DMARC setup starts with a TXT record at _dmarc.yourdomain such as v=DMARC1; p=none; rua=mailto:dmarc@yourdomain. Collect aggregate reports for two to four weeks, make every legitimate sender pass SPF or DKIM with your own domain, then raise the policy to p=quarantine and finally p=reject, which tells receivers to refuse forged mail.
Publishing a DMARC record takes two minutes. The trouble is what comes after. Jump straight to p=reject and you may discover the next morning that order confirmations from your shop platform have stopped arriving, because that platform never signed with your domain. The safe route goes through stages, and through the reports.
What DMARC actually checks
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It was first published as RFC 7489 in 2015, an informational document. In May 2026 the IETF replaced it with standards-track RFC 9989 for the protocol, plus RFC 9990 and 9991 for aggregate and failure reporting. Records still start with v=DMARC1, and existing ones keep working.
DMARC ties two older mechanisms to the one address people actually look at: the From header. A message passes if at least one of these is true:
- SPF passes and the envelope domain aligns with the From domain.
- DKIM passes and the signing domain (
d=) aligns with the From domain.
Without that alignment step, an attacker could pass SPF for their own domain while writing [email protected] into the From line. The two building blocks are explained in SPF record setup and DKIM setup.
The DMARC record, tag by tag
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"| Tag | Purpose | Values |
|---|---|---|
v | Version, must come first | DMARC1 |
p | Policy for the domain | none, quarantine, reject |
sp | Policy for subdomains | same as p; defaults to p |
np | Policy for non-existent subdomains (RFC 9989) | same as p |
rua | Where aggregate reports go | mailto: URI(s) |
ruf | Where failure reports go | mailto: URI(s) |
adkim / aspf | Alignment mode | r relaxed (default), s strict |
fo | When to generate failure reports | 0, 1, d, s |
t | Test mode: apply one level softer (RFC 9989) | y, n |
Relaxed alignment means mail.example.com aligns with example.com because they share an organisational domain. Strict demands an exact match. Relaxed is right for almost everyone.
ruf asks for reports on individual failing messages. Gmail does not send them at all, and many other large receivers don’t either, for privacy reasons. If you do get them, treat the inbox as one that holds personal data.
A staged rollout
| Phase | Record | Typical length | What you do |
|---|---|---|---|
| 1 | p=none; rua=… | 2–4 weeks | Collect reports, map every sender |
| 2 | p=none | until clean | Move each service onto your domain |
| 3 | p=quarantine | 2–4 weeks | Watch for stragglers |
| 4 | p=reject | permanent | Check reports monthly |
Those durations are rules of thumb. A one-person business on Google Workspace can be done in a week. A company with an ERP, a shop, two marketing tools, a recruiting portal and several agencies sending on its behalf should plan for two months.
The new t=y flag can soften phases 3 and 4 further. Receivers that understand it treat reject as quarantine, and quarantine as none. Don’t count on every receiver supporting it yet.
Getting reports, including to another domain
Aggregate reports arrive as XML files inside ZIP or gzip attachments, usually one per receiver per day. Even a modest domain soon gets dozens a day. How to make sense of them is covered in read DMARC reports.
If rua points to an address on a different domain, such as a reporting vendor, that domain has to opt in by publishing a verification record:
example.com._report._dmarc.reports.vendor.example. IN TXT "v=DMARC1"Without it, careful receivers drop the reports. Reputable vendors publish this for you.
Checking your record
$ dig +short TXT _dmarc.example.com
"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"That one is real: IANA publishes a strict reject policy for example.com, since it should never send mail. Compare Google’s own consumer domain:
$ dig +short TXT _dmarc.gmail.com
"v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]"Gmail.com stays at p=none because decades of devices, printers and apps send mail with Gmail addresses from servers Google doesn’t control. Your company domain has no such excuse.
What Google, Yahoo and Microsoft require
Since February 2024, anyone sending more than 5,000 messages a day to Gmail addresses must use SPF and DKIM, publish a DMARC record (p=none is acceptable) and align the From domain with SPF or DKIM. Marketing mail needs one-click unsubscribe, and the spam complaint rate must stay below 0.3%. Yahoo introduced matching rules at the same time without a fixed volume threshold. Microsoft followed for Outlook.com consumer mailboxes in 2025.
Smaller senders to Gmail need SPF or DKIM, valid reverse DNS and TLS. DMARC isn’t mandatory for them. Publish it anyway: it is the only thing that stops other people using your domain.
Mistakes that break DMARC
- Publishing the record at the root of the domain instead of at
_dmarc. - Missing semicolons:
v=DMARC1 p=noneis not parsed. [email protected]without themailto:prefix.- Two records under
_dmarc, so neither counts. - Forgetting parked domains. Any domain you own that never sends mail needs
v=spf1 -allandv=DMARC1; p=reject, or it becomes a convenient phishing sender.
Each domain needs its own record, so if you hold a .com and a .co.uk for the same brand, set both up. At betadomain both live in the same account, with DNS records edited next to the domain. A .com registration costs €14.99 a year and a .co.uk €15.99, renewing at the same price. If you still need to pick a domain for company email, publish SPF, DKIM and DMARC before the first message goes out. Why enforcement matters so much is spelled out in prevent email spoofing.
Step by step
- Create a reporting addressSet up a mailbox such as dmarc@yourdomain, or sign up with a report-processing service, to receive daily aggregate reports.
- Publish a monitoring recordAdd a TXT record at _dmarc.yourdomain containing v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.
- Review two to four weeks of reportsIdentify every IP address sending as your domain and whether each passes SPF or DKIM aligned with your From domain.
- Fix every legitimate senderEnable custom-domain DKIM in each platform, add missing SPF includes and retire services you no longer use.
- Move to quarantineChange the policy to p=quarantine and watch the reports for another two weeks for legitimate mail that still fails.
- Enforce with rejectWhen only unknown sources fail, set p=reject. Receivers will now refuse mail that forges your domain.
Found your domain? You can check and register it directly at check your domain – yearly price from €2.99.
FAQ
Is p=none enough for Gmail and Yahoo?
For the bulk sender rules, yes. Since February 2024 Google requires anyone sending more than 5,000 messages a day to Gmail to publish DMARC, and a policy of none is accepted. It does not stop spoofing, though; it only turns on reporting.
What happens to mail that fails DMARC?
Under p=none, nothing changes and it is delivered as usual. Under p=quarantine most receivers put it in spam. Under p=reject the receiving server refuses it and the sender gets a bounce.
Do subdomains need their own DMARC record?
Not necessarily. The organisational domain's record covers subdomains, and sp= sets a separate policy for them. A subdomain that publishes its own _dmarc record overrides the parent.
Is the pct tag still valid?
RFC 7489 defined it, but the replacement specification, RFC 9989 from May 2026, removed pct and added t=y as a testing flag. Receivers still running RFC 7489 logic may read pct, so leaving it out (which means 100) is the cleanest option.