# SPF, DKIM, DMARC

> What each email authentication record verifies, how DMARC alignment ties them to the From domain, and the failure modes that break them.

**SPF lists the servers allowed to send for a domain, DKIM cryptographically signs each message's headers and body, and DMARC checks that one of them aligns with the visible From domain, then tells receivers what to do on failure. All three are required by Gmail and Yahoo's bulk-sender rules.**

_Status: Reviewed — human-edited, facts not yet confirmed against the product._

## What it is

Three DNS records that let a receiving server verify who sent a message:

- **SPF** publishes which servers may send mail for the *envelope sender* domain (the Return-Path). The receiver checks the connecting IP against that list.
- **DKIM** adds a cryptographic signature over selected headers and the body. The receiver verifies it with a public key published in the sender's DNS.
- **DMARC** ties both to the *visible* From address: it requires SPF or DKIM to pass **and align** with the From domain, sets a policy for failures, and requests reports.

## Why it works this way

SMTP itself verifies nothing — anyone can put any address in the From header. SPF and
DKIM each authenticate a domain, but not necessarily the one the recipient sees. DMARC
closes that gap with alignment: the authenticated domain must match the From domain.
That is what makes spoofing detectable rather than merely discouraged.

## How it behaves in practice

- **Alignment is the whole point.** SPF can pass for `bounce.example.net` while the From says `example.com` — DMARC fails that message.
- **Policy escalates.** `p=none` only monitors, `p=quarantine` sends failures to spam, `p=reject` refuses them outright.
- **All three are now mandatory at scale.** Gmail and Yahoo's 2024 bulk-sender rules require SPF, DKIM, and DMARC for senders above roughly 5,000 messages per day.
- **SPF has a 10-DNS-lookup limit.** Each `include:` costs lookups; stacking sending tools silently breaks SPF past ten.
- **Forwarding breaks SPF but usually not DKIM.** A forwarder sends from a new IP, failing SPF; the DKIM signature travels inside the message and survives unless content is modified.

## Common misconceptions

| Belief | Reality |
| --- | --- |
| "SPF verifies the From address" | It verifies the envelope sender; only DMARC alignment connects it to the visible From |
| "DKIM encrypts the message" | It signs the message — proving origin and integrity, hiding nothing |
| "p=none does nothing, so skip DMARC" | `p=none` still unlocks reporting and satisfies bulk-sender requirements |
| "Authentication is a one-time setup" | Every new sending tool must be added; SPF lookup counts creep toward the limit |

## How Reply implements this

Reply's Domain Setup page runs a health checker over the sending domain's DNS — SPF,
DKIM, and DMARC, plus the MX, A, and rDNS records — explains any issue it finds, and
rechecks weekly, as part of the
[deliverability capability](/capabilities/deliverability). One detail matters for the
SPF lookup budget: Reply is not a mail server, so you do not add Reply.io to your
authentication records — you authenticate your mail provider (Google Workspace,
Microsoft 365, and so on), and a domain must carry only one SPF record. The records
themselves live in your DNS — Reply verifies them, it cannot create them for you.
Setup starts when you [connect a mailbox](/how-to/connect-a-mailbox).

## Where this breaks down

Authentication proves identity, not quality — spam that passes all three checks is still
spam, and [reputation](/learn/sender-reputation) decides placement from there. Mailing
lists that rewrite content break DKIM. And DMARC aggregate reports arrive as XML built
for tooling, not for reading — most senders never look at them.

## Related

- [Email deliverability](/learn/email-deliverability)
- [Sender reputation](/learn/sender-reputation)
- [Email warm-up](/learn/email-warm-up)
- [Connect a mailbox](/how-to/connect-a-mailbox)

## Build with Reply

- REST API: [docs.reply.io](https://docs.reply.io/api-reference/introduction) — email account connection and validation
- MCP: [agents.reply.io/mcp](https://agents.reply.io/mcp) — email account setup operations