DNS Helper

DMARC

DMARC, like SPF and DKIM, lives inside a TXT record, and builds on both rather than replacing either. It tells receiving servers what to do with a message that fails those checks, and gives you visibility into what's actually happening with your domain's mail through reports, rather than leaving both entirely to guesswork.

That is a sensible first record: it asks for nothing to be blocked, only for reports to be sent. The tags are separated by semicolons, and v=DMARC1 has to come first, a record that starts with anything else is ignored. There should also be exactly one DMARC record at that name: if a receiving server finds two, it discards both, which is an easy mistake to make when a panel or a provider's instructions add a second one instead of replacing the first.

Alignment: more than just "did SPF or DKIM pass"

DMARC doesn't only check whether SPF or DKIM passed somewhere, it also checks whether the domain that passed actually matches the domain a person sees in the message's own "From" address, a check called alignment. A message can pass SPF for one domain and still fail DMARC if the visible From address belongs to a different one, since forwarding, a misconfigured mailing list, or outright spoofing can all produce exactly that mismatch. DMARC only counts a message as authenticated when SPF or DKIM passes for a domain that aligns with the From address, not for any domain that merely appears somewhere in the message.

Policy: what happens to a message that fails

The p= tag says what a receiving server should do: none takes no action beyond reporting, quarantine typically means the spam or junk folder, reject means refusing the message outright. Moving straight to reject on a domain nobody has monitored yet risks losing legitimate mail that some not-yet-noticed misconfiguration was quietly relying on. The usual, sensible order is starting at p=none, watching the reports for a while, fixing whatever they reveal, then tightening to quarantine and eventually reject once nothing legitimate is failing any more.

Subdomains: sp and np

A policy on the main domain also covers its subdomains, unless a sp= tag says otherwise, for example p=reject; sp=none. A newer tag, np=, sets the policy for subdomains that do not exist in DNS at all. It applies only to those, not to existing subdomains and not to the domain itself, and when it is absent the sp= policy applies, or p= if there is no sp= either.

Reports: rua and ruf

rua= is where aggregate reports go, a periodic summary, typically covering one day, of what passed, what failed, and from where, sent as XML rather than anything readable at a glance, and usually compressed with gzip, so the attachment you receive often ends in .xml.gz. ruf= is for failure reports, sometimes still called forensic reports, copies of individual failing messages, and many large mail providers limit or switch off sending them entirely, because a copy of a failing message can contain personal data. The current specification itself calls aggregate reports the recommended way to get visibility, so rua= is the tag worth setting first.

Reading raw XML by hand doesn't scale much past a handful of reports, so most people use something built for the job instead: hosted SaaS services that collect and visualise reports exist, and so do self-hosted options, anything from an open-source project on somewhere like GitHub to a mail client plugin, one exists for Thunderbird, for reading them locally without handing the data to someone else's dashboard.

Reports don't have to come back to your own domain

rua and ruf don't have to be an address on the domain the DMARC record itself belongs to, mailing reports somewhere else entirely, a dedicated reporting service or a domain set up purely to collect them, is common. When they do point elsewhere, that other domain has to explicitly authorise it, or receiving mail servers ignore the reporting instruction rather than risk sending your domain's mail data to an address nobody actually agreed to receive it. That authorisation is itself a DNS record: a v=DMARC1; TXT record published on the other domain, named example.com._report._dmarc.example.net. Without it, an off-domain rua is simply ignored, silently, which is worth knowing before assuming reports are arriving just because the record says they should be. The same rule applies to ruf. A service that collects reports for many domains can publish one wildcard record, *._report._dmarc.example.net, instead of one per customer.

Building one yourself

Assembling a DMARC record by hand is easy to get wrong in the wrong direction, publishing p=reject immediately, before knowing what's actually sending mail as your domain, is the mistake that costs legitimate mail. Expert Tools' DMARC wizard builds a record for you to review and publish, defaulting to the same start-at-none-then-tighten approach covered above rather than jumping straight to the strictest setting.

Older guides and the current specification

DMARC was first written down in RFC 7489, which is still what most older guides cite. Since May 2026 it has been replaced by RFC 9989, with the two kinds of report moved into RFC 9990 (aggregate) and RFC 9991 (failure). Some tags from those guides, pct=, rf= and ri=, are marked historic in the new specification's own registry, meaning they are no longer expected to be in use, so a record copied from an older tutorial may carry tags that no longer do anything. Unknown tags are ignored rather than treated as an error.