SPF, DKIM, and DMARC are three small records in your domain's DNS settings that answer three questions: who is allowed to send email as you, is this message really from you and unmodified, and what should happen if the answer to either is no. Set them up correctly and your mail lands. Leave them out and mail providers increasingly assume the worst.
None of this is new technology. What changed is enforcement. Gmail and Yahoo now require these records from anyone sending mail in volume, and the definition of volume keeps moving down. That is why email that worked fine for years can start landing in spam without you touching anything.
The mail room analogy
Imagine your business sends physical letters and someone in the recipient's mail room has to decide whether each one is genuine.
SPF is the return address list. You publish, in public, the list of post offices allowed to send letters on your behalf. If a letter claiming to be from you arrives from a post office that is not on the list, that is a signal something is wrong.
DKIM is the wax seal. Every letter you send is sealed with a stamp only you can make. The mail room checks the seal. If it matches, the letter really came from you and nobody steamed it open and changed the contents on the way.
DMARC is the standing instruction. It is the note you leave with every mail room in the world saying: if a letter claiming to be from us has no valid return address and no valid seal, here is what I want you to do with it. Bin it. Hold it aside. Or, for now, deliver it but tell me about it.
That third one is the part most businesses skip, and it is the one that does the actual work. SPF and DKIM produce evidence. DMARC tells the recipient what to do with the evidence.
SPF: who is allowed to send as you
SPF is a single line in your DNS that lists the servers permitted to send email using your domain name. In practice that is usually your mailbox provider, your website (for contact form notifications, order confirmations, password resets), and any third-party tools that send on your behalf — an email newsletter platform, an invoicing system, a booking tool.
The common failure is not a missing SPF record. It is an incomplete one. A business sets up SPF when they move to a new mail provider, then eighteen months later adds a newsletter tool or a new checkout plugin, and nobody updates the record. The new sender is not on the list. Its mail starts failing checks quietly, and the only symptom is customers saying they never got the email.
SPF also has a limit that catches people out: it allows a limited number of lookups, and stacking too many services into one record breaks it entirely. When that happens the record does not half-work. It fails.
DKIM: is this really from you, and unchanged
DKIM adds a cryptographic signature to every message you send. The receiving server fetches your public key from your DNS and checks the signature. If it matches, two things are proven at once: the message came from a system holding your private key, and the content was not altered in transit.
DKIM is stronger evidence than SPF because it travels with the message. If your email is forwarded — which happens constantly, since plenty of people forward business addresses to a personal inbox — SPF usually breaks, because the forwarding server is not on your list. DKIM survives the trip. That is why you want both, not one.
DMARC: what happens when the checks fail
DMARC does two jobs. It sets your policy, and it gets you reports.
The policy has three settings. None means deliver as normal but send me reports. Quarantine means put failures in spam. Reject means refuse them outright. The right path is to start at none, read the reports for a few weeks to find every legitimate system sending as you, fix anything you missed, then tighten to quarantine and eventually reject.
Jumping straight to reject without doing the reading is how businesses accidentally block their own invoices. This is the one part of the process that genuinely benefits from patience. There is no prize for tightening the policy on day one.
The reports are the underrated half. Once DMARC is live, you get a feed of who is sending mail claiming to be your domain. Sometimes that is a forgotten tool you set up years ago. Sometimes it is someone impersonating you.
Why "it worked last year" stops being true
Email authentication used to be a best practice. It is now a gate. The large mailbox providers have moved steadily from "we prefer this" to "we require this", and each tightening catches a fresh set of businesses who did nothing wrong except stand still.
Three things also drift on their own. Your senders change — new plugins, new tools, a new payment processor, all sending on your behalf. Your hosting changes, and a migration that does not carry the records across breaks them silently. And the thresholds move: what counted as a low-volume sender exempt from the strict rules two years ago may not count as one now.
The result is a category of problem with no error message. Nothing crashes. There is no red banner. Mail just stops arriving for a slice of your customers, and you find out weeks later when someone mentions it in passing. It belongs to the same family of quiet failures as untested backups and expired certificates — the kind we write about in calmer website operations, where the goal is that nothing surprises you.
The special danger for sites that send transactional email
If your website only sends the occasional contact form notification, a delivery failure is annoying. If your website sends order confirmations, receipts, appointment reminders, quotes, or password resets, a delivery failure is a business problem with a delay built in.
Password resets are the sharpest example. A customer who cannot reset their password cannot log in, cannot check their order, and cannot buy anything. They do not email support to report a deliverability issue. They assume your site is broken and go somewhere else. You never hear about it.
Order confirmations are almost as bad. A customer who pays and gets nothing in return usually assumes the payment failed. Sometimes they pay twice. Sometimes they file a chargeback. Either way, you spend time cleaning up a mess caused by a DNS record nobody was watching.
There is a second half to this. WordPress sends mail from the web server by default, which is one of the least trusted ways to send email. Routing your site's transactional mail through a proper authenticated sending service, rather than straight out of the server, is one of the higher-value hours anyone can spend on a small business site. It is standard practice in the way we handle ongoing maintenance and security.
How to tell if yours is broken right now
You do not need tooling to get a rough answer. Send yourself a message from your website — trigger a real order confirmation or a password reset, not a manually typed email — to a Gmail address you control. Open it, view the original or the message details, and look for SPF, DKIM, and DMARC lines. You want to see "pass" next to all three. Anything else is worth a conversation.
Do the same for each system that sends on your behalf. The mistake is testing one and assuming the rest are fine. Your mailbox provider and your website are different senders, and they can pass and fail independently.
What we do about this
We set up SPF, DKIM, and DMARC on every mailbox we host, and we make sure the website's own outgoing mail is authenticated too. It is part of the setup, not an add-on. Mailboxes are $2 a month flat, and the records come configured.
When we take over an existing site during a migration, checking email authentication is on the list before we move anything, because a migration is exactly the moment these records get dropped. Most sites we take over have SPF and no DKIM, or all three records written by three different people over five years with nobody sure which ones are still live.
We do not think this needs to be your problem. It is a small piece of infrastructure that goes quietly wrong and costs real money when it does. That is the sort of thing a host should be handling. If you want to know whether yours is set up correctly, send us a note and we will look.
Frequently asked questions
Do I need all three, or is one enough?
All three. SPF and DKIM each prove something different, and each fails in situations where the other works — SPF breaks when mail is forwarded, DKIM does not. DMARC is what makes either of them matter, because without it you are producing evidence that nothing acts on.
Will setting up DMARC stop my email from being delivered?
Not if you do it in the right order. Start with a policy of none, which changes nothing about delivery and simply produces reports. Use those reports to find every legitimate sender, fix what is missing, and only then tighten the policy. Problems come from tightening first and reading later.
My email works fine today. Why should I bother?
Because "works fine today" is not the same as "will keep working". The requirements tighten on a schedule you do not control, and your list of senders grows every time you add a tool. Setting these up correctly is a one-time job that takes an hour. Finding out they were wrong usually takes a customer telling you they never got their receipt.
