DNS authenticationSPF, DKIM and DMARC: How the Three Work Together

SPF, DKIM and DMARC are three DNS records that let receiving mail servers check that email claiming to come from your domain really comes from you. SPF and DKIM do the checking. DMARC ties their results to the From address your readers see, and tells receivers what to do with mail that fails.

This guide is for people who send email (marketers, founders, small teams), not full-time DNS admins. You'll learn what each record checks, how the three work together, the order to set them up in, and what to do when SPF and DKIM pass but DMARC still fails.

Short answer

1. Publish one SPF record that lists every service that sends email for your domain.
2. Turn on DKIM signing at each of those services, using your own domain.
3. Publish a DMARC record with p=none and a rua= address, so you get reports without affecting delivery.
4. Read the reports, fix the gaps, then move the policy to p=quarantine and later p=reject.

SPF, DKIM and DMARC at a glance

SPF (Sender Policy Framework) is a TXT record that lists the servers allowed to send mail for your domain. The receiving server compares the server that delivered the message against that list. It checks the envelope sender (the Return-Path, or bounce address), not the From address people see. For the syntax and the common mistakes, read Sender Policy Framework (SPF) explained.

DKIM (DomainKeys Identified Mail) adds a digital signature to each message. The signature names a signing domain (d=) and a selector (s=), and the receiver fetches your public key from DNS to verify it. A valid signature shows the signed parts of the message weren't changed on the way, and that the signing domain takes responsibility for it.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of the other two. It checks whether SPF or DKIM passed for a domain that matches your From address, publishes your policy for mail that fails (none, quarantine or reject), and asks receivers to send you reports. Our post on what DMARC is and why you should use it goes deeper into policies and reports.

SPF vs DKIM vs DMARC: what each one checks

	SPF	DKIM	DMARC
What it checks	Is the sending server allowed to send for this domain?	Is the signature valid, and was the signed content left unchanged?	Did SPF or DKIM pass for a domain that lines up with the From address?
Which domain	The envelope sender (MAIL FROM / Return-Path), and the HELO name	The signing domain in d=	The domain in the visible From header
Where the record lives	TXT record on the domain itself, e.g. example.com	TXT record at selector._domainkey.example.com	TXT record at _dmarc.example.com
What it can't do on its own	Doesn't look at the From address; usually fails when mail is forwarded	d= doesn't have to match the From address; says nothing about what to do on failure	Authenticates nothing itself; it relies on SPF and DKIM results

The specs behind this are RFC 7208 for SPF, RFC 6376 for DKIM, and for DMARC RFC 9989, which replaced the widely referenced original, RFC 7489, in May 2026. The concepts in this guide (alignment, the three policies, aggregate reports) are the same in both.

How the three work together

When a message arrives, the receiver runs SPF and DKIM first. DMARC then takes those results and asks one question: did at least one of them pass for a domain that aligns with the From domain?

• If yes, DMARC passes, even if the other check failed.
• If neither passed with an aligned domain, DMARC fails, and the receiver looks at your policy: none (deliver as usual, just report), quarantine (treat as suspicious, usually the spam folder) or reject (refuse the message).

Receivers treat your policy as a request. They can still apply their own filtering, in both directions.

Alignment: relaxed vs strict

Alignment means the domain SPF or DKIM checked matches the domain in the From address. DMARC has two modes:

• Relaxed (the default): the domains only need to share the same organizational domain. mail.example.com aligns with example.com.
• Strict: the domains must match exactly. mail.example.com does not align with example.com.

A plain example. Your newsletter goes out with From: news@example.com:

