Skip to content
AZ Tools

DMARC Record Builder

Compose a _dmarc TXT record — policy, subdomain policy, percentage rollout, alignment, rua/ruf reporting — with safety warnings.

Presets
TXT record · Publish as: _dmarc.example.com
v=DMARC1; p=none; rua=mailto:dmarc@example.com

Publish as a TXT record at _dmarc.<your-domain>. Replace 'example.com' in the rua/ruf addresses with a mailbox you own.

How to use

  1. Start with the monitor preset (p=none) — receivers report what's happening without affecting delivery.
  2. Once SPF/DKIM are aligned for all legitimate mail, jump to quarantine (or use pct= to slowly ramp).
  3. After a few weeks of clean reports, promote to p=reject. Keep the rua mailbox forever — it's how you catch new misconfigurations.

About this tool

Show

DMARC is the record that closes the loop on email authentication. SPF and DKIM each say something about a message; DMARC says what a receiver should do when neither of them lines up with the address the reader actually sees, and where to send reports about it. The builder walks the usual path — monitor with p=none, then p=quarantine, then p=reject — and exposes the alignment modes, the subdomain policy and the percentage rollout that real deployments lean on. The record is published as TXT at _dmarc.yourdomain.

Alignment is the idea that makes DMARC worth having, and it is the part that is easiest to miss. SPF authenticates the envelope sender and DKIM authenticates whatever domain signed the message, and neither is necessarily the From: address a person reads. DMARC requires one of them to match that visible domain: relaxed mode accepts any subdomain of the organisational domain, strict mode demands an exact match. This is why mail sent through a provider can pass SPF, pass DKIM, and still fail DMARC — the provider's own bounce domain is what SPF authenticated, and that is not your domain.

Start at p=none and mean it. That policy changes nothing about delivery; all it does is turn on the aggregate reports that tell you who is sending as you, which is the information you need before tightening anything. Publish an rua address from the first day, because a record with a policy and no reporting address gives you enforcement with no visibility. If that address is at a different domain, the receiving domain has to authorise it with its own DNS record — yourdomain.com._report._dmarc.theirdomain.com — and reports silently stop arriving when it is missing. ruf failure reports are a different matter: most large receivers do not send them at all, for privacy reasons, so an empty ruf mailbox is normal rather than a misconfiguration.

Two practical notes. pct= samples enforcement rather than weakening it, so pct=10 with p=reject rejects a tenth of failing mail and quarantines the rest — it is a ratchet to turn, not a setting to leave. And since early 2024, Google and Yahoo have required bulk senders to publish a DMARC record at all, so for a domain that sends any volume this is no longer optional hygiene.

Frequently asked questions

Relaxed vs strict alignment?

Relaxed (the default) matches the organizational domain — mail from news.example.com aligns with example.com. Strict requires an exact domain match. Use strict only if you understand exactly which subdomains send what.

Do I really need rua?

If you ever plan to enforce (quarantine or reject), yes. Aggregate reports are the only way to find out which legitimate senders are failing alignment before your enforcement starts dropping their mail.

What is a safe order of operations for turning DMARC on?

Publish p=none with a rua address first and change nothing else. That collects reports without affecting delivery, and the reports are the only way to discover the senders you forgot — the invoicing system, the ticketing tool, the marketing platform someone set up years ago. Move to quarantine, then reject, once every legitimate stream aligns. Going straight to reject usually means finding a forgotten sender by way of a complaint.

Which domain has to align, and why does a passing SPF still fail DMARC?

DMARC checks that the domain the reader sees in From matches the domain that SPF or DKIM authenticated. A bulk sender that passes SPF for its own bounce domain therefore fails alignment while passing SPF, which is the single most common cause of an unexpected DMARC failure. DKIM signed with your domain is usually the more robust way to satisfy it, because it survives forwarding.

Related tools