DMARC record examples
; monitoring: nothing is blocked, reports arrive daily
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
; testing quarantine before it applies (RFC 9989's t tag)
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"
; enforcing, made-up subdomains refused outright
_dmarc.example.com. TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"
; a domain that sends no mail at all
_dmarc.example.org. TXT "v=DMARC1; p=reject"A domain that never sends mail is worth a record too — it is easier to spoof than one that does. Pair p=reject with the SPF record v=spf1 -all, which the SPF record generator writes when you list no servers and pick -all.
The tags
| Tag | Values | Meaning |
|---|---|---|
| v | DMARC1 | Version, exactly in that case; must be the first tag |
| p | none | quarantine | reject | What receivers do with mail that fails; treated as none when missing |
| sp | none | quarantine | reject | The same for existing subdomains; p applies when left out |
| np | none | quarantine | reject | For subdomains that do not exist in DNS; sp or p applies when left out |
| t | y | n | Test mode: y asks receivers to apply one step softer (quarantine → none, reject → quarantine) |
| rua | mailto:… | Where aggregate reports go — one or more addresses, separated by commas |
| ruf | mailto:… | Where failure reports on single messages go; few large receivers send them |
| fo | 0 | 1 | d | s | When failure reports are wanted; only read together with ruf |
| adkim, aspf | r | s | Relaxed alignment (a subdomain counts) or strict (exact match); relaxed when left out |
| psd | y | n | u | Whether the domain is a public suffix (y) or its own organisational domain (n) |
What changed with RFC 9989
DMARC was an informational RFC (7489) for eleven years. RFC 9989, published in May 2026, makes it a Proposed Standard and replaces both RFC 7489 and RFC 9091; aggregate and failure reports moved to RFC 9990 and RFC 9991. For a record, that means:
| Change | What to do |
|---|---|
| pct removed | Receivers applied values other than 0 and 100 unevenly. For a soft start use t=y; leave pct out unless you depend on an older receiver. |
| t added | t=y is the old pct=0: the policy is announced but applied one step softer, and mailing lists already treat your mail as they would under enforcement. |
| np added | A separate policy for made-up subdomains, so that a spoofer cannot fall back to random.example.com. Receivers still on RFC 7489 ignore it. |
| psd added | For registries, and for organisations that want a delegated subdomain to be its own organisational domain (psd=n). |
| ri, rf removed | Reports arrive daily regardless, in one format. Both tags are ignored. |
| Policy discovery | Receivers walk up the DNS from the From domain instead of consulting the public suffix list. Explicit records on every sending domain avoid any difference between old and new receivers. |
Nothing breaks: v=DMARC1 stays, and receivers ignore tags they do not know. A record with pct=100 or ri=86400 keeps working; the generator reads them from a pasted record, flags them and leaves them out.
From p=none to reject
- 1Monitor for at least a month
p=nonewith a report address. The aggregate reports list every server that sent mail as your domain — your own, your providers’, and anyone spoofing you. Read them with a report service or a parser; they are XML files, one per receiver per day. - 2Fix every legitimate source
Each service that sends as you needs SPF or DKIM that passes for your domain. DKIM matters more: SPF does not survive forwarding, and a newsletter service usually bounces through its own domain, so only a DKIM signature with your domain makes its mail pass.
- 3Quarantine — in test mode first
p=quarantine; t=yfor a while, then withoutt=y. RFC 9989 suggests staying at quarantine about as long as you monitored, and comparing the reports. - 4Reject
p=rejectonce the reports are clean. RFC 9989 warns that domains whose users post to mailing lists run into trouble with reject, because lists change messages in ways that break the checks; with reject, every message must carry a DKIM signature.
Sending reports to another domain
When rua points to an address outside your organisation — a report service, or your company’s main domain — that domain has to agree, or receivers drop the address (RFC 9990, section 4). It publishes one TXT record that names your domain; report services publish a wildcard:
example.com._report._dmarc.reports.example.net. TXT "v=DMARC1"
*._report._dmarc.reports.example.net. TXT "v=DMARC1" ; any domainThe generator lists the record each outside address needs. After publishing, the DMARC checker reads your record from DNS and tests whether those authorisations are in place.
Frequently asked
Where do I publish the DMARC record?
As a TXT record at _dmarc in front of your domain: _dmarc.example.com. Most DNS panels ask only for the host part, _dmarc, and add the domain themselves. Publish exactly one: with two DMARC records at the same name, receivers discard both. The record also covers subdomains that have none of their own.
Which DMARC policy should I start with?
p=none with a rua= report address, for at least a month — the reports list every server that sends as your domain, including the ones you forgot. Then p=quarantine, with t=y as a test step if you like, for about as long, and p=reject once all of your own mail passes and is DKIM-signed. RFC 9989 describes this path and warns that p=reject causes trouble for domains whose users post to mailing lists. p=none on its own protects nothing.
What changed with RFC 9989 (DMARCbis)?
RFC 9989, published in May 2026, made DMARC a Proposed Standard and replaced RFC 7489 and RFC 9091. It adds the np tag (a policy for subdomains that do not exist), t (test mode, which replaces pct) and psd, and removes pct, ri and rf; reporting moved to RFC 9990 and RFC 9991, and receivers now find the organisational domain by walking up the DNS instead of using the public suffix list. Existing records keep working: v=DMARC1 is unchanged, and receivers ignore the tags they no longer know.
Do I need DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM only say that some domain vouches for a message; without DMARC nothing requires that domain to be the one in the From address people see, so a spoofer can pass SPF with a domain of his own and still show yours. Gmail and Yahoo also require a DMARC record — p=none is enough — from everyone who sends them bulk mail, since February 2024.
Can DMARC reports go to an address at another domain?
Yes, if that domain agrees. It publishes a TXT record v=DMARC1 at yourdomain._report._dmarc.theirdomain — for example example.com._report._dmarc.reports.example.net — and report services publish one for every domain at once. Without it, receivers drop the address. The generator names the record each outside address needs.