SPF, DKIM and DMARC explained: the complete guide for MSPs

Email was designed without any way to prove who sent a message. SPF, DKIM and DMARC are the three records that add that proof. Together they decide whether a business's email is trusted, delivered and protected from impersonation. This guide explains each one, how they fit together, and how to roll them out for a client without breaking anything.

The problem they solve

Every email has two "from" addresses. The envelope sender (also called Return-Path or MAIL FROM) is used by servers for bounces. The header From is what the reader sees. Neither is verified by default, so anyone can send a message that displays accounts@yourclient.com. That is how fake invoices and password-reset scams work.

SPF: which servers may send

SPF (Sender Policy Framework, RFC 7208) is a TXT record on the domain that lists the servers allowed to send its email.

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

When a message arrives, the receiving server looks up SPF for the envelope sender's domain and checks whether the sending IP is listed. Key points:

• Exactly one SPF record per domain. Two records make SPF fail.
• At most 10 DNS lookups, counted recursively. See the SPF 10-lookup limit.
• The ending matters: -all (fail), ~all (softfail), ?all (neutral) or +all (allow everyone, which defeats the purpose). See SPF ~all vs -all.
• SPF breaks on forwarding, because the forwarding server is not in the original domain's list.

DKIM: a signature on each message

DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message. The sending service signs with a private key; the public key is published in DNS under a selector:

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The signature header names the signing domain (d=) and selector (s=), so the receiver knows where to fetch the key. Key points:

• DKIM survives forwarding, as long as the message is not modified.
• Each sending service has its own selector and key. A domain can have many.
• Selectors cannot be listed from outside, which is why no tool can prove DKIM is "missing". See how to find a DKIM selector.
• Use 2048-bit RSA keys where the provider supports them.

DMARC: the policy that ties them together

DMARC (RFC 7489) is a TXT record at _dmarc. plus the domain:

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

It does two things. First, it requires alignment: SPF or DKIM must pass for the same domain the reader sees in the From address. Second, it tells receivers what to do when a message fails: nothing (p=none), spam folder (p=quarantine) or reject (p=reject). It also asks receivers to send daily aggregate reports to the rua address.

Alignment, the part most people miss

A message passes DMARC if either of these is true:

1. SPF passes, and the envelope sender's domain matches the From domain.
2. DKIM passes, and the signing domain (d=) matches the From domain.

"Matches" is relaxed by default: mail.example.com aligns with example.com. Strict mode (aspf=s, adkim=s) requires an exact match.

This is why a newsletter tool can "pass SPF" and still fail DMARC: it passed SPF for its own bounce domain, not yours. The fix is to set up a custom return-path or, more often, DKIM signing with your domain in that tool.

A safe rollout plan

1. Inventory senders. Ask the client which tools send email as their domain: mail platform, CRM, invoicing, newsletters, booking, help desk, website forms.
2. Publish DMARC at p=none with rua. Nothing changes for delivery; reports start arriving within a day or two.
3. Fix SPF. One record, under 10 lookups, retired tools removed. Check with the SPF lookup counter.
4. Enable aligned DKIM for every sender, starting with the main mail platform: Microsoft 365 or Google Workspace.
5. Read the reports for two to four weeks until every legitimate source passes.
6. Move to p=quarantine, watch for a week or two, then p=reject. Some teams use pct= to phase this in.
7. Set a subdomain policy with sp= if needed. See DMARC for subdomains.
8. Keep watching. New tools get added. Re-check monthly or watch the domain.

Common mistakes

• Two SPF records, often one added by a web host and one by the mail provider.
• DMARC stuck at p=none for years. Our local study found far more domains at none than enforcing.
• A rua mailbox nobody reads, or one on another domain without the authorisation record that external reporting needs.
• Forgetting parked domains. A domain that never sends email should publish v=spf1 -all and v=DMARC1; p=reject.
• Enforcing before checking reports, and blocking the client's own invoices.

Where MTA-STS fits

SPF, DKIM and DMARC protect the identity of the sender. They say nothing about whether the message travels encrypted. That is MTA-STS (with TLS-RPT for reporting), covered in MTA-STS in 10 minutes. Check any domain with the free MTA-STS checker.

Explaining it to the client

Most clients need one sentence per record: SPF is the guest list, DKIM is the signature, DMARC is the instruction to the bouncer. The longer version, with the questions they will ask, is in how to explain DMARC in two minutes.