How Email Deliverability Works: SPF, DKIM, and DMARC Explained

When you send an email, nothing stops a stranger from claiming it came from your domain. The original email protocol, SMTP, was built without any way to verify the sender. Three DNS-based standards close that gap: SPF, DKIM, and DMARC. Together they let a receiving mail server answer a simple but critical question—is this message really authorized by the domain it claims to be from? This guide explains how each one works, how receivers evaluate them, and how to set them up correctly.

Why Email Authentication Exists

Every email actually carries two "from" addresses. There is the envelope sender (also called the Return-Path or MAIL FROM), which the receiving server uses during the SMTP conversation, and there is the header From: address that you see in your mail client. Spammers and phishers exploit the gap between them by putting a trusted brand in the visible From: line while sending from infrastructure that has nothing to do with that brand.

Authentication standards give a domain owner a way to publish, in public DNS, the rules for who may send mail on their behalf and how that mail should be cryptographically marked. Receiving servers read those published rules and decide whether to trust the message. The payoff is twofold: less spoofing of your domain and better inbox placement for the mail you genuinely send, because mailbox providers reward authenticated, consistent senders.

SPF: Which Servers Are Allowed to Send

SPF stands for Sender Policy Framework. It is a single DNS TXT record that lists the IP addresses and hostnames authorized to send mail for a domain. When a receiving server gets a message, it looks at the envelope sender's domain, fetches that domain's SPF record, and checks whether the connecting server's IP address is on the approved list.

A typical SPF record looks like this, published as a TXT record on the root of the domain:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Reading the mechanisms left to right:

v=spf1 declares the record version. Every SPF record starts this way.
ip4:203.0.113.10 authorizes that specific IPv4 address.
include:_spf.google.com delegates to Google's SPF record, a common pattern when you send through a third-party provider.
-all is the qualifier for everything else. The hyphen means "hard fail"—any server not listed is not authorized. A tilde (~all) means "soft fail," a weaker stance that receivers usually treat as suspicious but not disqualifying.

Two practical limits are worth remembering. First, SPF evaluation is capped at 10 DNS lookups; chaining too many include: statements causes a permerror and breaks authentication. Second, SPF validates the envelope sender, not the visible From: address, and it breaks when mail is forwarded, because the forwarding server's IP is rarely in your record. That gap is exactly why DKIM and DMARC are needed alongside it.

DKIM: A Cryptographic Signature on the Message

DKIM, or DomainKeys Identified Mail, takes a different approach. Instead of checking the connecting IP, it attaches a digital signature to the message itself. The sending server hashes selected headers and the body, signs that hash with a private key, and adds the result as a DKIM-Signature header. The matching public key lives in DNS, so any receiver can verify the signature.

The public key is published under a selector. If the signature header says s=mail2026; d=example.com, the receiver fetches the key from this hostname:

mail2026._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Here v=DKIM1 is the version, k=rsa is the key type, and p= holds the base64-encoded public key (truncated above; real keys are 1024 or 2048 bits). Using a selector lets a domain rotate keys or run several providers at once, each with its own selector.

When the receiver recomputes the hash over the same headers and body and it matches the decrypted signature, two things are proven: the message was authorized by whoever holds the private key for d=example.com, and the signed parts of the message were not altered in transit. Because the signature travels with the message, DKIM usually survives forwarding, which is its key advantage over SPF.

DMARC: Policy, Alignment, and Reporting

SPF and DKIM each authenticate a domain, but neither one is tied to the From: address the recipient actually sees. DMARC—Domain- based Message Authentication, Reporting, and Conformance—fixes that. It does three jobs: it requires alignment with the visible From: domain, it tells receivers what to do when authentication fails, and it asks them to send reports.

A DMARC record is a TXT record published at the _dmarc subdomain:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=r; pct=100"

The important tags:

p= is the policy for messages that fail DMARC: none (take no action), quarantine (treat as suspicious, usually route to spam), or reject (refuse the message outright).
rua= is the address that receives aggregate reports—daily XML summaries of how much mail passed or failed, and from which sources.
adkim and aspf set alignment mode to strict (s) or relaxed (r). Relaxed allows subdomains to align with the organizational domain; strict requires an exact match.
pct= applies the policy to a percentage of failing mail, useful for a gradual rollout.

Alignment is the heart of DMARC

DMARC does not just ask "did SPF or DKIM pass?" It asks "did they pass for a domain that matches the visible From: address?" That match is called alignment, and a message passes DMARC if it satisfies at least one of these:

