API docsAgent tools

Deliverability mechanics

SPF, DKIM, DMARC

Learn Reviewed · not yet fact-checked

In short

What do SPF, DKIM, and DMARC actually verify?

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.

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

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

Where this breaks down

Authentication proves identity, not quality — spam that passes all three checks is still spam, and 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.

Build with Reply