For years, email authentication was something for people sending newsletters to a hundred thousand addresses. Then Google and Yahoo introduced mandatory requirements above five thousand messages a day, Microsoft started rejecting — not junking, rejecting with an error — unauthenticated mail addressed to Outlook accounts, and the threshold keeps coming down.
But compliance is not why a small company should care. The reason is that without these three records, anyone can send an invoice in your domain's name, and your customer has no way to tell.
The three records, one sentence each
SPF states which servers are allowed to send email for your domain. It is a list published in DNS: the receiving server checks it and sees whether the sender was authorised.
DKIM signs every message with a cryptographic key. The public half sits in DNS, the private half on the sending server: the recipient verifies the signature and knows the content was not altered in transit.
DMARC is the rule that ties the first two to a behaviour. It tells the world: "if a message claims to come from my domain but passes neither aligned SPF nor aligned DKIM, do this" — where this can be nothing, quarantine, or reject.
On their own, SPF and DKIM protect nobody. They are checks whose results, without DMARC, the recipient is free to ignore.
The word that makes the difference: alignment
This is where almost every misconfiguration lives, and it is worth slowing down for.
An email has two senders: the technical one, used by servers to talk to each other, and the one the recipient sees in the "From" field. DMARC does not look at the first. It looks at the second, and it requires that the domain your customer sees is the same one SPF verified or DKIM signed.
That is why a setup can report "SPF: pass" and "DMARC: fail" at the same time. It happens routinely with newsletter platforms and with business systems that send on your behalf: the message passes SPF on the platform's domain, while the "From" field shows yours. Technically authenticated, and to DMARC, a stranger.
The order to do this in
The wrong way is to publish a strict policy straight away and see what happens. What happens is that invoices stop going out, and nobody connects cause to effect for a fortnight.
The right order has four steps.
- Take a census of who sends for you. It is nearly always more systems than the company remembers: company mail, the ERP sending order confirmations, the shop, the newsletter platform, the e-invoicing service, the website contact form, the CRM. Each one gets authorised, or gets moved to a different domain.
- Fix SPF and DKIM for each of those senders, checking alignment rather than just a "pass".
- Publish DMARC in observation mode. It blocks nothing and risks nothing: it only asks recipients to send you a report on what they see.
- Read the reports for two or three weeks, and tighten the policy only when they say every legitimate sender is in order.
That observation period is not excessive caution. It is where the forgotten service turns up — and there is nearly always one.
What the reports show you
DMARC reports arrive as daily XML, unreadable by eye and highly instructive once parsed. The three things that turn up most often:
- A legitimate sender nobody remembered. The agency that has been sending the newsletter for three years, the accountant's portal, an old server still humming in the office.
- A service sending without alignment. It passes the technical checks and fails DMARC, and the fix is configuring a custom sending domain on that platform.
- Somebody pretending to be you. Odd volumes from addresses with no connection to the business. That is the moment the exercise stops feeling bureaucratic.
The ten-lookup limit
One technical detail that catches out companies which grew by accumulation: SPF allows at most ten DNS lookups during evaluation. Every include: for an external service consumes at least one, sometimes more.
With Google Workspace, an ERP, a newsletter platform, an invoicing service and a CRM, the limit is crossed without anyone noticing — and once crossed, SPF does not fail loudly: it returns a permanent error, and depending on how the recipient treats that, mail lands in spam or is refused. The fix is consolidation, not another line.
What to expect from it
This is not marketing, it is maintenance. Done properly, email stops being a guess — messages arrive, and when they do not, a report says why. The domain stops being usable for impersonating your company. And the big providers' requirements are met before they turn into a wall.
The technical work takes a few hours. It is the observation that takes patience, and it is worth doing now, while nobody is waiting on an urgent invoice.