# SPF vs DKIM vs DMARC: what each one proves, and what it doesn't

URL: https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc
Last updated: 2026-10-09
Published: 2026-10-09
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> A plain-English comparison of SPF, DKIM and DMARC: what each checks, what it can't prove, how they work together, and where MTA-STS and BIMI fit.

## Short answer

SPF proves a server was allowed to send for the envelope domain. DKIM proves a domain signed the message and the signed parts weren't changed. DMARC ties either result to the From address people see and tells receivers what to do on failure. None of them proves a message is safe or wanted.

Email was designed without any way to prove who sent a message. SPF, DKIM and DMARC were added later, each covering a different gap. Together they let a receiver answer: "Did this message really come from the domain in the From line?"

They don't answer: "Is this message safe?" or "Did the person want it?"

## How do SPF, DKIM and DMARC compare?

| | SPF | DKIM | DMARC |
|---|---|---|---|
| Standard | [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html) | [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.html) | [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) (replaced RFC 7489 in May 2026) |
| DNS record | TXT on the domain | TXT at `selector._domainkey.domain` | TXT at `_dmarc.domain` |
| Checks | The sending server's IP against a list | A cryptographic signature on headers and body | That SPF or DKIM passed **and** aligns with From |
| Domain it authenticates | Envelope sender (Return-Path / MAIL FROM) | The signing domain (`d=`) | The visible From domain |
| Survives forwarding | Usually not | Usually, unless the message is changed | If DKIM survives |
| Tells receivers what to do | Weakly (`-all` / `~all`) | No | Yes (`p=none`, `quarantine`, `reject`) |
| Sends you reports | No | No | Yes (`rua`) |

## SPF: was this server allowed to send?

SPF lists the IP addresses allowed to send mail using your domain in the **envelope sender**: the hidden bounce address, not the From line people read.

**It proves:** the connecting server was on the list published by the envelope domain.

**It doesn't prove:**

- Anything about the From address the reader sees. A spammer can use their own envelope domain, pass SPF, and put your name in From.
- That the message wasn't changed.
- Much after forwarding, because the forwarder's IP isn't on your list.

