SPF, DKIM, and DMARC Explained for Non-Technical Business Owners

If you've ever searched "why are my emails going to spam," you've likely come across the acronyms SPF, DKIM, and DMARC. They sound technical, and they are — but understanding what they do and why they matter doesn't require a computer science degree.

Think of email authentication like the identification system at a border crossing. SPF is the list of authorised vehicles. DKIM is the sealed envelope that proves the contents haven't been tampered with. DMARC is the border agent's standing orders: "If the vehicle isn't on the list or the seal is broken, turn it away."

SPF: The Authorised Senders List

SPF stands for Sender Policy Framework. It's a DNS record — a short line of text you add to your domain's settings — that lists which mail servers are allowed to send email on behalf of your domain.

For example, if you use Google Workspace to send email from hello@yourcompany.com, you'd add Google's mail servers to your SPF record. When Gmail receives an email claiming to be from your domain, it checks: did this email come from a server on my authorised list? If yes, it passes. If no, it's treated as suspicious.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com -all

The include:_spf.google.com part says "also authorise all servers listed in Google's SPF record." The -all at the end means "reject everything else."

What goes wrong: Having no SPF record at all. Using ~all (soft fail) instead of -all (hard fail). Having more than 10 DNS lookups in your SPF chain. Or having multiple SPF records — you can only have one.

DKIM: The Digital Signature

DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to every email you send, created using a private key held by your email provider. Your DNS record contains the corresponding public key.

When a receiving server gets your email, it looks up the public key from your DNS and uses it to verify the signature. If the signature checks out, the email is confirmed as genuinely from you and unmodified in transit. If it doesn't, something is wrong.

Unlike SPF, DKIM survives email forwarding. If someone forwards one of your emails, SPF will fail (because it's now coming from a different server) but DKIM will still pass (because the signature on the content remains valid). This is why you need both.

What goes wrong: Not having DKIM enabled in your email provider's admin panel. Generating a DKIM key but forgetting to add the DNS record. Key rotation without updating the DNS record.

DMARC: The Policy That Ties It Together

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It's the policy layer that sits on top of SPF and DKIM.

DMARC answers one question: "What should you do when an email claims to be from my domain, but fails SPF and/or DKIM?" There are three options:

• p=none — Do nothing; just monitor and send me reports. This is where everyone should start.
• p=quarantine — Send failing emails to spam. This is the recommended policy once you've confirmed all your legitimate email is passing authentication.
• p=reject — Reject failing emails outright. Maximum protection, but requires confidence that all your email is properly authenticated.

DMARC also enables reporting. You can specify an email address to receive aggregate reports from Gmail, Yahoo, and other major providers showing authentication pass/fail rates for your domain. This is invaluable for spotting misconfigured email sources before they become deliverability problems.

A minimal DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com

What goes wrong: Having no DMARC record (very common). Setting p=reject before checking that all email sources are passing authentication (this can cause legitimate emails to be rejected). Not monitoring the reports.

Why You Need All Three

SPF alone is not enough because it breaks during forwarding. DKIM alone is not enough because it doesn't prevent someone from using a domain you've never heard of in the "From" address. DMARC alone does nothing without SPF or DKIM to evaluate.

The three records work as a system. SPF says which servers are allowed. DKIM proves the email wasn't altered. DMARC says what happens when they fail and requires them to be aligned with the visible "From" domain.

Gmail and Yahoo made all three mandatory for bulk senders in February 2024. But even for low-volume senders, the combination is the baseline standard for professional email in 2025.

What About BIMI and MTA-STS?

Two newer records extend the authentication system further.

BIMI (Brand Indicators for Message Identification) adds your logo to the inbox in Gmail and Apple Mail. It requires a valid DMARC enforcement policy (p=quarantine or p=reject) and a verified SVG logo file. BIMI is optional but increases open rates by making your emails instantly recognisable.

MTA-STS (Mail Transfer Agent Strict Transport Security) forces incoming mail to use encrypted TLS connections. It protects your domain from "downgrade attacks" where an attacker intercepts mail by forcing a connection to use no encryption. MTA-STS is technical to set up but worth doing once everything else is in place.

How to Check Your Current Setup

All five records are publicly readable — they're stored in your domain's DNS, which any server can query. The fastest way to check your status is to run a free audit that looks up all five records at once and tells you which ones pass, fail, or need attention.