Publishing a DMARC record and tightening it safely

Where the record lives and what it contains

A DMARC record is a TXT record at the _dmarc label of the domain that appears in the header From. For example.com the name is _dmarc.example.com. It must begin with v=DMARC1, and the domain must publish exactly one — several records at that name means no policy is applied at all.

A receiver that finds no record at the header From domain looks for one at the organisational domain, so a policy on example.com covers mail.example.com unless that subdomain publishes its own.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; pct=100; adkim=r; aspf=r; rua=mailto:[email protected]; ri=86400"

Alignment is the point of DMARC

An SPF pass is about the envelope sender. A DKIM pass is about the domain in d=. Neither is inherently about the address the recipient sees. Alignment is the rule that requires one of those passing identities to refer to the same domain as the header From, and it is what makes DMARC more than a summary of the other two.

Relaxed alignment, the default for both mechanisms, compares organisational domains: a DKIM signature from mail.example.com aligns with a header From at example.com. Strict alignment requires the names to match exactly. Set adkim=s or aspf=s to demand strict, and expect it to break any provider that signs with a subdomain.

A message passes DMARC when SPF passes and its envelope domain aligns, or when DKIM passes and its d= domain aligns. One aligned pass is enough; both mechanisms failing alignment is a DMARC failure regardless of how many unaligned passes the message collected.

The tags that change behaviour

• p= is the policy for the domain itself: none, quarantine or reject. It is the only mandatory tag besides v.
• sp= is the subdomain policy. Without it, subdomains inherit p=, which is usually what you want once the rollout is finished but not during it.
• pct= samples enforcement, applying the policy to that percentage of failing messages and the next weaker action to the rest. A failing message not sampled under p=reject is quarantined, and under p=quarantine is left alone.
• adkim= and aspf= select relaxed (r, the default) or strict (s) alignment for each mechanism independently.
• rua= is where aggregate reports are sent, and ruf= where failure reports are sent if a receiver generates them at all.
• ri= is the requested aggregate reporting interval in seconds, defaulting to 86400. Receivers are not obliged to honour anything but a daily cadence.
• fo= controls when a failure report is requested: 0 for a complete DMARC failure, 1 for any mechanism failure, d and s for DKIM and SPF failures specifically.

What receivers do with a policy

A DMARC policy is a request, not a command, and receivers vary in how literally they take it. A large mailbox provider may apply its own reputation judgement over the top, delivering a failing message from a domain it trusts and rejecting one from a domain it does not, and DMARC does not oblige it to do otherwise.

What is consistent is the direction of travel. A policy of none asks for no change in handling. A policy of quarantine asks that failures be treated as suspicious, which in practice usually means the spam folder. A policy of reject asks that failures be refused during the SMTP conversation, which means the sender gets a bounce and the recipient never sees the message — including when the sender was you and the failure was a system nobody remembered.

A staged rollout

Every stage below is driven by the same question: does every legitimate source produce an aligned pass. Aggregate reports are the only source of that answer, which is why rua is published on the first day and never removed.

• Publish p=none with rua, and change nothing else. Collect at least two full reporting cycles, and longer if the domain sends monthly or quarterly mail such as invoices or statements.
• Work through the sources the reports reveal. For each, either fix authentication until it aligns, or establish that it is not yours.
• Move to p=quarantine with a low pct value if the domain's volume makes a staged sample meaningful, and watch the reports for a fall in aligned pass rates rather than a rise in complaints.
• Raise pct to 100 at quarantine and hold there until a full business cycle has passed with no new sources appearing.
• Set sp=reject before p=reject. Subdomains are rarely used for real mail and are a favourite of spoofers, so they can usually be locked down well ahead of the parent.
• Move to p=reject, and keep reading the reports. A policy is not a project that finishes; new sending systems are added to organisations continuously.

The sources that break first

Certain patterns fail DMARC predictably, and finding them in the reports at p=none is the whole purpose of that stage.

• Mailing lists, which rewrite the subject and append a footer, breaking DKIM, and relay from their own host, breaking SPF. Many now rewrite the From header into their own domain specifically to survive DMARC.
• Forwarding, whether a university alias or a personal rule that pushes mail to another account. SPF fails; DKIM survives if nothing was altered.
• Third-party platforms sending as your domain — invoicing, ticketing, survey, applicant tracking — which often sign with their own domain and so pass DKIM without aligning.
• Bounce and notification systems configured with a header From at your domain and no authentication at all, because nobody expected a reply.
• Departmental sign-ups, which appear in the reports as a modest but persistent volume from a platform nobody in the mail team has heard of.

Knowing when you are ready for reject

The condition is not a date and not a percentage anyone else can supply. It is that every source in the aggregate reports is one you recognise, and that each one either shows an aligned pass or is a source you have decided you are content to have rejected.

Two details are worth confirming before the change. The first is that at least one mechanism aligns for each source, not merely that some mechanism passed — an unaligned pass is a DMARC failure. The second is that low-volume, high-importance mail is represented in the reports at all: a monthly statement run or an annual renewal notice can be invisible in a fortnight of data and still be the most damaging thing to reject.