DMARC: the record that says what to do when SPF and DKIM fail.
SPF and DKIM each prove something about a message. DMARC ties that proof to the address the recipient actually sees, tells receivers what to do when it is missing, and sends you reports about who is using your domain. It lives in one TXT record at _dmarc.yourdomain.com. This page explains the record and its tags with three worked examples; the step-by-step setup for all three records is on SPF, DKIM and DMARC setup.
What DMARC adds over SPF and DKIM.
SPF lists the servers allowed to send for a domain, but the domain it checks is the one in the bounce address, which the recipient never sees. DKIM signs the message with a key published under a domain, but that domain can be anything the signer controls. A phisher can pass both, with their own bounce domain and their own signature, while the From header still says billing@acme.com.
DMARC closes that gap with one rule called alignment: the domain that passed SPF, or the domain in the DKIM signature, must match the domain in the visible From header. A message passes DMARC when at least one of the two passes and aligns. When neither does, the record’s policy tells the receiver what to do, and the record’s reporting address tells them where to send the daily summary of what they saw.
That reporting is the part most guides skip. Before DMARC you have no way to know who is sending as your domain. After a week on the weakest policy you have a list of every source, the share of mail that aligned, and the sources that did not.
Three records, one for each stage.
Each is a single TXT record at _dmarc under the domain. Replace acme.com and the reporting address with your own; the reporting mailbox must exist and be able to receive XML attachments, or be an address a DMARC reporting service gives you.
_dmarc.acme.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.com"
This is where every domain should start. p=none changes nothing about delivery. The rua address is what makes it worth publishing: without it you have a record that satisfies a checklist and teaches you nothing.
_dmarc.acme.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@acme.com"
pct=25 applies the quarantine policy to a quarter of the mail that fails; the other three quarters are treated as none. Raise it to 50, then 100, as the reports stay clean. Quarantine in practice means the spam folder, so a forgotten sending source shows up as complaints from colleagues rather than as lost mail.
_dmarc.acme.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@acme.com"
p=reject refuses failing mail during the SMTP conversation. sp=reject extends that to subdomains you have not published their own record for, which is where lookalike sending usually moves once the apex is protected. adkim=s and aspf=s require an exact domain match rather than a subdomain; leave them relaxed if you send from mail.acme.com with a From address at acme.com, or the mail stops.
Every tag, and what it defaults to.
| Tag | Meaning | Notes |
|---|---|---|
v | Version. Always DMARC1. | Must be the first tag or the record is ignored. |
p | Policy for mail that fails: none, quarantine or reject. | The only other required tag. Start at none. |
sp | Policy for subdomains. | Defaults to the value of p. Set it explicitly once you know which subdomains send. |
rua | Where aggregate reports go, as a mailto: address. | Daily XML summaries per sending source. This is the tag that makes p=none useful. |
ruf | Where forensic reports go. | Per-message failure samples. Few providers send them; most senders leave it out. |
pct | Share of failing mail the policy applies to, 0 to 100. | Defaults to 100. Lets you roll out quarantine or reject to a fraction first. |
adkim | DKIM alignment: r (relaxed) or s (strict). | Relaxed accepts a subdomain of the From domain; strict wants an exact match. Defaults to r. |
aspf | SPF alignment: r (relaxed) or s (strict). | Same rule for the SPF domain. Defaults to r. |
Reading the aggregate reports.
Each receiver that supports reporting sends one XML file a day to the rua address. Inside, the mail is grouped by sending IP address, and each group carries the count, the SPF and DKIM results, and whether each aligned with the From domain. Raw XML is readable in an emergency and unpleasant otherwise; a free DMARC report viewer turns a month of it into a table of sources.
The question to ask of the table is simple: is every source that passes one you recognise, and is every source that fails one you do not? A legitimate source that fails is a sending service you never set records for, a marketing tool using its own domain for SPF, or a subdomain nobody told you about. Fix those first. A source you do not recognise that fails is what DMARC exists to stop; when only those remain, tighten the policy.
Move from none to quarantine when the reports have shown nothing legitimate failing for a few weeks. Move from quarantine to reject when nothing you care about has landed in spam since. Keep the rua tag at every stage; the reports do not stop being useful once the policy is strict.
Why Notix recommends starting at none.
When you add a domain to Notix, the setup lists the DKIM, SPF and MX records the domain needs to verify, and a fourth record marked recommended rather than required: a DMARC record with the value v=DMARC1; p=none;. It is deliberately the weakest form. A domain that has just started sending has no report history and often has other senders attached to it: Google Workspace, a help desk, a marketing tool. A strict policy on day one would quarantine those before anyone knew they existed. p=none satisfies the mailbox providers that ask for a record, costs nothing, and starts the reports. Add a rua address to it and tighten on evidence.
Mail sent through Notix aligns either way. Every message is signed with DKIM under your own domain, using the notix selector from your setup, so the DKIM domain matches your From address and the message passes DMARC at any policy. The missing record is also one of the warnings the pre-send check raises, so a domain without one is flagged before a campaign, not after.
What Gmail and Yahoo require.
Since 1 February 2024 Google’s sender guidelines require anyone sending 5,000 or more messages a day to Gmail addresses to authenticate with both SPF and DKIM, publish a DMARC record, align the From domain with SPF or DKIM, support one-click unsubscribe on marketing mail and keep the spam rate reported in Postmaster Tools below 0.3%. On the DMARC policy the guidance is explicit that the enforcement policy can be set to none. Yahoo’s sender requirements ask for the same: both SPF and DKIM, a DMARC policy of at least p=none that passes, one-click unsubscribe and a spam rate below 0.3%. Below the bulk threshold a DMARC record is not mandatory, but every mailbox provider treats its presence as a signal that the domain is looked after.
Questions, answered.
What is a DMARC record example I can copy?
Do I need DMARC if I already have SPF and DKIM?
What is the difference between p=none, p=quarantine and p=reject?
What does DMARC alignment mean?
Will DMARC break email sent through Notix?
How long should I stay on p=none?
Keep reading.
Set up SPF, DKIM and DMARC
The three DNS records a sending domain needs, what each one proves, and the one-click path when your DNS provider supports Domain Connect.
LearnSPF records for transactional email
What an SPF record says, the include for a sending service, the ten-lookup limit and how to stay under it.
LearnDKIM selectors and keys
How a DKIM signature is checked, what the selector in the DNS name is for, and why each sending service gets its own.
LearnEmail deliverability and sender reputation
What mailbox providers score, the complaint threshold that matters, warming a new domain, and the honest position on shared IPs.
NotixDocs
The quickstart: verify a domain, copy an API key, send the first email.
Verify a domain and the records are listed for you.
DKIM, SPF, MX and the recommended DMARC record, checked automatically once they resolve.