Email Authentication: SPF, DKIM & DMARC Explained

If your emails land in spam, get silently dropped, or arrive with a “via” warning, the cause is often the same: missing or broken email authentication. SPF, DKIM and DMARC are the three records that prove an email genuinely comes from your domain. Get them right and you protect both your inbox placement and your brand from being spoofed. Get them wrong and even legitimate campaigns struggle to reach people.

This guide explains how SPF, DKIM and DMARC each work, how they fit together through alignment and policy, where most setups break, and a generic step-by-step approach you can follow with any mailbox or sending platform. Think of it as teaching your domain to carry a sealed, verifiable letter — the kind a valiant carrier pigeon delivers without anyone questioning who sent it.

Why email authentication matters for deliverability

Mailbox providers like Gmail, Outlook and Yahoo receive an enormous volume of mail, and a large share of it is spam or outright fraud. To decide what reaches the inbox, they lean heavily on whether a message can be cryptographically and administratively tied to a real, accountable domain.

Authentication does three things for you:

• Builds sender reputation. Reputation is tracked per domain and per IP. Without authentication, providers can’t reliably attribute your good behavior to you, so you never accumulate the trust that earns inbox placement.
• Prevents spoofing and phishing. Anyone can put your address in the “From” field. Authentication is what stops a scammer from convincingly impersonating your brand.
• Meets bulk-sender requirements. Major providers now expect bulk senders to authenticate properly. Domains that don’t comply increasingly see mail rejected or filtered.

In short: authentication is no longer optional polish. It’s the foundation that everything else in deliverability sits on. If you want to go deeper on the broader picture, see our email deliverability guide.

How SPF works

SPF (Sender Policy Framework) answers one question: is this server allowed to send mail for this domain?

You publish an SPF record as a TXT record in your domain’s DNS. It lists the servers and services authorized to send on your behalf. When a receiving server gets your message, it checks the sending server’s IP address against that list.

A simplified SPF record looks like this:

v=spf1 include:_spf.example-esp.com include:servers.mailservice.com -all

Breaking that down:

• v=spf1 declares the record version.
• include: delegates authorization to another domain’s SPF record. This is how you authorize an email platform, your CRM, your help desk, and so on — each provider gives you the include value to add.
• -all is the enforcement mechanism. -all (hard fail) says “anything not listed is unauthorized”. ~all (soft fail) is more lenient and marks unlisted sources as suspicious rather than failing them outright.

Key SPF limits to know

• The ten-lookup limit. SPF allows a maximum of ten DNS lookups. Each include can chain to more lookups, and exceeding ten causes a permerror that breaks SPF entirely. Stacking too many services is the most common way SPF silently fails.
• SPF breaks on forwarding. When a message is forwarded, the forwarding server’s IP usually isn’t in your SPF record, so the check fails. This is exactly why DKIM and DMARC exist — SPF alone isn’t enough.
• One SPF record per domain. You merge all sources into a single record. Publishing two separate SPF TXT records is invalid.

How DKIM works

DKIM (DomainKeys Identified Mail) adds a tamper-evident signature to every message. Where SPF checks the path, DKIM checks the content and origin using public-key cryptography.

Here’s the mechanism:

1. Your sending platform holds a private key and uses it to sign outgoing messages. The signature covers the headers and body.
2. You publish the matching public key in DNS as a TXT record, under a name that includes a selector — for example selector1._domainkey.yourdomain.com. The selector lets you run multiple keys at once (handy when rotating keys or using several providers).
3. The receiving server reads the DKIM-Signature header, fetches your public key from DNS, and verifies the signature.

If the signature validates, two things are proven: the message genuinely came from a domain that controls the private key, and it wasn’t altered in transit. Because DKIM signs the message itself rather than checking the connecting IP, it survives forwarding in most cases — a critical advantage over SPF.

DKIM practicalities

• Use strong keys. Longer keys (commonly 2048-bit) are the modern standard. Some legacy setups still use weaker keys, which providers may distrust.
• Selectors enable rotation. Periodically rotating keys is good hygiene, and selectors make it possible without downtime: publish a new key under a new selector, switch signing, then retire the old one.
• Your platform handles the signing. In practice you rarely touch the private key — your email service generates the keypair and gives you the public-key DNS record to publish.

How DMARC ties it all together

SPF and DKIM each prove something useful, but on their own they don’t tell a receiving server what to do when checks fail, and they don’t guarantee the checks relate to the address your recipient actually sees. DMARC (Domain-based Message Authentication, Reporting and Conformance) closes both gaps.

DMARC is also a TXT record, published at _dmarc.yourdomain.com. It introduces three concepts: alignment, policy, and reporting.

Alignment

This is the heart of DMARC. A message passes DMARC when SPF or DKIM passes and the relevant domain aligns with the domain in the visible From header.

• SPF alignment compares the From domain with the domain SPF validated.
• DKIM alignment compares the From domain with the domain in the DKIM signature.

