DMARC: start at none, read the reports, then tighten

DMARC is a DNS record that tells receiving mail servers what to do with messages claiming to come from your domain that fail authentication, and where to send reports about them. It sits on top of SPF and DKIM: those two decide whether a message is authenticated, DMARC decides what happens when it is not — and, crucially, requires that the authenticated domain aligns with the visible From address.

Alignment is the part that surprises people. A message can pass SPF for a sending platform’s own domain and still fail DMARC, because the domain that passed is not the domain in the From header. That is exactly the gap DMARC was designed to close, and it is why adding DMARC often reveals that mail you thought was authenticated is not.

What a DMARC record contains

• The policy: none, quarantine or reject — what receivers should do with failures.
• Reporting addresses: where aggregate reports go, and optionally where forensic reports go.
• The percentage of mail the policy applies to, useful for phased rollout.
• Alignment mode for SPF and DKIM: relaxed, which allows subdomains, or strict.
• Subdomain policy, where it should differ from the organisational domain.
• Nothing about the spf record itself — DMARC references the result of that check rather than repeating it.

The rollout that does not break mail

1. Publish p=none with a reporting address. This changes nothing about delivery and starts the flow of data.
2. Read the aggregate reports for several weeks. They are XML, and a parser or a service makes them legible.
3. Build the inventory the reports reveal: your mail platform, the CRM, the invoicing system, the ticketing tool, the marketing platform, the payroll provider — anything that sends as you.
4. Fix each legitimate sender so it passes with alignment: usually DKIM signing with your domain, sometimes a subdomain of your own.
5. Move to p=quarantine, first on a percentage, and watch the reports again.
6. Move to p=reject once the reports show only unauthorised mail failing.

Publishing p=reject on day one is the classic self-inflicted outage. Invoices from the finance system, password resets from the app and campaigns from the marketing platform all vanish silently, and the people affected are your customers rather than your team. The reports exist so that this discovery happens before the policy, not after. Treat the rollout as an email deliverability project with a measurement phase, not as a DNS edit.

Reading aggregate reports without drowning

Aggregate reports arrive daily from each receiver, describing volumes by source IP with pass and fail counts. What you are looking for is not perfection but pattern: a source you recognise that is failing needs fixing, a source you do not recognise needs investigating, and a long tail of small failing sources is usually forwarding rather than abuse.

Forwarding is the standard complication: when a message is forwarded, SPF breaks because the forwarding server is not in your record, while DKIM usually survives. This is one reason DKIM alignment matters more than SPF alignment in practice.

Where mail runs on your own domain, the records and the reporting mailbox sit together with it. Ettex Mail hosts the mailboxes and receives the aggregate reports at an address you control, so the rollout is something you can watch rather than delegate blindly. What DMARC cannot do is make unauthenticated mail deliverable — that is what fixing the senders is for, and there is no record you can publish instead.