DMARC: setting a policy and receiving reports for your domain

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM in two ways: it requires the authenticated identity to be aligned with the domain visible in the From: header, and it lets the domain owner tell mailbox providers what to do with messages that fail, while receiving reports in return. DMARC is described in RFC 7489; a revision, DMARCbis, is being finalised in the IETF DMARC working group.

Alignment: the heart of the mechanism#

A message passes DMARC if at least one of two conditions holds:

• SPF passes and the MAIL FROM domain is aligned with the From: domain;
• DKIM passes and the signature's d= domain is aligned with the From: domain.

Alignment is relaxed (the default) when both domains share the same organisational domain (news.example.com and example.com), and strict when they must be identical. The aspf= and adkim= tags set this behaviour separately for SPF and DKIM. In practice, aligned DKIM is the more robust condition, because SPF breaks on forwarding.

The DNS record#

The policy is published as a TXT record under the _dmarc label of the domain:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=r; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; pct=100"

Main tags:

• p=: requested policy for the domain, none (monitor), quarantine (file as spam) or reject (refuse);
• sp=: policy for subdomains, by default the same as p=;
• rua=: address receiving aggregate reports, sent as XML by mailbox providers, usually once a day;
• ruf=: address for detailed failure reports, which few providers still send;
• pct=: percentage of messages the policy applies to, useful for a gradual rollout;
• fo=: conditions for generating failure reports (0, 1, d, s).

If the rua address lives on a different domain from the one publishing the policy, the receiving domain must publish an authorisation record example.com._report._dmarc.receiver.tld containing v=DMARC1, otherwise providers will not send the reports.

Providers first look up _dmarc.<From domain>; if it does not exist, they fall back to the organisational domain. DMARCbis replaces the public suffix list with a DNS tree walk and introduces the np= tag for non-existent subdomains.

Deploying DMARC#

1. Make sure SPF and DKIM are in place and, above all, aligned for every legitimate stream: internal servers, marketing providers, transactional tools, third-party applications sending on behalf of the domain.
2. Publish p=none with a rua address. This has no effect on delivery, but reports start arriving.
3. Analyse the aggregate reports for several weeks: identify each source, fix missing alignment, have providers sign with DKIM using d= on your domain. The page reading a report covers this step in detail.
4. Move to p=quarantine, possibly with an increasing pct=, then to p=reject once no legitimate source fails any more.
5. Handle subdomains explicitly with sp=, and publish dedicated policies on those with a distinct purpose (see subdomains and wildcards).
6. Keep reading the reports: a new failing source means either a misconfigured new provider or an impersonation attempt.

Mailbox provider requirements since 2024#

In February 2024, Google and Yahoo enforced a common set of sender requirements, stricter for anyone sending more than 5,000 messages a day to their mailboxes: SPF and DKIM in place, a published DMARC record (at least p=none), alignment of the From: domain with SPF or DKIM, a valid PTR record, one-click unsubscribe per RFC 8058 for marketing mail, and a complaint rate kept below 0.3%. Microsoft announced comparable rules in 2025 for consumer Outlook mailboxes. These rules are imposed by mailbox providers, not by a standard: they govern delivery to their mailboxes and have become the de facto baseline for any domain that sends mail.

Common mistakes#

• Staying at p=none indefinitely: the reports are useful but the domain is not protected, and p=none is not enough for BIMI.
• Jumping to reject without reading the reports: legitimate, unaligned streams (support desk, invoicing tool, internal applications) get rejected.
• Forgetting sp= on a domain whose subdomains are used by third parties.
• rua pointing at a mailbox nobody reads, or at a third-party domain without the authorisation record.
• Confusing pct=0 with p=none: pct=0 applies the policy to no message but is still treated as an "active" policy by some checks, including BIMI.
• Relying on SPF alone: forwarding, mailing lists and redirections break SPF; without aligned DKIM, those messages fail.
• Several _dmarc records: the result is undefined and most providers ignore the policy altogether.

What SenderRadar shows#

SenderRadar presents the DMARC policy published for the domain, the effective policy for subdomains, the alignment modes, the report destinations and whether they are authorised, as well as inconsistencies between that policy and the state of SPF and DKIM. SenderRadar relies on its own analysis base to place the domain's policy level against comparable domains.

References#

• RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• IETF DMARC working group (DMARCbis)
• RFC 8058 – One-Click List Unsubscribe
• dmarc.org