Skip to content
Talvara

Deliverability

Getting DMARC to enforcement without breaking mail

Publishing p=reject takes thirty seconds. Publishing it without silently destroying a year of legitimate correspondence takes about four months, and almost all of that time is measurement.

Marek Sildaru, Technical Director 8 min read

Every few months a client arrives having read that DMARC enforcement is a security baseline, published p=reject over a weekend, and spent the following fortnight discovering which business processes depended on mail they had just instructed the world to throw away. The invoice runs are usually the first casualty; the recruitment platform is usually the second. The protocol is not the difficult part; the difficult part is that most organisations do not know what sends mail as them, and DMARC is unforgiving about that.

Start by accepting that p=none is not an achievement

A policy of none asks receivers to report but take no action. A domain sitting there for three years with nobody reading the reports has the same posture as one with no DMARC record at all. What it buys is visibility, and only if you publish a rua= address and process what arrives: aggregate reports are the only view you get of mail sent in your name from infrastructure you do not control.

Collect for at least two full business cycles. Monthly invoicing, quarterly statements and the payroll provider that writes each January will not appear in a fortnight's sample — and those are the messages whose loss gets noticed.

What to key on in the reports

An aggregate report is a set of records, each summarising messages from one source IP. Four fields matter:

  • The source IP and its resolved host. This is what turns "unknown sender" into "the marketing automation tool procured in 2023".
  • The evaluated SPF and DKIM results, and the domains they were evaluated against. A report can show SPF passing while DMARC fails; this is the most common source of confusion.
  • The alignment outcome for each mechanism. A pass that does not align contributes nothing. This is the field to sort by.
  • The message count. Ten thousand failures from one source is a project. Three is probably somebody forwarding to a personal address.

Build a register: source, owner, business purpose, current state, target state. The register is the deliverable; everything after it is mechanical.

The three failure modes that cause the damage

1. Third-party platforms that authenticate under their own domain

A platform sends on your behalf with an envelope sender and a DKIM d= pointing at its own domain, while the visible From: is yours. Every basic checking tool reports SPF passing. Nothing aligns, so DMARC fails for one hundred percent of that traffic.

The fix is a delegated subdomain — a CNAME for something like mail.example.eu pointing at the vendor, plus a per-tenant DKIM key under your domain. Essentially every serious platform supports it; remarkably few customers have switched it on, because the default worked well enough to close the onboarding ticket.

2. Forwarding

A forwarding host generally preserves the envelope sender while connecting from its own address, so SPF fails at the destination. This is correct behaviour and nothing you publish will change it. It is the reason to treat aligned DKIM as the primary path to a pass — a signature travels with the message and survives a forward, provided nothing rewrites the content.

Mailing lists are the harder case, because many do rewrite — a footer appended, a tag added to the subject — and that breaks the signature. ARC lets a participating receiver see that authentication passed before the message was altered, but it is an input to their judgement rather than a guarantee. Plan for a residual tail of list traffic that will fail, and know which lists your staff use before you enforce.

3. The SPF lookup ceiling

SPF evaluation permits ten DNS-querying mechanisms. Exceed it and you get a permerror, which many receivers treat as a failure — so a record that worked last year can break without you touching it, because a vendor expanded their own nested include. Audit the budget whenever you add a sender.

The ramp

Once the register is complete and the high-volume sources align, move in stages:

  1. Subdomains first. Set sp=quarantine while the organizational domain stays at none — a real enforcement test with a smaller blast radius. For subdomains that never legitimately send, the tag for non-existent subdomains lets you reject outright.
  2. Then p=quarantine. Hold four to six weeks with someone reading the reports weekly. Quarantine is recoverable — a user can retrieve mail from a spam folder. Reject is not.
  3. Then p=reject. Safe once the aligned-pass rate has been stable above roughly 98% for a month and every remaining failure is explained. If you cannot explain the remaining 2%, you are not ready.

A percentage ramp via pct= is widely honoured and useful for spreading the transition, but treat it as temporary scaffolding: the DMARC revision progressing through the IETF removes it.

Do not enforce on a Friday. Enforcement failures are invisible to the sender — there is no bounce, because the rejection happens on someone else's server. They are reported by recipients, who need somebody available to report them to. Tuesday morning, with the register open and the previous policy value written down, is the whole trick.

Afterwards

Enforcement is not a finished state. New sources appear the moment a department buys a tool, and at p=reject a new source's mail simply vanishes. Keep ingesting reports, alert on sources you have not seen before, and review the register quarterly. The organisations that hold enforcement comfortably are the ones who kept reading the reports afterwards.

Marek Sildaru

Technical Director and co-founder, Talvara

Marek spent eleven years operating mail transport at scale before co-founding Talvara in 2017, and owns the technical standards the firm holds itself to.