How to roll out DMARC without breaking your email

DMARC has two settings that people confuse: what it reports, and what it does. Reporting is free and safe. Enforcing is neither, until you know what you are sending. A rollout that respects that order takes a few weeks and usually ends with p=reject; a rollout that skips it takes an afternoon and ends with a support ticket about missing invoices.

What "breaking email" actually looks like

It is rarely dramatic. A customer says the invoice never arrived. A salesperson's follow-up gets no reply because it went to junk at the recipient. A booking confirmation silently disappears. Nothing bounces on your side, because the message left your infrastructure perfectly — it was rejected or quarantined after it arrived, by a policy you published.

The mechanism is worth internalising: p=quarantine and p=reject apply to messages that fail both SPF alignment and DKIM alignment. If any legitimate sender sends as your domain without one of those aligning, enforcement kills it.

Step 1 — inventory every sender

Before touching DNS, write a list. Ask accounts payable, sales and whoever runs the website. Every entry below is a real sender in a typical small business:

• Primary mailbox provider: Google Workspace, Microsoft 365, Zoho, or a hosted mail server.
• CRM and sales-engagement tools that "send as you".
• Invoicing and accounting platforms, including payment reminders.
• Helpdesk and ticketing systems, plus any form-to-email on the website.
• Scheduling tools, survey tools and newsletter platforms.
• Monitoring and alerting that emails from an application.
• The scanner that emails documents to accounts, and any device that sends mail.
• Agencies, freelancers and virtual assistants with delegated access.

If you cannot produce this list from memory, that is the finding. DMARC reports will complete it for you, which is the point of the next two steps.

Step 2 — make SPF and DKIM worth aligning to

For each sender, two questions: is it authorised in SPF, and does it sign with DKIM for your domain? Authorising in SPF alone is fragile, because SPF authenticates the envelope sender and breaks under forwarding. A DKIM signature made with a key published on your domain survives forwarding in many cases and is the more durable signal.

Most platforms will publish a DKIM key for your domain if you ask them to — look for a "domain authentication", "DKIM" or "sender authentication" setting. That is materially better than sending with the platform's own domain in the envelope while your domain sits in From, because that arrangement passes SPF for the platform and aligns for nobody.

Step 3 — publish monitoring first

Start with a policy that does nothing except collect reports:

_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r"

Two practical notes. Use a dedicated mailbox or a forwarding alias for rua=, not a person's inbox: aggregate reports arrive daily as XML attachments, one per reporting domain. And leave adkim and aspf relaxed (r) at this stage, which allows organisational-domain matching and avoids failing on legitimate subdomain senders you have not catalogued yet.

If you would rather not read XML, plenty of free and paid services will parse aggregate reports and present them as a table of source IPs and pass/fail counts. That is the one place in this process where a third-party service earns its keep — just check where the reports are being sent.

Step 4 — read the reports until they are boring

An aggregate report answers four useful questions per sending source: how many messages, whether SPF aligned, whether DKIM aligned, and what the receiver did with them. You are looking for two things: sources you did not know about, and volume from sources that fail both checks.

Two weeks of quiet reports — every legitimate source showing an aligned pass, and the failures being sources you can name — is your green light. If a failing source turns out to be real mail, fix the sender before continuing. If it is a marketing platform sending as your domain without DKIM, either configure its DKIM or move it to a subdomain you control.

Step 5 — enforce in small increments

pct= asks receivers to apply the policy to a percentage of failing messages, which is the closest thing DMARC has to a dial. It is imperfect — not every receiver honours it exactly — but it turns a cliff into a ramp. Once you are stable at p=reject, consider adding sp=reject so subdomains inherit the same treatment deliberately rather than by accident.

The three things that break, and their fixes

1. Forwarding. A university, a supplier or an old colleague forwards mail from your domain; the forwarding hop breaks SPF. DKIM alignment is the fix, because the signature survives if the message is not modified. This is the single strongest argument for real DKIM everywhere.
2. Mailing lists. Lists often rewrite the From address to the list's own domain, which removes your domain from the equation entirely — or leave it in place and modify the body, breaking DKIM. Ask list operators how they handle DMARC; most have a documented policy by now.
3. Subdomains. Without sp=, subdomains inherit the parent policy. If marketing sends from news.yourdomain.com through a platform you never configured, p=reject will start refusing it. Either configure that subdomain or publish an explicit sp= value.

If something breaks anyway

Get the original message headers from whoever reported the problem — the Authentication-Results line names which check failed and for which domain. Usually the answer is "DKIM did not align because the sender is a third party that was not in the inventory". Fix the sender, then re-run that reporting window.

Rolling back is one DNS edit: lower the policy to p=none and the refusals stop once the record propagates. That is worth knowing before you start, because it makes the rollout a reversible decision — and reversible decisions are the ones that actually get made in a small business.

What an external check can and cannot tell you

Anyone can read your published policy and see whether it is none, quarantine or reject. What an outsider cannot see is your aggregate reports — those are private, and should stay that way. They also cannot enumerate your DKIM selectors; they can only check the selector names they are given or can reasonably guess. Both limits are stated rather than hidden in the reference article, and the control catalog shows exactly which email checks this project performs.

What SMB Scanner Lite checks here

These are the controls from this area that the assessment evaluates from outside, without credentials and without touching anything private. Each one returns a status and, for every conclusive result, the record, header or handshake that produced it.

Only assess domains you own or are authorised to test — see responsible use. The published recorded assessment shows how a result and its evidence appear in a report, and the control catalog lists all 22 controls with their weights. Reference detail for this topic lives in SPF, DKIM and DMARC: how email authentication actually works.