SPF also has a hard limit of 10 DNS-querying mechanisms. Exceed it and the result is PermError. See [how to fix too many SPF lookups](https://iblockspam.com/blog/spf-too-many-dns-lookups), or start with [what SPF is and how receivers check it](https://iblockspam.com/blog/what-is-spf).

## DKIM: did this domain sign this message?

DKIM adds a `DKIM-Signature` header made with a private key. The receiver fetches the public key from DNS and verifies it.

**It proves:** the domain in `d=` took responsibility for the message, and the signed headers and body weren't altered since signing.

**It doesn't prove:**

- That the signing domain is the one in From. Any domain can sign any message.
- That the content is honest. A compromised account produces perfectly signed phishing.
- That the message wasn't replayed. A validly signed message can be resent to other people.

An unknown DKIM selector isn't a failure. Selectors are names the sender chooses, and DNS can't list them. For the signature tags, keys and what breaks them, see [what DKIM is and how it works](https://iblockspam.com/blog/what-is-dkim).

## DMARC: does the authenticated domain match the From line?

DMARC closes the gap. A message passes when SPF or DKIM passes **for a domain aligned with the From domain**. You publish a policy saying what receivers should do with mail that fails, and where to send reports. Our guide to [what DMARC is](https://iblockspam.com/blog/what-is-dmarc) covers the policy and its reports in more depth.

**It proves:** the visible From domain authorized this message through SPF or DKIM.

**It doesn't prove:**

- That the message is safe. Attackers authenticate their own domains.
- Anything about look-alike domains (`examp1e.com`, `example-billing.com`).
- That receivers will follow your policy. They make the final decision.

RFC 9989 removed the `pct` tag, added `t` (test mode) and `np` (policy for non-existent subdomains), and replaced public suffix list lookups with a DNS tree walk for finding the organizational domain. Existing `v=DMARC1` records still work.

## How do SPF, DKIM and DMARC work together?

1. Your invoicing tool sends an invoice from `billing@example.com`, using `bounces.invoicetool.example` as the envelope sender, signed with `d=example.com`.
2. **SPF:** passes for `bounces.invoicetool.example`. Not aligned with `example.com`.
3. **DKIM:** passes for `example.com`. Aligned.
4. **DMARC:** passes, because DKIM passed with alignment.

Now remove the custom DKIM. DKIM passes only for `invoicetool.example`, SPF still isn't aligned, and DMARC fails. At `p=reject`, your invoices bounce.

## What else appears in the same checks?

These aren't authentication, but they appear in the same checks:

| Standard | What it does |
|---|---|
| MTA-STS ([RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html)) | Tells senders your MX hosts support TLS with valid certificates, so mail to you can't be downgraded to plain text. A TXT record at `_mta-sts` plus a policy file at `https://mta-sts.yourdomain/.well-known/mta-sts.txt`. |
| TLS-RPT ([RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html)) | A TXT record at `_smtp._tls` asking senders to report TLS failures to you. |
| Null MX ([RFC 7505](https://www.rfc-editor.org/rfc/rfc7505.html)) | `MX 0 .` says a domain accepts no mail. Use it on parked domains alongside `v=spf1 -all` and `p=reject`. |
| BIMI | Displays your logo in supporting inboxes. It requires DMARC at `quarantine` or `reject`, according to the [BIMI Group](https://bimigroup.org/implementation-guide/), and most providers also want a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). It's an IETF draft, not an RFC. |

## What do people get wrong about SPF, DKIM and DMARC?

**"We have SPF, so nobody can spoof us."** SPF checks the envelope sender, which readers never see. Without DMARC at enforcement, an attacker can use their own envelope domain, pass SPF for it, and put your domain in the visible From line.

**"DKIM encrypts our email."** It doesn't. DKIM signs messages; anyone along the way can still read them. Encryption in transit is TLS, which MTA-STS helps enforce.

**"p=reject will block our own mail."** Only mail that fails both aligned SPF and aligned DKIM. If you've read your reports and fixed your senders first, legitimate mail keeps flowing. The risk comes from skipping the monitoring stage, not from the policy itself.

**"DMARC stops phishing."** It stops one kind: exact-domain spoofing at receivers that enforce it. Look-alike domains, display-name tricks ("IT Support" <random@freemail.example>) and compromised real accounts all pass or bypass it.

**"An unknown DKIM selector means DKIM is broken."** Selectors are names the sender chooses and can't be listed from DNS. If a checker can't guess yours, enter the `s=` value from a real message header.

**"A domain with no MX is misconfigured."** Not if it doesn't receive mail. It should say so with a Null MX record, `MX 0 .`, plus `v=spf1 -all` and a `p=reject` DMARC policy, so nobody can send as it either.

**"We only need this if we send newsletters."** Every domain that sends any email benefits. Gmail requires SPF or DKIM from all senders, not just bulk ones, according to [Google's sender guidelines](https://support.google.com/mail/answer/81126).

## What do receivers do with the results?

The standards say what to check, not exactly what to do. Each receiver combines the results with its own signals. A failed SPF check under `~all` is usually just one negative signal. A DMARC failure under `p=reject` is a strong instruction that most large receivers follow, though they may make exceptions, for example for mailing lists that carry trustworthy ARC results. A full pass is a positive signal, but content and reputation filtering still decide whether the message reaches the inbox, the junk folder or quarantine.

## In what order should you set them up?

1. **Inventory your senders.** Every service that sends with your domain in From.
2. **Publish SPF** listing your mail platform and any outbound relay. One record only.
3. **Enable DKIM** with your domain in every service. Prefer 2048-bit keys.
4. **Publish DMARC at `p=none`** with a `rua` address.
5. **Read the reports**, fix gaps, then move toward `p=reject`. Our [staged DMARC rollout](https://iblockspam.com/blog/dmarc-none-to-reject-small-business) has the detail.
6. **Add MTA-STS and TLS-RPT** for transport security.

## How iBlockSpam helps

Our free checkers test each record: [SPF](https://iblockspam.com/tools/spf-checker), [DKIM](https://iblockspam.com/tools/dkim-checker), [DMARC](https://iblockspam.com/tools/dmarc-checker), and all of them together in the [Email Health Check](https://iblockspam.com/tools/email-health-check). For mail you receive, iBlockSpam adds spam, virus, malware, phishing and spoofing protection at the MX. That matters because passing authentication doesn't make a message safe.

## Next steps

1. Check all three records at once with the free [Email Health Check](https://iblockspam.com/tools/email-health-check).
2. Fix SPF and DKIM for every sending service, then publish DMARC at `p=none` with the [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator).
3. Move toward enforcement with [DMARC from none to reject](https://iblockspam.com/blog/dmarc-none-to-reject-small-business).

If you'd rather not read aggregate reports yourself, iBlockSpam's [DMARC monitoring](https://iblockspam.com/features/dmarc-monitoring) shows which of your senders pass SPF, DKIM and DMARC, and it's included in both plans on our [pricing page](https://iblockspam.com/pricing).

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Do I need all three?

Yes. SPF and DKIM give receivers two independent ways to authenticate your mail, and DMARC connects them to your visible From address. Google and Yahoo require all three from bulk senders, and every domain benefits from them.

### If an email passes SPF, DKIM and DMARC, is it safe?

No. It only means the message genuinely came from the domain it claims. Attackers can register their own domain, set up perfect authentication and send phishing. Content and reputation filtering still matter.

### Why do I see dkim=pass but dmarc=fail?

DKIM passed for a domain that doesn't match your From domain. Many tools sign with their own domain by default. Set up custom DKIM so they sign as your domain.

### Is DMARC still RFC 7489?

No. RFC 9989, published in May 2026, replaced RFC 7489 and moved DMARC onto the IETF Standards Track. Existing v=DMARC1 records keep working.

## Sources

- [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376.html)
- [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html)
- [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html)
- [RFC 7505: A Null MX No Service Resource Record](https://www.rfc-editor.org/rfc/rfc7505.html)
- [BIMI Group: Implementation guide](https://bimigroup.org/implementation-guide/)
- [Gmail Help: Email sender guidelines](https://support.google.com/mail/answer/81126)

## Free tools for this guide

- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator): Build a DMARC record with the right policy, reporting and alignment settings.

---

Source: iBlockSpam, https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt