Email

Getting your email to actually arrive: SPF, DKIM and DMARC

Three records decide whether your email reaches the inbox or the spam folder, and unlike almost everything else that can go wrong, this one tells you nothing when it does. Here is what each one does, in plain terms.

ByAlan Herbert1 September 202611 min read

Almost everything that goes wrong with a website tells you about it. A page errors, a form throws a message, a link goes nowhere and somebody mentions it. Email is the exception. When your email stops reaching people, nothing happens at all. There is no error, often no bounce, and no notification. Your messages simply arrive in spam folders, or quietly nowhere, and the only symptom is that people seem slower to reply than they used to be.

This is why it is worth an hour of anybody’s attention, even though it is the least interesting subject in this series. It is the only problem here that can be costing you money today without producing a single clue that it is happening.

What the three records actually do

All three live in your DNS, which is the public record that tells the internet how your domain works. They exist because email was designed in an era when nobody expected anyone to lie, so by default anybody can send a message claiming to be from your address. These three records are the patches for that.

SPF is a list of who is allowed to send email on your behalf. It names the services permitted to send using your domain, so a receiving mail server can look up your list and see whether the message came from somewhere on it. Think of it as a guest list on the door.

DKIM is a signature. Your mail server signs each message on the way out, and the receiving server checks that signature against a key published in your DNS. If it matches, the message genuinely came from you and has not been altered in transit. Think of it as a wax seal.

DMARC is the policy that ties the other two together. It tells receiving servers what you would like them to do with a message that fails the first two checks, and, importantly, it asks them to send you reports about what they are seeing. Think of it as the standing instruction to the doorman, plus a nightly summary of who tried to get in.

You need all three. SPF and DKIM answer questions, and without DMARC nobody knows what to do with the answers.

You have more senders than you think

This is where most businesses come unstuck, and it is worth doing properly before touching anything.

Almost nobody sends email from only one place. There is your actual mail system, which for many businesses is Microsoft 365 or Google Workspace. Then there is your website’s contact form, which sends through something. Your accounting software sends invoices. Your booking or ticketing system sends confirmations. Your newsletter tool sends campaigns. Your support desk sends replies. A payment provider sends receipts.

Every one of those is sending mail claiming to be from your domain, and every one of them needs to be on the list. Getting SPF technically correct while forgetting that your invoicing software exists is how businesses discover, several weeks later, that their invoices have been going to spam.

So the first job is not a DNS change, it is a list. Write down everything that sends email as you, including the things somebody set up years ago and nobody thinks about. That list is the work.

The bit that trips people up

There is one concept worth understanding, because it explains most of the confusion.

It is not enough for SPF or DKIM merely to pass. For DMARC to be satisfied, the domain that passed the check has to match the domain in the “From” address that the recipient sees. This is called alignment, and it is why a message can pass SPF perfectly and still fail DMARC.

The common version of this problem is a third-party service that sends on your behalf, passing SPF for its own domain rather than yours. Everything looks fine in the technical detail and DMARC still fails, because the thing DMARC cares about is whether the name on the envelope matches the name that was actually verified. Most reputable services have a setup step that fixes this, usually described as authenticating or verifying your domain, and it is a step people skip.

The rules changed, and they probably do not apply to you

You may have been told that this is now mandatory. That is worth being precise about, because the honest position is more interesting than the scare.

Google and Yahoo introduced requirements in February 2024 for bulk senders, meaning those sending roughly 5,000 messages or more a day to personal accounts. Those senders need SPF and DKIM in place, aligned so that DMARC passes, and a DMARC record published with a policy of at least none. Microsoft brought in comparable requirements for high-volume senders to its consumer addresses from May 2025, with mail from non-compliant domains liable to be rejected outright.

Five thousand messages a day is a great deal of email. Unless you run a substantial mailing list, none of this applies to you by the letter of the rule, and anybody telling you that you must comply or be blocked is overstating it.

Here is why you should do it anyway. Those thresholds tell you where the industry is heading, and the same signals that decide whether a bulk sender is accepted also feed the spam scoring applied to everybody else. Authentication has moved from a good idea to an expectation. A small business with none of it in place is not blocked, it is simply treated with more suspicion than the business next to it that has it, every single time it sends a message.

Start at none and read the reports

The mistake people make, having understood the above, is to jump straight to a strict policy. Do not.

DMARC has three settings. None means “do not change how you handle it, but tell me what you are seeing”. Quarantine means “put failures in spam”. Reject means “refuse them outright”. Start at none, always, and leave it there for a few weeks.

The reason is that the reports you get back at none will show you every service sending as you, including the ones missing from the list you wrote earlier. Almost everybody discovers something they had forgotten. Moving straight to reject without that period is how a business discovers it has stopped its own invoices from being delivered, and the failure mode is silent in exactly the way described at the start of this article.

The reports themselves arrive as XML and are close to unreadable by eye. There are inexpensive services that turn them into something a human can understand, and for a small business one of those for a couple of months, while you get to a strict policy, is money well spent.

Once the reports are quiet and everything legitimate is aligned, move to quarantine, watch again, then to reject. Reject is the point of the exercise, because that is the setting that stops somebody sending mail pretending to be you.

What tends to go wrong

A handful of faults account for most problems. Two SPF records on the same domain is invalid, and it happens when somebody adds a second one rather than editing the first. There should be exactly one, containing everything.

Too many lookups. SPF has a hard limit of ten DNS lookups, and each service you include can consume one or more. Businesses with many senders hit this limit and the record silently stops working. If you are near it, that is a sign to consolidate rather than add.

Forgetting a sender, as above, which the reports will find for you.

Going strict too early, which is the one that causes actual damage.

And treating it as done. Every time you add a service that sends email as you, this needs revisiting. It is worth a note in whatever calendar reminds you about domain renewals.

How to check yours today

You do not need anything technical to get a rough answer. Send an email from your normal address to a personal Gmail account, open it there, and use the option to show the original or view the source. Near the top you will see lines for SPF, DKIM and DMARC, each saying pass or fail. Three passes and you are in reasonable shape. Anything else is worth looking into.

That takes two minutes and tells you whether the rest of this article is urgent or merely sensible.

Where to start

Write the list of everything that sends email as you. Do that before anything else, because every decision afterwards depends on it, and it is the part that needs you rather than a technician.

Then check what you have with the Gmail test above. If DMARC is missing entirely, publishing a record set to none costs nothing, changes nothing for your recipients, and starts the flow of information you need to fix the rest properly.

Where these facts come from

The sender requirements described above are published by the platforms themselves, and both are worth a look if you want the detail.

More articles