SPF, DKIM and DMARC: The Three DNS Records That Decide Whether Your Email Arrives

A recruitment firm told us their email had stopped working. Not bouncing — worse than bouncing. Messages left their outbox, showed as sent, and simply never appeared for a meaningful share of recipients. No error, no notification, nothing to investigate. They had been quoting for work into silence for weeks before anyone connected the dropped conversations to a delivery problem, and by then they had also concluded, wrongly, that their market had gone quiet.

The cause was three DNS records: one missing, one written years ago and never updated, and one that had never existed. This is now among the most common invisible failures in small-business marketing, and it is entirely fixable in an afternoon by someone who can edit DNS.

Why This Suddenly Matters

Domain authentication is not new — SPF has been around since the early 2000s. What changed is enforcement. Google and Yahoo both published sender requirements that took effect in 2024, and the substance is that bulk senders must authenticate their domain with SPF and DKIM, publish a DMARC policy, keep unsubscribe handling clean, and stay under a spam-complaint threshold. Microsoft has since moved in the same direction for high-volume senders.

The practical effect is that authentication moved from a deliverability nicety to a precondition. An unauthenticated domain sending any volume is no longer treated as merely suspicious. It is increasingly treated as unwanted, and the filtering happens silently.

What Each Record Actually Does

The three work together, and the usual confusion comes from assuming they are alternatives. They are not — each answers a different question.

SPF answers: is this server allowed to send as my domain?

SPF is a single DNS TXT record listing the services permitted to send email using your domain. Your mail provider, your marketing platform, your CRM, your invoicing tool, the contact form on your website. A receiving server checks whether the sending server appears on that list.

The most common SPF failure is not absence. It is staleness: a record written when the company used one mail provider, never updated through two platform migrations, still authorising a service nobody has logged into in years while omitting the one currently sending the invoices.

DKIM answers: was this message altered in transit, and did my domain really sign it?

DKIM adds a cryptographic signature to outgoing mail. The sending service holds a private key; you publish the matching public key in DNS. A receiver verifies the signature, which proves both that the message came from something holding your key and that the content was not tampered with along the way.

Every mail platform worth using generates DKIM keys for you and shows you the record to publish. The work is entirely on your side: actually publishing it, for every service that sends on your behalf.

DMARC answers: what should a receiver do when the first two fail?

DMARC is the policy layer, and it is the one most small businesses have never heard of. It tells receiving servers what to do with mail claiming to be from your domain that fails SPF and DKIM: take no action, treat it as suspicious, or reject it outright. It also asks receivers to send you reports about what is being sent using your domain name.

Those reports are the genuinely valuable part, and almost nobody reads them. They are how you discover that a supplier is sending on your behalf from a service nobody told you about, or that somebody is spoofing your domain in invoice fraud aimed at your own customers.

The Order to Do This In

Sequence matters, because it is entirely possible to publish a strict policy and cut off your own accounting software. Do it in this order.

1. Inventory every service that sends email using your domain. Mail provider, marketing platform, CRM, e-commerce, booking system, helpdesk, invoicing, website forms. This list is always longer than the first draft, and the forgotten entry is what breaks later.
2. Publish or correct SPF so it authorises exactly those services and nothing else. One SPF record per domain — a second one invalidates both, and this is a frequent and confusing failure.
3. Enable DKIM on every one of those services and publish each key. Do not skip the low-volume ones; a single unsigned sender is enough to keep you from tightening the policy later.
4. Publish DMARC in monitoring mode first, with a reporting address. This changes nothing about delivery and starts the flow of reports.
5. Read the reports for a few weeks. You are looking for legitimate senders that are failing, which is exactly the list of things you missed in step one.
6. Only once legitimate mail passes cleanly, tighten the policy from monitoring toward quarantine, and then toward rejection.

Businesses that skip straight to a strict policy usually discover the omission when a customer complains that their invoice never arrived. The monitoring period exists precisely to make that discovery cheap.

Where the Records Live, and Who Should Touch Them

All three are DNS records on your domain, edited wherever your DNS is hosted — often the registrar, sometimes the hosting company, sometimes a CDN. That location is the first thing to establish, and in a surprising number of small businesses nobody currently knows. Finding out is not optional; a company that cannot edit its own DNS cannot fix its own email, and cannot move hosting either.

The work itself is well within reach of a technically comfortable owner. What it needs is care rather than expertise: DNS changes propagate, mistakes are not instantly visible, and a typo in an SPF record fails quietly rather than loudly. If you would rather not, this is a small and well-defined job to hand to whoever manages your website — but ask for the reports to be sent somewhere you can read them, not only to the person doing the work.

How to Tell If This Is Your Problem

Two quick checks before you commit an afternoon to it. First, send a message from your normal business address to a personal address at a large consumer mail provider, open it, and look at the message details or original — it will state plainly whether SPF and DKIM passed. Second, check whether a DMARC record exists on your domain at all, using any of the free public lookup tools.

If SPF or DKIM fails on your own everyday mail, stop reading and fix it this week. That is not a marketing optimisation. That is your quotes, your invoices and your replies landing in spam folders belonging to people who assume you never got back to them.

← Back to all articles