Rolling Out DMARC Without Breaking Your Email: A Step-by-Step Plan

DMARC is the DNS record that tells mail providers what to do with a message that claims to come from your domain but fails authentication. Set to reject, it stops criminals sending fake invoices in your name. Set to reject too early, it stops your own invoices, payroll slips and password resets as well. Both outcomes are common, and the second one is entirely avoidable.

Our earlier article on why website emails land in spam covers SPF, DKIM and DMARC in outline. This one is about the part that goes wrong: getting from no policy to an enforced one without losing legitimate mail on the way. It is the process our email deliverability service follows, and it is measured in weeks rather than days, most of them spent waiting for reports.

What DMARC Actually Checks

DMARC adds one idea to SPF and DKIM: alignment. It is not enough for a message to pass SPF or carry a valid DKIM signature. The domain that passed has to match the domain in the From address the recipient sees. A newsletter platform that sends with its own domain in the technical headers and signs with its own DKIM key passes SPF and DKIM for itself, and still fails DMARC for you.

A message passes DMARC if either SPF or DKIM passes and aligns. In practice DKIM matters more, because SPF breaks when mail is forwarded and DKIM usually survives. Every service that sends as your domain should sign with a DKIM key published in your DNS.

Step 1: Publish a Monitoring Policy

Start with a DMARC record at policy none, with an address for aggregate reports: a TXT record at _dmarc on your domain, along the lines of v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. Policy none changes nothing about delivery. It asks receivers to send you a daily summary of every message they saw claiming to be from your domain, and whether it passed.

Google and Yahoo now expect a DMARC record from anyone sending large volumes to their users, so many domains already have a p=none record. Publishing it is the start, not the end. Two practical points: use a dedicated mailbox or a report-processing service, because reports arrive as compressed XML and a busy domain produces many a day; and if the reports go to a different domain from your own, that domain must publish a small authorisation record or receivers will not send them.

Step 2: Read the Aggregate Reports

Each report lists sending IP addresses, how many messages each sent, and the SPF and DKIM results with the domains they aligned to. Raw, they are unreadable. Processed into a table grouped by sender, they are the most complete picture of your email you will ever have. Sort what you see into three buckets:

• Legitimate and passing. Usually your main mailbox provider, such as Microsoft 365 or Google Workspace, properly configured. Nothing to do.
• Legitimate and failing. Services you use that send as your domain without aligned authentication. This is your work list.
• Not yours. Servers you do not recognise sending as your domain. Some will be forwarding, where a recipient's mailbox passes your message onward; most of the rest is spoofing. Enforcement is what stops it.

Give it at least a month. Monthly senders such as invoicing runs, payroll and statements will not appear in the first week, and they are exactly the messages you cannot afford to block.

Step 3: Find Every Sender, Including the Forgotten Ones

Reports show IP addresses. Turning those into a list of services means asking around the business as well as reading data. The senders we find most often:

• The website itself: contact forms, order confirmations and password resets, often still sent from the web server.
• A transactional email service set up by a previous developer.
• The newsletter or marketing platform.
• CRM, helpdesk and live chat tools, which send replies as your staff.
• Accounting and invoicing software sending invoices and reminders.
• Booking systems, payroll providers, e-signature tools and survey tools.
• An old server, a scanner or a script that emails reports in the middle of the night.

For each legitimate sender the fix is the same: set it up to sign with DKIM for your domain, using the records the service gives you, and where possible a custom bounce domain so SPF aligns too. If a service cannot align, move it to a subdomain such as notify.yourdomain.com with its own records, or stop it sending as your main domain. Keep SPF to one record and within its limit of ten DNS lookups; adding every service's include line is the quickest way to break SPF entirely.

Website mail is the sender we fix most often, by routing it through an authenticated transactional service instead of the server. On WordPress and WooCommerce sites that is usually a plugin and a few DNS records, and it is a sensible item for any maintenance plan.

Step 4: Move to Quarantine, Gradually

When the reports show every legitimate sender passing with alignment for a few weeks, move to p=quarantine. Failing messages now go to spam rather than the inbox. If something was missed, it lands in junk rather than disappearing, which is why quarantine comes before reject.

You can soften the step further. The pct tag asks receivers to apply the policy to only a percentage of failing mail, and some teams step through 25, 50 and 100 percent. Support for partial enforcement varies between providers and the standard is being revised, so treat it as a way to slow down rather than a precise dial. Subdomains can be handled separately with the sp tag, which helps when an old subdomain still has senders you are chasing.

Tell the people who handle customer queries before you change the policy, so that "the customer never got the invoice" is recognised as a possible DMARC issue rather than a mystery.

Step 5: Reject, and Keep Watching

After a clean period at full quarantine, move to p=reject. Receivers now refuse failing mail outright, and your domain is properly protected against direct spoofing. Keep the report address in place. New tools are added to businesses all the time, usually by someone who has never heard of DMARC, and the reports are how you find out before customers do.

Add one question to the process for adopting any new tool: will this send email as us, and if so, is DKIM set up before it goes live? That single line prevents most of the problems we are later asked to fix.

BIMI Comes Last, if at All

BIMI lets supporting mail providers show your logo beside authenticated messages. It is tempting to start there because it is the visible part. It cannot work until DMARC is at quarantine or reject across the domain, and the major providers generally also require a mark certificate from an approved authority, which has its own cost and, for some certificate types, a registered trademark. Treat it as a reward for finishing the rollout, not a reason to rush it.

A Rollout Checklist

1. Publish p=none with a report address, and process the reports.
2. Collect at least a month of data, covering monthly sends.
3. List every legitimate sender and give each aligned DKIM.
4. Keep SPF to one record, under ten lookups.
5. Move to quarantine, warn the support team, watch for a few weeks.
6. Move to reject, keep the reports, and add DKIM to the new-tool process.
7. Only then, consider BIMI.

DNS changes like these are where a small typo has large effects, so if your records are spread across a registrar, a host and a CDN, our hosting and DNS team can tidy them first. Spoofing protection is also one of the things a security audit should check. If you want a second pair of eyes, send us your domain name; we will read your current SPF, DKIM and DMARC records and tell you which step you are on.