Learn · Topic explainer
DMARC, SPF, and DKIM explained: the email authentication trio
If your domain sends mail — transactional, marketing, or even just confirmation emails from a contact form — you need three DNS records: SPF, DKIM, and DMARC. Each does a different job, and each is essentially useless without the other two. Together, they tell mailbox providers "only these IPs and signing keys are allowed to send mail as me; reject everything else." This explainer covers what each record actually does, why you need all three, and the staged DMARC rollout that gets you to enforcement without blocking your own legitimate senders.
Quick answer
SPF, DKIM, and DMARC are three DNS records that authenticate your domain's email. SPF lists which servers may send, DKIM cryptographically signs each message, and DMARC ties the two together and tells receivers what to do with mail that fails. You need all three, and only DMARC at p=quarantine or p=reject actually blocks spoofing of your domain.
SPF: who's allowed to send
SPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and hosts authorized to send mail with your domain in the `MAIL FROM` (envelope sender) address. A receiving server checks the sending IP against your SPF record and either passes, fails, or soft-fails. SPF on its own has a serious limitation: it only checks the envelope sender, not the visible `From:` address users see. An attacker can pass SPF using their own domain in `MAIL FROM` while displaying your domain in `From:`. That's why SPF alone isn't enough.
DKIM: cryptographic proof
DKIM (DomainKeys Identified Mail) signs outgoing messages with a private key; the public key lives in DNS. Receiving servers verify the signature against the public key. A valid DKIM signature proves the message hasn't been modified in transit and that someone with access to your DKIM private key sent it. DKIM signatures survive forwarding (unlike SPF), which makes DKIM more useful for messages that pass through aliases or mailing lists. Like SPF, DKIM by itself doesn't block spoofing of the `From:` field — that's DMARC's job.
DMARC: alignment and policy
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with two new ideas: alignment and policy. Alignment requires that the domain in the visible `From:` field match the domain in either SPF or DKIM. Policy tells receiving servers what to do when a message fails alignment: `p=none` (do nothing, just send a report), `p=quarantine` (move to spam), or `p=reject` (refuse delivery). DMARC is the piece that actually stops spoofing — but only at `p=quarantine` or `p=reject`.
The staged DMARC rollout
Don't go straight to `p=reject` — you'll block your own legitimate senders that you forgot about (a forgotten marketing tool, a SaaS app sending invoices in your name). The standard rollout: (1) Publish DMARC at `p=none` with a `rua=` reporting mailbox. (2) Wait 2–4 weeks for aggregate reports. Identify every legitimate sender and either add them to your SPF record or get them to align. (3) Move to `p=quarantine; pct=10` — quarantine 10% of failures, see what breaks. (4) Slowly raise `pct` to 100, then change `p` to `quarantine`. (5) Once stable, move to `p=reject`. The whole process takes 2–4 months for a typical organization.
BIMI: the visible reward
Once your DMARC policy is at `p=quarantine` or `p=reject`, you can publish a BIMI (Brand Indicators for Message Identification) record. BIMI displays your logo in the recipient's inbox next to your messages — it's the small visible payoff for the months of DMARC work. BIMI isn't a security control; it's a UX signal that mailbox providers reward to domains with hardened email auth. If you're going to do DMARC right, BIMI is the natural endpoint.
SPF vs DKIM vs DMARC at a glance
| Record | What it does | Where it lives | Key limitation |
|---|---|---|---|
| SPF | Lists IPs and hosts allowed to send | DNS TXT at the domain | Only checks the envelope sender, not the visible From: |
| DKIM | Cryptographically signs each message | DNS TXT at selector._domainkey | Does not block From: spoofing on its own |
| DMARC | Enforces alignment and sets policy | DNS TXT at _dmarc | Only blocks spoofing at p=quarantine or p=reject |
Frequently asked questions
- Do I need all three of SPF, DKIM, and DMARC?
- Yes. Each is close to useless without the other two. DMARC relies on SPF and DKIM results to decide whether a message is aligned, and only DMARC blocks spoofing of the visible From: address.
- What is the difference between SPF and DKIM?
- SPF authorizes which servers may send mail for your domain; DKIM cryptographically signs each message so receivers can verify it was not altered. DKIM signatures survive forwarding, while SPF checks break when mail is forwarded.
- What does p=none mean in DMARC?
- p=none is monitoring only: receivers send you reports about failures but still deliver the mail. It is the safe starting point for a rollout, not a protective policy. You only block spoofing once you move to p=quarantine or p=reject.
- How long does a DMARC rollout take?
- Typically two to four months. Start at p=none with a reporting mailbox, use the reports to find every legitimate sender, then raise to p=quarantine with a small percentage and work up to p=reject as confidence grows.
- Why does my SPF record fail with too many lookups?
- SPF allows a maximum of 10 DNS lookups while evaluating a record. Chained include: mechanisms from several vendors push you over that limit and cause a permanent failure. Remove unused includes or flatten the record to stay under 10.
Related Scorifya checks
Try the focused tools
Single-purpose checkers that test exactly what this topic covers.
See how your site scores
Run a free Scorifya scan on any URL you're allowed to test. The score breaks down across TLS, security headers, exposure, cookies, and DNS, exactly the areas this explainer covers.