Check	Domain it checked	Relaxed	Strict
SPF	Return-Path bounce@mail.example.com	Aligned	Not aligned
DKIM	d=example.com	Aligned	Aligned
DKIM	d=esp-mail.example.net (your provider's domain)	Not aligned	Not aligned

Most senders keep the default relaxed mode.

Do you need both SPF and DKIM for DMARC?

For DMARC to pass, one aligned pass is enough. In practice, set up both:

• Gmail and Yahoo ask bulk senders for both SPF and DKIM (see the next sections).
• They fail in different situations. When a message is forwarded, it arrives from the forwarder's server, which isn't in your SPF record, so SPF usually fails. A DKIM signature travels with the message and usually survives forwarding. The exception: mailing lists and some forwarders change the message (a footer, a subject tag), which can break the signature.

With both in place, one can cover for the other.

What the three records look like

These are examples for example.com. Use the exact values your sending services give you; don't copy these as they are.

SPF, a TXT record on example.com. This one allows Google Workspace and Mailgun and soft-fails everything else:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:mailgun.org ~all"

A domain must have exactly one SPF record. If a new service asks you to add theirs, add its include: to your existing record instead of publishing a second one.

DKIM, a TXT record at <selector>._domainkey.<domain>. Your sending service picks the selector and generates the key; you publish the public half. Here the selector is s1 and the key is a placeholder:

s1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=<public-key-from-your-provider>"

Many services give you a CNAME to publish instead, pointing at a key they host. Either way, the receiver ends up at s1._domainkey.example.com. Each signed message then carries a header that names the domain and selector, for example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:to:subject:date; bh=...; b=...

DMARC, a TXT record at _dmarc.example.com. This is the starting point: monitor only, with reports to a mailbox you read:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p= is the policy, rua= is where aggregate reports go, and an optional sp= sets a separate policy for subdomains. The lines above are in zone-file format. Most DNS providers' forms ask only for the type (TXT), the host (@, s1._domainkey or _dmarc) and the value.

What Gmail and Yahoo require

Both providers have authentication rules for everyone who sends to their users, with stricter rules for bulk senders. As of November 2026:

Requirement	Google, all senders	Google, bulk (5,000+ messages a day to Gmail)	Yahoo, bulk senders
SPF and DKIM	SPF or DKIM	SPF and DKIM	SPF and DKIM
DMARC	Not required	Required; p=none is accepted	Required, at least p=none, and it must pass
Alignment	Not required	From domain aligned with the SPF or DKIM domain	From domain aligned with the SPF or DKIM domain (relaxed is fine)
One-click unsubscribe	Not required	Required for marketing mail	Required, honored within 2 days
Spam rate	Below 0.3% in Postmaster Tools	Below 0.3% in Postmaster Tools	Below 0.3%

Google also asks for a DKIM key of 1024 bits or longer for mail to personal Gmail accounts. Yahoo strongly recommends a rua= address in your DMARC record. Yahoo doesn't define a bulk volume on its page, and Google's 5,000-a-day line applies only to Google.

Neither provider requires p=reject. Meeting the rules doesn't guarantee the inbox either; it makes your mail eligible to get there. Check the current Google sender guidelines and Yahoo sender best practices before you rely on this table. For the background on the 2024 change, read Gmail's new email delivery standards.

Set them up in this order

How to set up SPF, DKIM and DMARC without blocking your own mail:

1. SPF. List every service that sends email as your domain: your mailbox provider, newsletter tool, CRM, helpdesk, billing and any app that sends notifications. Add each one's include: (or IP range) to one SPF record. Stay within the limit of 10 terms that need a DNS lookup; going over makes SPF return an error. The SPF guide explains what counts.
2. DKIM. Turn on signing in each sending service, using your own domain, and publish the record or CNAME it gives you. Note the selector each service uses; you'll need it to check the record.
3. DMARC at p=none. Publish the monitoring record shown above, with a rua= address. Nothing changes for delivery yet.
4. Read the reports, then tighten. Aggregate reports show which servers send as your domain and whether they pass with alignment. Fix any legitimate source that fails, then move to p=quarantine, and later to p=reject. We suggest two to four weeks of clean reports at p=none before the first step; that's our recommendation, not a rule. Our deliverability monitoring stack guide covers reading DMARC reports.

Enforcement also unlocks your logo in the inbox: BIMI needs DMARC at p=quarantine or p=reject.

Check that it works

DNS changes can take a while to show up. Once they have, run the domain through our free SPF, DKIM and DMARC checker:

1. Enter your domain, or paste a full email address (the checker uses the part after the @).
2. If you know your DKIM selector, open Advanced options and enter it under DKIM Selector (optional). Leave it blank and the check looks for common selectors.
3. Click Check Domain.

You'll see a card each for the email provider, SPF, DKIM and DMARC, each marked Pass, Warning or Fail with the issues found. Show raw record displays the record as published, so you can compare it with what you meant to publish. On top you get an overall grade from A to F with a score out of 100, and below the cards a list of recommendations. A DMARC record at p=none shows a warning: that's expected while you monitor, and a reminder to tighten the policy later.

The checker covers your domain's setup. It doesn't check blacklists or spam reputation, and it doesn't tell you whether a particular mailbox exists.

Troubleshooting: all pass, DMARC still fails

SPF and DKIM pass, but DMARC fails. This is almost always alignment. Many sending services use their own domain for the Return-Path and sign with their own d= domain until you set up your domain with them. Both checks pass, but for the provider's domain, not yours. Look at the headers of a sent message (the Return-Path and the d= in DKIM-Signature), then follow the service's "custom domain" or "domain authentication" setup so DKIM signs with your domain.

SPF fails after forwarding. Forwarded mail comes from the forwarder's server, which isn't in your record, so SPF fails, and there's nothing you can add to fix it. Make sure DKIM is set up and aligned; it usually carries DMARC through forwarding.

SPF has too many lookups. Each include: and some other terms count toward the limit of 10, and includes can contain more includes. Remove services you no longer use, or move a sender to a subdomain with its own SPF record. The SPF guide lists what counts.

DKIM record not found. The record lives under a selector, so a checker has to know which one to look for. Find the s= value in the DKIM-Signature header of a message you sent, or in your sending service's settings, and enter it under Advanced options in the checker.

FAQ

Are SPF, DKIM and DMARC all required?

Not for every sender. Google asks all senders for SPF or DKIM, and bulk senders at Google and Yahoo need all three. Setting up all three is still the sensible default, because DMARC is what tells receivers to act on failures.

What's the difference between p=none, p=quarantine and p=reject?

p=none only asks for reports. p=quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder. p=reject asks them to refuse it. Start with none and step up once your reports are clean.

Does setting up all three guarantee the inbox?

No. Authentication shows your mail is really from you, which makes it more likely to reach the inbox. Receivers still weigh other signals, such as your spam rate.

Next step: check your domain

Check your domain with the free SPF, DKIM and DMARC checker, and fix what it flags.

Once your domain authenticates, make sure the list you send to is clean too. Verifying addresses reduces bounces and protects your sender reputation. Try the free email verifier on a single address, or sign up to clean a whole list with 200 free validations, no credit card required.