Alignment matters because a spammer could pass SPF for their own domain while spoofing your address in the From line. DMARC’s alignment requirement is what makes that impossible. Only one of SPF or DKIM needs to pass and align for DMARC to pass.

Policy

The p= tag tells receivers how to treat mail that fails DMARC:

• p=none — monitor only. Nothing is blocked; you simply collect data. This is where every domain should start.
• p=quarantine — failing mail is treated as suspicious, typically routed to spam.
• p=reject — failing mail is rejected outright. This is the strongest protection against spoofing and the recommended end state once you’re confident your legitimate mail aligns.

A basic record looks like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Aggregate reports

The rua= tag tells receivers where to send aggregate reports — XML summaries of who is sending mail using your domain and whether it passed SPF, DKIM and alignment. These reports are how you discover legitimate services you forgot to authorize before you tighten your policy. Reports are dense XML, so most teams feed them into a DMARC reporting tool that turns them into readable dashboards.

The recommended path is a ramp: start at p=none, read the reports, fix every legitimate source until it aligns, move to p=quarantine, confirm nothing breaks, then move to p=reject.

BIMI, briefly

BIMI (Brand Indicators for Message Identification) lets your verified brand logo appear next to your messages in supporting inboxes. It’s a reputation reward, not an authentication check in itself — and it has a hard prerequisite: you must have DMARC at an enforced policy (quarantine or reject) first. Some inboxes also require a Verified Mark Certificate. Treat BIMI as a bonus you earn after the SPF/DKIM/DMARC foundation is solid, not a starting point.

Common mistakes

• Exceeding the SPF ten-lookup limit. Adding service after service silently pushes you over the limit and breaks SPF for everyone.
• Publishing two SPF records. Only one is valid; a second one invalidates the check.
• Forgetting a sending source. Your CRM, invoicing tool, help desk and newsletter platform may all send as your domain. Miss one and it fails authentication — sometimes only discovered after you reach p=reject.
• Jumping straight to p=reject. Enforcing before you’ve verified every legitimate source is the fastest way to block your own transactional mail.
• Weak or unrotated DKIM keys. Old, short keys undermine the trust DKIM is meant to build.
• Ignoring DMARC reports. The reports exist to guide you; skipping them means tightening policy blind.

Step-by-step setup approach

This sequence is provider-agnostic — the exact DNS values come from your email platform, but the order is the same everywhere.

1. Inventory every sending source. List everything that sends mail as your domain: marketing platform, CRM, support desk, billing system, and your own mail server.
2. Publish or update SPF. Create a single SPF TXT record that includes each authorized service. Keep an eye on the lookup count. Start with ~all, move to -all once you’re confident.
3. Enable DKIM on every source. In each platform, turn on DKIM and publish the public-key TXT record it gives you, using the selector it specifies. Confirm each one signs your outgoing mail.
4. Publish DMARC at p=none. Add the _dmarc TXT record with p=none and an rua= address so reports start flowing.
5. Read the reports and fix alignment. Over a few weeks, identify any legitimate source that isn’t passing or aligning, and correct it.
6. Ramp the policy. Move to p=quarantine, monitor, then to p=reject once clean.
7. Consider BIMI. With enforcement in place, evaluate adding a BIMI record to display your logo.

How to verify

• Send a test message to an account at a major provider and view the message headers (in Gmail, “Show original”). Look for spf=pass, dkim=pass, and dmarc=pass.
• Check DNS directly. Query your domain’s TXT records to confirm the SPF, DKIM selector and DMARC records resolve as expected.
• Use a lookup or testing tool. Free SPF, DKIM and DMARC checkers will flag syntax errors, the ten-lookup overflow, and missing alignment.
• Watch your DMARC reports. Ongoing aggregate reports are your early-warning system for new unauthorized — or forgotten legitimate — sources.

Authentication isn’t a one-time task. Sources change, services get added, keys should rotate. Revisit your records whenever you add a new tool that sends on your behalf, and keep reading those reports.

FAQ

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

Yes. SPF and DKIM each prove different things, and DMARC is what ties them to the address recipients actually see while telling receivers what to do on failure. Together they form one system; skipping any one leaves a gap that providers — and spammers — will find.

What’s the difference between SPF and DKIM?

SPF authorizes which servers may send for your domain (a path check) and breaks when mail is forwarded. DKIM cryptographically signs the message itself, proving origin and integrity, and usually survives forwarding. DMARC requires that at least one of them passes and aligns with your visible From domain.

Is it safe to start with DMARC at p=reject?

No. Start at p=none to monitor, use the aggregate reports to find and fix every legitimate sending source, then ramp through quarantine to reject. Jumping straight to enforcement risks blocking your own legitimate email.

Does email authentication guarantee inbox placement?

No, but it’s the prerequisite. Authentication lets providers trust and attribute your sending. Inbox placement still depends on reputation, engagement and list quality — covered in our email deliverability guide.