DMARC Policy and Reporting

The three parts of DMARC

First, alignment. Receivers run SPF and DKIM as usual, then ask whether the domain that passed matches the domain in the visible From header. With relaxed alignment (the default) the two only need the same organisational domain; with strict alignment they must be identical. DMARC passes if at least one of SPF or DKIM passes and aligns.

Second, policy. The p= tag says what the domain owner asks receivers to do with messages that fail: none to take no special action, quarantine to treat them as suspicious, reject to refuse them. Tags sp and np can set different policies for subdomains and for names that do not exist, and pct applies the policy to part of the failing mail while you roll out.

Third, reporting. The rua tag lists where aggregate summaries should go and ruf where individual failure reports may go. Reporting is independent of policy: a p=none record is how most domains start collecting data.

Where the record lives and how parents apply

The record is a TXT record at _dmarc. followed by the domain, beginning v=DMARC1. If a subdomain has no record of its own the receiver looks upward, and the policy found at the parent applies, with sp taking over if the parent specified it. The DMARC checker displays every step of this walk, and notes when the record was inherited. Only one DMARC record may exist at a name; if there are several, they are all discarded and the domain behaves as if it had none.

p=none is monitoring, not misconfiguration

A policy of none is sometimes reported as a fault. It is better described as the first stage. It requests reports but asks receivers to change nothing, so it offers no protection from spoofing, and it is also the safe place to learn who sends mail as your domain. The error is staying there forever. A domain should know why it is still at none, and what blocks the move to quarantine.

External report destinations need authorisation

This is the point most often missed. If a rua or ruf mailbox is on a different organisational domain from the domain publishing the policy, RFC 7489 section 7.1 asks the receiver to check that the destination agrees. The destination domain must publish a TXT record at example.com._report._dmarc.destination-domain whose value begins v=DMARC1. Without it, compliant receivers do not send the reports. Using a third-party report-processing service means that service has to publish such records for your domain, or you publish a delegation for them; ask the provider which it expects.

So there are two independent questions to ask of any record: what policy does it request, and can reports actually arrive? A record can have a perfectly valid p=none and deliver nothing, or a working reporting address and a weak policy. The DMARC checker reports these as separate findings for this reason.

Rolling out enforcement

1. Make sure SPF and DKIM work for the main mail platform, and publish v=DMARC1; p=none; rua=mailto:[email protected], authorising the destination if it is on another domain.
2. Collect aggregate reports for several weeks or a full business cycle, to capture monthly and quarterly senders such as billing systems.
3. For each legitimate source that fails, enable DKIM signing with your domain or fix SPF alignment. Stop and investigate sources you do not recognise.
4. Move to p=quarantine with a small pct, observe, then raise pct in steps. Receivers differ in how they treat quarantine, so watch for complaints of missing mail.
5. Move to p=reject when the reports are clean. Keep the old record text so you can revert immediately.
6. Decide the subdomain policy deliberately with sp. Unused subdomains are a common spoofing route and can be set to reject early.

Operational risks

Enforcement changes affect mail from every system that uses your domain: forgotten application servers, ticketing tools, printers and third parties acting for you. Mailing lists and forwarders can break alignment even when the original sender is correct, because they change the connecting IP or alter the message. Plan for support requests, and keep the TTL low while you change policy so that a rollback is quick.

What DMARC does not do

DMARC protects the exact domain in the From header. It does not stop look-alike domains, display-name impersonation or compromised legitimate accounts, and reports are summaries sent by participating receivers, not a complete record of all mail. The failure reports requested by ruf are sent by few receivers and can contain message data, so consider privacy before requesting them.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09