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.
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.
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.