SPF, DKIM and DMARC Explained Simply (With Real Examples)

If you run a business with its own email domain, someone has probably told you to "set up SPF, DKIM and DMARC". Maybe your invoices are landing in customers' spam folders, or your newsletter tool is showing warnings. The three acronyms sound like one technical chore. In fact, they're three different answers to a problem email has had since the beginning.

The problem they solve

When email was designed, nothing checked who a message came from. The "From" line was just text, so anyone could send an email that said it was from your bank, your boss or your company. (We explain the history in How email actually works.)

SPF, DKIM and DMARC were added on top of email, years later, so that a receiving mail server can check three things:

SPF: Did this come from a server the domain allows to send its mail?
DKIM: Is the message signed by the domain, and unchanged since it was signed?
DMARC: Do those checks match the address the reader actually sees, and what should happen if they don't?

A useful way to picture it: SPF is the guest list at the door, DKIM is a wax seal on the envelope, and DMARC is the instruction to the doorman about what to do with anyone who fails.

SPF: the guest list

SPF (Sender Policy Framework) is a single line in your domain's DNS that lists which servers are allowed to send email for your domain. Here's a typical one for a business using Google Workspace and a newsletter service:

example.com.  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"

Read left to right: "This is SPF version 1. Google's mail servers may send for us. So may our newsletter provider's. Anything else is suspicious."

The ending matters. ~all ("soft fail") asks receivers to treat other senders as suspicious. -all ("fail") says they're definitely not allowed. Most domains start with ~all and let DMARC decide what happens.

SPF's weaknesses

It checks the hidden envelope sender (the bounce address), not the From address people see. On its own, it doesn't stop someone faking your visible address.
It breaks on forwarding. When someone forwards your email automatically, it arrives from their server, which isn't on your list.
It has a 10-lookup limit. Every include: can trigger DNS lookups, and past 10 the whole record fails. Businesses that keep adding tools hit this limit often.
You may only have one SPF record. Two separate v=spf1 records make both invalid. Combine them into one.

DKIM: the wax seal

DKIM (DomainKeys Identified Mail) adds a digital signature to every email your domain sends. Your mail provider signs each message with a private key. You publish the matching public key in your DNS, so any receiver can check the signature.

The signature travels inside the email as a header. Shortened, it looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
    h=from:to:subject:date; bh=...; b=...

Two parts are worth knowing. d=example.com is the domain taking responsibility for the email. s=google is the selector: it tells the receiver where to find the public key, in this case at google._domainkey.example.com.

If anyone changes the signed parts of the message along the way, even a single character, the signature no longer matches and DKIM fails. Unlike SPF, DKIM usually survives forwarding, because the signature travels with the message.

You don't write DKIM keys by hand. Your provider (Google Workspace, Microsoft 365, your newsletter or invoicing tool) generates them and tells you which DNS record to add. Each service that sends as your domain should have its own DKIM key.

DMARC: the doorman's instructions

SPF and DKIM have a shared blind spot: neither one checks the From address that people actually see. A scammer could pass SPF for their own domain, sign with DKIM for their own domain, and still show your company's name in From.

DMARC (Domain-based Message Authentication, Reporting and Conformance) closes that gap. It passes only if SPF or DKIM passes and the domain they checked matches the visible From domain. This matching is called alignment, and it's the heart of DMARC.

DMARC also lets you tell receivers what to do with failures, and ask them to send you reports. The record lives at _dmarc.yourdomain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The p= part is the policy:

Policy	What receivers do with failing mail	When to use it
`p=none`	Deliver as normal, but report it	First weeks: watch and learn
`p=quarantine`	Put it in spam	Once all your real senders pass
`p=reject`	Refuse it completely	Full protection against spoofing

The rua= address receives daily reports from Gmail, Outlook, Yahoo and others, listing every server that sent mail claiming to be you, and whether it passed. These reports are XML files that aren't pleasant to read directly; free and paid DMARC report tools turn them into readable dashboards.

Why this suddenly matters for everyone

For years, these records were "best practice" that many businesses skipped. That changed in February 2024, when Gmail and Yahoo began enforcing new rules. Everyone sending to them must have SPF or DKIM, and bulk senders (more than 5,000 messages a day to Gmail) must have SPF, DKIM and a DMARC record, with alignment, plus one-click unsubscribe. Microsoft introduced similar requirements for Outlook.com in 2025.

In practice, even small businesses without these records increasingly find their mail in spam, or bounced with errors mentioning "authentication".

A safe order to set them up

The biggest risk is not doing nothing. It's jumping straight to p=reject and silently blocking your own invoices. Go in this order:

List everything that sends email as your domain. Your mailbox provider, website contact forms, newsletter tool, invoicing or accounting software, CRM, helpdesk, booking system. People are usually surprised by how long the list is.
Set up DKIM for each one. Each service's help pages explain which records to add.
Create one SPF record that includes all of them, and check it stays under 10 lookups.
Publish DMARC with p=none and a reporting address.
Read the reports for 2 to 4 weeks. Fix any legitimate sender that fails.
Move to p=quarantine, then after another few weeks of clean reports, p=reject.

Common mistakes we see

Two SPF records after adding a new tool, which makes both invalid.
Forgetting a sender, usually the website contact form or the accounting software, then going to reject and losing its emails.
DMARC reports going to an unread mailbox, so nobody notices problems.
Setting DMARC and forgetting it at p=none forever. This gives you reports but no protection against spoofing.
Assuming a DMARC pass means an email is safe. It only proves the email came from the domain it shows. Scammers can pass DMARC for their own lookalike domains, which is why checking the domain itself still matters (see How to check if an email is real).

How to check any email's results

You can see these checks on any email you've received. In Gmail, open the message, click ⋮ and choose Show original. The top of the page shows SPF, DKIM and DMARC, each with PASS or FAIL. Send an email from your own domain to a Gmail address and check it this way: if all three say PASS, your setup is working.

The one-paragraph summary

SPF lists the servers allowed to send your mail. DKIM signs each message so it can't be forged or altered. DMARC makes sure those checks match the address people see, tells the world what to do with fakes, and sends you reports. Together, they stop criminals from sending email as your domain, and they're now the difference between reaching the inbox and landing in spam.