How to check a DMARC record

`dig _dmarc.example.com TXT +short`. An empty result means no DMARC record, whatever may have been published on the apex domain.

A valid record begins `v=DMARC1;` and must include a `p=` tag.

Check subdomains too, or check for `sp=` on the organisational domain — subdomains inherit the parent policy unless `sp=` says otherwise.

`p=` — the policy: `none`, `quarantine` or `reject`.

`rua=` — where aggregate reports are sent. Without it you get no visibility, which is the main benefit of `p=none`.

`pct=` — the percentage of messages the policy applies to, used to roll out gradually.

`sp=` — the policy for subdomains.

`aspf=` and `adkim=` — whether alignment is strict or relaxed.

At `p=none`, failing mail is delivered normally. The domain can be spoofed as if no record existed.

Its value is the reports: they name every service sending mail in your name, including ones nobody remembers signing up for.

Most domains publish `p=none` and stop there, which means they hold the evidence and take none of the benefit.

Collect aggregate reports for several weeks at `p=none`.

Fix each legitimate sender so it aligns — add it to SPF, or set up DKIM signing with your domain.

Move to `p=quarantine` with a low `pct=`, and watch.

Move to `p=reject` once only illegitimate mail is failing.

Rushing rejects your own invoices; staying at none protects nothing.

`rua=` takes a mailto: address, and the choice of address matters more than it looks, because the reports are gzipped XML arriving daily from dozens of providers.

Sending them to a person's mailbox means they are deleted unread within a week. This is the usual outcome, and it is why so many domains have reporting configured and no idea what is in it.

A dedicated mailbox plus a processing tool is the working arrangement. Several services accept the reports and present them as a readable history of senders; a shared mailbox and an afternoon with a parser is the alternative.

An address on another domain must authorise it. Publishing `rua=mailto:dmarc@reports.example.net` for `example.com` requires a TXT record at `example.com._report._dmarc.reports.example.net`, or conforming receivers will not send. This is an easy step to miss, and the symptom is simply no reports arriving.

Multiple addresses are allowed, comma-separated, which is how a processing service and an internal archive can both receive them.

SPF authenticates the envelope sender — an address the recipient never sees. DMARC requires that a passing result belongs to the same domain as the visible From: header. That is alignment.

Forwarding and third-party senders commonly break it: the message is legitimate, SPF passes for the forwarder, and DMARC does not count it because the domains differ.

This is why DKIM matters: it survives forwarding, and DMARC needs only one of the two to pass in alignment.

`email.dmarc.present`, `email.dmarc.policy`, `email.dmarc.syntax`, `email.dmarc.alignment`, `email.dmarc.subdomain`, `email.dmarc.pct`, `email.dmarc.rua` and `email.dmarc.ruf` read the record and report the policy, the reporting addresses and the subdomain coverage.

They are read alongside the SPF and DKIM checks, because DMARC depends on both.

The record is what is observed. What receivers actually did with your mail is in the aggregate reports, which arrive at the address in `rua=`.

The reason to spend weeks at `p=none` rather than days is that the list of systems sending mail in your name is always longer than anyone in the organisation believes.

The obvious ones are in place before anybody starts: the mailbox provider, the transactional sender the application uses, the marketing platform.

The ones the reports find are the others. A CRM that emails prospects from the salesperson's address. An invoicing tool. A recruitment system sending rejections. A survey platform. A support desk. A scheduling tool sending calendar invitations. A monitoring system alerting the team.

Then the individual ones: a newsletter tool somebody in marketing signed up for, a form service embedded on one page, an e-signature platform used by legal.

And the historical ones: a service cancelled two years ago whose entry is still in the SPF record, consuming lookups for nothing.

Each has to be dealt with before enforcement, and there are only two options: bring it into alignment — into SPF, or signing with DKIM under your domain — or accept that its mail will be rejected. There is no third option, and discovering one of these after moving to `p=reject` means discovering it as an outage.

This is also why `pct=` exists. Moving to `p=quarantine` with a low percentage exposes a missed sender as a small number of complaints rather than as every message failing at once.