SPF alignment: SPF passes and the envelope sender domain aligns with the From: domain.
DKIM alignment: a valid DKIM signature exists and its d= domain aligns with the From: domain.

This is why a raw SPF or DKIM pass is not enough on its own. A message can pass SPF for bounces.mailer.example.net while the From: header reads [email protected]. Raw SPF passes, but SPF alignment fails because the two organizational domains differ. If DKIM is also unaligned, the message fails DMARC and the published policy kicks in.

How a Receiving Server Decides: A Walkthrough

Picture a message arriving at a large mailbox provider. Roughly, here is the sequence it runs through:

Read the From: domain

The receiver records the organizational domain in the visible From: header. This is the identity DMARC will hold everything else accountable to.

Check SPF

It looks up the envelope sender domain's SPF record and compares the connecting IP. The result is pass, fail, softfail, neutral, or an error. It then checks whether that envelope domain aligns with the From: domain.

Verify DKIM

For each DKIM-Signature header, it fetches the public key by selector, recomputes the hash, and verifies the signature. A valid signature whose d= domain aligns with the From: domain counts as DKIM alignment.

Evaluate DMARC

If either SPF or DKIM passed AND aligned, DMARC passes. If neither aligned, DMARC fails and the receiver consults the published policy (none, quarantine, or reject).

Apply policy and report

The receiver enforces the policy, factors the outcome into its own reputation and filtering signals, and later sends an aggregate report to the rua address so the domain owner can see what happened.

A crucial nuance: DMARC needs only one aligned pass. A forwarded message often fails SPF because the forwarder's IP is not in your record, but if the DKIM signature survives forwarding and stays aligned, the message still passes DMARC. This redundancy is the main reason all three mechanisms are deployed together rather than picking one.

Practical Setup Notes

Getting authentication right is mostly about a careful, staged rollout rather than flipping every switch at once:

Inventory your senders first. List every service that sends mail as your domain—your mail provider, marketing platform, support desk, billing system. Each one needs to appear in SPF and ideally sign with DKIM.
Publish SPF and DKIM, then verify. Add the SPF record and the DKIM keys each provider gives you. Send test messages and confirm both pass before touching DMARC.
Start DMARC at p=none. A monitoring-only policy with an rua address changes nothing about delivery but turns on reporting, so you can discover sources you forgot.
Read the aggregate reports. When every legitimate source shows aligned passes, you are ready to tighten. Many teams use a report-parsing tool, since the raw XML is hard to read by hand.
Move to quarantine, then reject. Step up to p=quarantine (optionally with pct= for a partial rollout), watch for fallout, then finish at p=reject for full protection.

Keep in mind that authentication is necessary but not sufficient for inbox placement. SPF, DKIM, and DMARC prove identity; reputation, recipient engagement, complaint rates, and list hygiene decide whether wanted mail actually lands in the inbox. A perfectly authenticated message to an unengaged list can still end up filtered.

Frequently Asked Questions

Do I need all three of SPF, DKIM, and DMARC?

In practice, yes. SPF and DKIM each authenticate a different part of the message, and DMARC ties them together with alignment checks and tells receivers what to do on failure. Some large mailbox providers now require DMARC for bulk senders, and a message that passes neither SPF nor DKIM alignment will fail DMARC regardless of policy.

What is the difference between an SPF pass and SPF alignment?

An SPF pass means the sending IP is authorized by the SPF record of the domain in the SMTP envelope (the Return-Path / MAIL FROM). SPF alignment, which DMARC requires, means that envelope domain also matches the domain in the visible From: header. You can pass raw SPF but still fail SPF alignment if the two domains differ.

Should I start my DMARC policy at p=reject?

No. Start at p=none with a reporting address so you can see who is sending mail as your domain without affecting delivery. Once your aggregate reports show that all legitimate sources pass alignment, move to p=quarantine and finally p=reject.

Why did my email pass authentication but still land in spam?

Authentication proves who sent a message; it does not prove the message is wanted. Reputation, content, list hygiene, engagement, and complaint rates all factor into placement. SPF, DKIM, and DMARC are a prerequisite for good placement, not a guarantee of it.

The Bottom Line

SPF says which servers may send for your domain, DKIM proves a message was authorized and unaltered with a signature, and DMARC ties both to the visible From: address while telling receivers what to do on failure. Deploy all three, start DMARC in monitoring mode, and tighten the policy as your reports confirm that legitimate mail aligns. If you are testing signup or verification flows and need a throwaway address to inspect what actually arrives, a free temporary-email tool such as OpenInbox can be a convenient place to read the raw headers.