Blog · Email security
SPF, DKIM and DMARC, explained without the acronym soup
Three records, three jobs, one outcome: whether a receiving mail server has any reason to believe a message came from you. Here is the mental model that makes the rest of the internet's email advice make sense.
The short version
- SPF says which servers may send mail for your domain. DKIM proves a message was not altered after it was signed. DMARC decides what a receiver does when either check fails.
- SPF or DKIM on their own are plumbing. DMARC is the part that changes someone else's behaviour.
- Alignment is the detail most people miss: DMARC asks whether the domain that authenticated matches the domain in the visible From line.
- You can inspect all three on your own domain in about ten minutes, with three
digcommands.
The original email protocol has no concept of a sender identity. Anyone who can reach a mail server can claim to be anyone, and for most of the internet's history the receiving side had nothing to check that claim against. SPF, DKIM and DMARC were added later, one problem at a time, by different working groups, which is precisely why they look like three unrelated things bolted onto the same system.
They are not unrelated. Think of them as three questions a receiving mail server asks:
- Is this machine allowed to send for that domain? (SPF)
- Was this message tampered with after the sender signed it? (DKIM)
- If either answer is bad, what should I do — and does the domain that passed even match the one the customer sees? (DMARC)
What each record actually does
| Record | Where it lives | What it answers | What it cannot do |
|---|---|---|---|
| SPF | A TXT record on the domain itself | Which IP addresses or hosts are authorised to send mail using this domain as the envelope sender | Survive forwarding, or tell you anything about the visible From line |
| DKIM | TXT records under <selector>._domainkey | Whether the message body and selected headers match what the sender signed | Prove the sender is trustworthy — only that the message was signed with a key that domain published |
| DMARC | A TXT record at _dmarc.yourdomain.com | What to do on failure, where to send reports, and whether authentication has to align with the From domain | Work at all unless SPF or DKIM aligns for legitimate mail |
The part that connects them: alignment
Here is the subtle bit that trips up almost everyone. SPF authenticates the envelope sender — a routing detail the recipient usually never sees. DKIM authenticates a domain that signed the message. The From line in the customer's inbox is a third thing entirely, and nothing forces them to agree.
So an attacker can send a message with your domain in the From line, use a domain they control for the envelope sender, pass SPF on their domain, and land in an inbox looking like you. DMARC closes that gap by asking for alignment: did the domain that passed SPF or DKIM match the domain in From? That question — not the pass itself — is what turns authentication into protection.
SPF passing for your domain is not the same as SPF passing for your domain on a message that claims to be from you.
What a healthy configuration looks like
Concretely, for a business on Google Workspace or Microsoft 365 with a couple of extra senders, a working setup looks like this. The exact mechanisms differ; the shape does not.
; the domain itself
yourdomain.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
; the policy
_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r"
; one signing key (Google Workspace uses the "google" selector)
google._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg... "Three things are worth noticing. The SPF record ends in -all, a hard fail, not
~all. The DMARC policy is p=reject, which means receivers are told to
refuse failing mail outright. And the DKIM selector is named — selectors are not
discoverable by design, so the only people who can check a selector are the ones who know what
it is called.
A ten-minute check on your own domain
You do not need a tool for the basics. On macOS or Linux, three queries cover the three
records. On Windows, the same questions work in any DNS lookup site or in PowerShell with
Resolve-DnsName.
# 1. SPF (look for a single record, and for -all at the end)
dig +short TXT yourdomain.com
# 2. DMARC (look for v=DMARC1 and the p= value)
dig +short TXT _dmarc.yourdomain.com
# 3. DKIM (use the selector your provider documents, e.g. "google" or "selector1")
dig +short TXT google._domainkey.yourdomain.comRead the answers for what they are, not for whether something replied. Two SPF records is a
failure, not a merge. An SPF record that ends in ?all expresses no opinion at all.
A DMARC record with p=none asks for reports and promises nothing. And a DKIM query
that returns nothing may mean the selector name is wrong rather than the key being missing
— which is exactly why "DKIM not found" from a checklist site deserves a second look
before you panic.
Why "we already have SPF" is not the end of the conversation
SPF is the easiest of the three to publish and the least useful on its own. It breaks when mail is forwarded, it fails silently when a third-party tool sends on your behalf from an address you forgot to authorise, and it says nothing about whether the visible sender is you. A domain with SPF but no DMARC policy is a domain where anyone can still forge the From line without consequence.
The order that works is unglamorous: inventory every system that sends mail as your domain, give each one SPF authorisation and its own DKIM signature, then publish DMARC in monitoring mode, then enforce. Skipping to enforcement is how a business discovers, mid-quarter, that its invoices have been going to spam for a week.
If you want the record-syntax level detail — mechanisms, qualifiers, the ten-lookup limit, the subdomain policy flag — the reference article on how email authentication actually works goes deeper than this page needs to. The DMARC rollout guide takes the next step: turning a monitoring policy into enforcement without losing mail.
What SMB Scanner Lite checks here
These are the controls from this area that the assessment evaluates from outside, without credentials and without touching anything private. Each one returns a status and, for every conclusive result, the record, header or handshake that produced it.
| Control | What is evaluated |
|---|---|
| SPF policy strength | Whether the record ends in a hard fail (-all), a soft fail, or nothing at all. |
| SPF record validity | Whether the record stays inside the RFC 7208 ten-lookup limit, and whether more than one SPF record exists. |
| DMARC enforcement | Whether _dmarc exists and which policy is published: none, quarantine or reject. |
| DKIM presence | Whether discoverable selectors publish a usable key, and at what length. |
| MX and null-MX posture | Whether mail routing is coherent, including deliberate null MX for domains that never send. |
Only assess domains you own or are authorised to test — see responsible use. The published recorded assessment shows how a result and its evidence appear in a report, and the control catalog lists all 22 controls with their weights. Reference detail for this topic lives in SPF, DKIM and DMARC: how email authentication actually works.