Domain-based Message Authentication, Reporting & Conformance¶
What is DMARC?¶
DMARC is an email authentication, policy and reporting protocol.
It builds on SPF and DKIM and allows you to protect your domain from fraudulent emails. You can detect and prevent spoofed emails claiming to come from your domain.
Use our free DMARC tool to check the policy a domain actually publishes and build the one it should publish next. It walks the DNS tree the way a receiving mail server does, so it shows you which record governs the name you asked about — which is often not the name itself — and it judges what it finds against the 2026 revision below.
What changed in 2026¶
DMARC was re-specified in May 2026 as RFC 9989, RFC 9990 and RFC 9991, replacing RFC 7489. Receivers are split across the old rules and the new ones, so a record written before the revision can be handled two different ways depending on who receives it.
Three changes matter when you write a record today.
pct was removed. It used to apply your policy to a share of failing mail and the next-weaker policy to the rest, so p=reject; pct=10 meant reject a tenth and quarantine the remainder. Receivers never implemented it consistently, and receivers that have adopted the revision now ignore it entirely and apply your full policy. If your record still carries a pct, it is already doing more than its author intended — a p=reject; pct=10 is a full rejection at a modern receiver.
np was added, for subdomains that do not exist. sp covers subdomains you have; np covers the ones a spoofer invents, like billing.yourdomain.com. It costs nothing, because no legitimate mail comes from a name that is not there, and a receiver that does not support it falls back to your p. Set it.
Finding the policy is now a DNS tree walk rather than a lookup at the organisational domain via the Public Suffix List. A receiver queries _dmarc. at the name, then walks up the tree, which means the record that governs a subdomain may live several labels above it. psd lets a domain stop that walk at itself.
The revision also added t, which asks receivers to apply one step less than your policy while you test. We do not recommend it yet: a receiver predating the revision cannot see it and applies your policy in full, so p=reject; t=y means quarantine at some receivers and real rejection at others. Stepping through p=none to p=quarantine to p=reject means the same thing to every receiver, which is what a staged rollout needs.
Getting Started¶
If you want to get started with DMARC you already need to have SPF and DKIM in place.
If you're using a hosted mail provider like GSuite, O365, FastMail or others, search online for how to setup SPF and DKIM with those providers. This is generally a simple process that only requires you to set a DNS TXT record for SPF and a CNAME record for DKIM.
Here is our SPF record:
report-uri.com. 299 IN TXT "v=spf1 include:spf.messagingengine.com include:sendgrid.net ~all"
Here are our DKIM records:
fm1._domainkey.report-uri.com. 299 IN CNAME fm1.report-uri.com.dkim.fmhosted.com.
fm2._domainkey.report-uri.com. 299 IN CNAME fm2.report-uri.com.dkim.fmhosted.com.
fm3._domainkey.report-uri.com. 299 IN CNAME fm3.report-uri.com.dkim.fmhosted.com.
Your records will be different, so please don't copy and paste ours!
Enable DMARC¶
Once you have SPF and DKIM configured, you can enable DMARC. Enabling DMARC is as simple as creating a single DNS TXT record that contains the policy you would like enforcing on your emails. Here is an example of what that might look like:
v=DMARC1; p=none; np=reject; rua=mailto:scotthelme-d@dmarc.report-uri.com
Publish this at _dmarc.yourdomain.com, not at the domain itself. p=none changes nothing about how your mail is treated — it exists to start your reports, so you can find every legitimate sender before any of their mail is at risk. Move up to p=quarantine and then p=reject once a few weeks of reports show only senders you recognise.
DMARC is very flexible and you can be as strict or relaxed as you like in your policy. There are details on how to configure DMARC here, and our DMARC tool will build a record from the choices rather than asking you to remember the tag names.
Supported report types¶
Currently, we support only the aggregate feedback reports (rua) and we don't have any plans to implement support for ruf (message-specific failures) reports at present as they can contain samples of the message content itself and this is data we don't wish to store or process.
At present, given ruf reports are such low volume, and the nature of the content they can contain, our best advice is to send those directly to your own email.
Useful Links¶
SPF - https://scotthelme.co.uk/email-security-spf/
DKIM - https://scotthelme.co.uk/email-security-dkim/
DMARC - https://scotthelme.co.uk/email-security-dmarc/
Start Monitoring with Report URI¶
Already collecting DMARC reports with us? Find your reporting address on Setup, or view your DMARC reports. Run the DMARC tool against your domain to see which policy actually applies to it and what it is costing you.
New to Report URI? Create an account, then grab your unique DMARC reporting address from the Setup page to use in the rua= record above.