SPF, DKIM, and DMARC: Email Authentication in Plain English

Every day your business sends email that customers, vendors, and staff are supposed to trust. The problem: by default, nothing about standard email actually proves who sent it. That gap is exactly what attackers exploit when they spoof your domain to send convincing invoices, wire-transfer requests, and password-reset lures that look like they came from you. Three email-authentication standards — SPF, DKIM, and DMARC — close that gap. Here is what each one does, in plain English, and how to roll them out without knocking your own mail offline.

Why email needs authentication at all

The core email protocol was designed in a more trusting era. The "From" address you see is just a label — a sender can type almost anything there, the same way you can write any return address on a paper envelope. Authentication adds a way for receiving mail servers to check that a message claiming to be from your domain was really authorized by you. Get it right and two things improve at once: attackers can no longer impersonate your domain, and your legitimate mail is far less likely to land in spam.

SPF: who is allowed to send for you

Sender Policy Framework (SPF) is a public list of the mail servers permitted to send email using your domain. You publish it as a DNS record. When a receiving server gets a message that claims to be from you, it checks whether the sending server appears on that list.

The catch most businesses hit: you probably send mail from more sources than you think — your email platform (Microsoft 365 or Google Workspace), your marketing tool, your invoicing or CRM system, maybe a helpdesk. Every legitimate source has to be included, or its mail can fail. Build the list carefully and keep it within the standard's limit of ten DNS lookups; quietly overflowing that limit is a common way SPF breaks.

DKIM: a tamper-proof seal

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every message you send. Your mail server signs outgoing email with a private key, and you publish the matching public key in DNS. The receiving server uses it to confirm two things: the message really came from your domain, and it was not altered in transit. Think of it as a wax seal that proves both who sent the envelope and that no one opened it along the way.

DKIM matters even more than SPF in one common case: forwarded mail. SPF often breaks when a message is forwarded, but a DKIM signature usually survives — so the two standards cover each other's gaps.

DMARC: the policy that ties it together

SPF and DKIM each answer a question, but neither tells receiving servers what to do when a check fails — and neither, on its own, protects the exact address your customers see. DMARC (Domain-based Message Authentication, Reporting and Conformance) fills both gaps. It lets you publish a policy that says, in effect, "if a message claiming to be from my domain fails these checks, here is what to do with it," and it makes sure those checks line up with the visible From address.

A DMARC policy has three settings worth knowing:

• p=none — monitor only. Nothing is blocked, but you start receiving reports about who is sending mail as your domain. This is where everyone should begin.
• p=quarantine — send failing mail to spam.
• p=reject — refuse failing mail outright. This is the goal: it is what actually stops spoofed email from reaching anyone.

DMARC also turns on reporting. Those reports are gold: they show every service sending mail under your name, which quickly surfaces both the legitimate tools you forgot about and the impostors you did not know existed.

How to roll it out without breaking your mail

The single biggest mistake is jumping straight to p=reject before your legitimate senders are all passing. Do it in order:

1. Inventory every sender. List every system that sends email on your behalf, including marketing, billing, and support tools.
2. Publish SPF and DKIM for each of those sources and confirm they pass.
3. Start DMARC at p=none and read the reports for a few weeks. Fix any legitimate sender that is failing.
4. Move to p=quarantine, watch for fallout, then advance to p=reject once the reports are clean.

Rushed, this process sends your own newsletters and invoices to spam. Done in stages, it is invisible to everyone except the attackers it locks out.

Where this fits in a bigger picture

Email authentication is one of the highest-return security controls a small business can put in place: it is inexpensive, it directly blunts the phishing and invoice-fraud attacks that cause real losses, and it improves deliverability as a bonus. But it protects the domain, not the inbox — it will not stop a look-alike domain or an account that has already been compromised. Pair it with multi-factor authentication, phishing awareness, and monitoring for the full picture. Our cybersecurity team configures SPF, DKIM, and DMARC as part of standard onboarding, precisely because the payoff is so high for the effort.

Key takeaways

• Standard email does not prove who sent it — SPF, DKIM, and DMARC add that proof.
• SPF lists who may send for your domain; DKIM cryptographically seals each message; DMARC sets the policy and reports on abuse.
• Only DMARC at p=reject actually stops spoofed mail from reaching recipients.
• Roll out in stages (none → quarantine → reject) so you never send your own mail to spam.
• It protects your domain, not your accounts — combine it with MFA and phishing training.

Not sure whether your domain can be spoofed right now? A quick check often shows that it can. Get your AI & Cyber Risk Review and we will tell you exactly where your email and identity defenses stand — and what to fix first.