SPF, DKIM & DMARC: The Complete Setup Guide for 2026

SPF (Sender Policy Framework): A DNS record that lists which mail servers are allowed to send email for your domain.

DKIM (DomainKeys Identified Mail): A cryptographic signature added to every outgoing email that proves the message wasn't altered in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy that tells receiving servers what to do when SPF or DKIM fails, and sends you reports on who's sending mail as your domain.

Quick Answer

Since February 1, 2024, Google and Yahoo have required all three for bulk senders sending 5,000+ messages a day to their users (Google Postmaster guidelines). Microsoft joined them on May 5, 2025 (dmarcian).

Maybe your ESP just told you to "add some DNS records." Maybe your emails started landing in spam. Maybe your IT team forwarded you a Google notice about authentication. Whatever brought you here, this guide walks you through the whole thing in one place, with copy-paste record examples you can adapt. If you're troubleshooting a wider deliverability problem, start with our email deliverability guide, the hub this article belongs to.

Why All Three Protocols Work Together (Not Separately)

SPF, DKIM, and DMARC each solve a different piece of the same problem, and none of them works fully on its own. SPF says which servers may send for your domain. DKIM proves the message wasn't tampered with. DMARC decides what happens when one of those checks fails, and reports the results back to you. Skip any one and you leave a gap that mailbox providers notice. As of mid-2026, only about 42% of domains actually enforce DMARC, which means more than half are still a spoofing and deliverability risk (technologychecker.io DMARC adoption statistics, 2026).

Here's the analogy that makes it stick.

The part that trips people up is alignment. You can pass SPF and still fail DMARC. DMARC requires that at least one of SPF or DKIM passes and that the domain it validated matches the domain in your visible From: address. Send from marketing@yourbrand.com while your SPF only covers your ESP's domain, and DMARC fails on alignment even though SPF technically "passed." Most ESPs fix this with a custom return-path domain. For the full mechanics of how each check verifies your identity, see our guide to email authentication protocols.

Step 1: Set Up Your SPF Record

An SPF record is a single TXT record that names every service allowed to send email for your domain. You publish one SPF record, list each sender with an include: statement, and end with a softfail or hardfail rule. SPF allows a maximum of 10 DNS lookups, and multiple SPF records on the same domain cause an automatic failure, so the goal is one clean record.

What an SPF record looks like

v=spf1 include:_spf.yourESP.com ~all

Each part does one job:

• v=spf1 sets the SPF version.

• include:_spf.yourESP.com authorizes a third-party sender. Replace this with the exact include string your provider gives you.

• ~all is a softfail for any server not listed. It's a safer starting point than the stricter -all hardfail.

How to add it in your DNS

1. Log in to your domain registrar or DNS host (GoDaddy, Namecheap, Cloudflare, etc.).

2. Open DNS Management and choose Add Record.

3. Set Name/Host to @ (or leave it blank, depending on the registrar).

4. Set Type to TXT.

5. Paste your SPF string into the Value field.

6. Save, then wait 24 to 48 hours for the change to propagate.

The SPF 10-lookup limit (the gotcha nobody warns you about)

SPF caps out at 10 DNS lookups, and every include: you add counts against it. Send through your ESP, your CRM, and a transactional tool at once, and you can quietly blow past the limit. When that happens SPF returns a "PermError" and fails silently. Count your lookups with the MXToolbox SPF checker before you assume you're fine.

Warning: Add your ESP's include string to your existing SPF record. Don't create a second one. Two SPF TXT records on the same domain make SPF fail outright, and that's one of the most common setup mistakes we see.

Step 2: Set Up DKIM

DKIM adds a cryptographic signature to the header of every email you send. Your sending server signs the message with a private key, and the receiving server checks that signature against a public key published in your DNS. If anything in the message changes in transit, the signature breaks and DKIM fails. You don't generate DKIM keys by hand. Your ESP creates the key pair and hands you the record to publish.

Generate your DKIM keys

In most platforms you'll find this under Settings > Sending Domain > Authenticate Domain. The platform generates the key pair and shows you a TXT record to add. The generic format looks like this:

Name/Host: [selector]._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=[public key string]

The [selector] is a label your provider assigns, often something like s1, google, or your ESP's name. Paste the record exactly as given, including the long public key string.

Verify your DKIM

After DNS propagates, send a test message to mail-tester.com or run a check with the MXToolbox DKIM lookup. A pass means the signature is valid and your key is published correctly.

Warning: If you switch ESPs, your DKIM signing key changes, even when the visible sending domain stays the same. That usually means re-warming your sending reputation. This is the kind of detail that surprises teams mid-migration, and it's why authentication isn't a one-and-done task. For more on rebuilding trust on a new setup, see our guide to domain warm-up.

Step 3: Set Up DMARC

DMARC is the policy layer that ties SPF and DKIM together and reports back to you. You publish one TXT record at _dmarc.yourdomain.com that sets a policy level and a reporting address. Start at p=none so you can watch what's happening before you enforce anything.

The three DMARC policy levels

A minimal copy-paste DMARC record

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

Add it to your DNS like this:

• Name/Host: _dmarc.yourdomain.com (or just _dmarc if your registrar appends the domain for you)

• Type: TXT

• Value: the string above, with your real reporting address

What the rua= tag does, and why it isn't optional

The rua= tag sets the address that receives aggregate DMARC reports. Mailbox providers send you XML files showing every server that sent mail claiming to be your domain, and whether SPF and DKIM passed. Drop the rua= tag and p=none gives you nothing but a policy with no visibility. LB Blair, strategic advisor at SendPost and SendX, put it plainly on a recent call:

"Big reason I'm a huge proponent of DMARC reporting, because a lot of people don't realize that info comes directly from the mailbox providers. Google, Yahoo, Gmail, Comcast, et cetera." — LB Blair, email deliverability consultant, October 2025

One caveat from that same conversation: not every provider sends reports yet. Apple doesn't return DMARC reports, so your iCloud traffic stays invisible in the data. Pipe your reports into a parser like EasyDMARC, dmarcian, or Validity so the XML becomes a readable dashboard instead of a folder of files.

Warning (LB Blair's biggest pet peeve): Plenty of ESPs hand you a generic DMARC record and tell you to publish it. If you already have a DMARC record doing your reporting, their template overwrites it and you lose everything.

"That's my biggest pet peeve. Don't overwrite people's. I keep seeing platforms telling people to put DMARC records on subdomains without checking to see if there's one on the parent. That ends up cutting you off from information that could be very valuable." — LB Blair, email deliverability consultant

Merge, don't replace. If your existing record is missing a rua= tag, add the tag to the record you already have.

Moving from p=none to p=reject

Don't rush to p=reject. Any service you forgot to authorize will have its mail bounced the moment you flip the switch. Work through it in stages:

1. Sit at p=none for 30 to 60 days and read your reports.

2. Identify every service sending mail on your behalf, including CRMs and transactional tools.

3. Make sure each one passes SPF or DKIM alignment.

4. Move to p=quarantine and watch for legitimate mail landing in spam.

5. After another 30 clean days, move to p=reject.

What Changed With Google and Yahoo's 2024 Requirements

On February 1, 2024, Google and Yahoo began enforcing new rules for bulk senders, defined as anyone sending 5,000 or more messages a day to Gmail or Yahoo addresses (Google Postmaster guidelines). Authentication stopped being best practice and became a delivery requirement. Here's what the rules actually say:

• All senders must have SPF or DKIM. No exceptions (Yahoo Sender Best Practices).

• Bulk senders (5,000+/day) must have SPF, DKIM, and DMARC at a minimum of p=none with a valid rua= reporting address.

• Spam rate must stay below 0.10%, with 0.30% as the absolute hard limit (Google Postmaster guidelines).

• One-click unsubscribe is mandatory for bulk senders, processed within two business days (Google Postmaster guidelines).

• May 5, 2025: Microsoft joined, requiring DMARC for bulk senders to Outlook.com, Hotmail.com, and Live.com (dmarcian).

If you send fewer than 5,000 a day, you aren't subject to the bulk-sender rules today. That's not a reason to skip setup. The threshold can drop, and providers are clearly moving toward universal enforcement. Setting up all three now is insurance, not overkill. For a deeper look at why Gmail in particular gets strict, see our notes on Gmail deliverability issues.

The state of adoption: As of mid-2026, only about 42% of domains enforce DMARC at p=quarantine or p=reject (technologychecker.io, 2026). That leaves roughly 58% sitting unauthenticated or stuck at monitoring-only, which is both a phishing risk and a deliverability liability. You can track the long-term trend through the DMARC.org adoption statistics, and there's a useful regulatory-context breakdown at DuoCircle's 2026 authentication analysis.

How to Verify Your Setup

Once your records propagate, confirm everything passes before you trust it. Free tools read your DNS and your email headers and tell you exactly which check failed. Don't assume a record works just because you saved it. Test it.

Testing tools

For a fuller rundown, our list of email deliverability testing tools goes beyond authentication into placement and reputation.

Reading your email headers

Open any received message and view its source. In Gmail that's "Show original." A fully authenticated message shows three passes:

Authentication-Results: mx.google.com;
  dkim=pass header.d=yourdomain.com;
  spf=pass (google.com: domain of you@yourdomain.com designates X.X.X.X as permitted sender);
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Three pass lines means you're fully authenticated. If one says fail, that's your starting point.

Debugging tip from LB Blair: When something fails at Google, the headers there are often thin. His workaround:

"Generally Microsoft gives more verbose error messages in the headers when authentication fails. So one of my tactics, if I see something's failing at Google, is to send it to a Microsoft account I have, to hopefully get a more robust mirror message." — LB Blair, email deliverability consultant, June 2026

Common Mistakes and How to Avoid Them

Most authentication failures come from a short list of avoidable errors. Get these right and you've cleared the bar that the majority of senders trip over. Each one below is a real failure mode, not a hypothetical.

1. Two SPF records. Multiple SPF TXT records on one domain cause a PermError. Merge them into one.

2. Blowing the 10-lookup limit. Every include: adds lookups. Check the count with MXToolbox.

3. Two DMARC records. Same trap as SPF. Two _dmarc TXT records are treated as a permanent fail. As LB Blair found while debugging a customer's setup, "if you have two DMARC records, [Google is] just gonna treat your DMARC as a fail no matter what." Check for duplicates before adding a new one.

4. Overwriting your DMARC with an ESP template. Generic provider records wipe out the reporting you already configured. Merge, don't replace.

5. Jumping to p=reject too early. Any unauthorized sender gets bounced the moment you enforce. Monitor at p=none first.

6. Wrong DKIM selector. If your ESP rotates keys, the old selector stops resolving. Update your DNS when keys change.

A surprising amount of "my emails go to spam" panic traces back to one of these six. If you want the broader picture on why mail lands in spam, our guide on why emails go to spam covers the reputation and content side.

What Comes After SPF, DKIM, and DMARC?

Once the three core records pass, a few next-level options build on them:

• BIMI (Brand Indicators for Message Identification) displays your logo beside your emails in supported inboxes. It requires DMARC at p=quarantine or p=reject first.

• MTA-STS enforces TLS encryption on email transport and blocks downgrade attacks.

• Ongoing DMARC report analysis is how you catch misconfigured senders, spoofing attempts, and forwarding breakage before they dent your reputation.

Conclusion

The path is simple to remember: SPF first, then DKIM, then DMARC at p=none, gather reports, and move to enforcement once your senders all pass. The work isn't hard. The discipline is in treating it as ongoing rather than one-time, because a new ESP, a DNS edit, or an added sending service can quietly break any of it.

Want the technical layer underneath all this? Our guide to email authentication protocols covers exactly how each protocol verifies your sending identity. And if you're sending transactional mail through SendPost, your DKIM and SPF setup is documented in our walkthrough on email authentication for transactional emails.

FAQ

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

If you send more than 5,000 emails a day to Gmail or Yahoo users, yes. Google, Yahoo, and Microsoft (as of May 2025) all require the full set for bulk senders. Below that volume, SPF and DKIM together are the minimum, and DMARC is strongly recommended regardless.

What happens if my DMARC fails?

It depends on your policy. At p=none, nothing changes and the message is delivered, but you get a report. At p=quarantine, failing mail goes to spam. At p=reject, it's bounced and never delivered. Start at p=none to gather data before you enforce.

How do I check if SPF, DKIM, and DMARC are set up correctly?

Use MXToolbox to inspect your DNS records, or send a test to mail-tester.com and read the authentication results. You can also open any sent message in Gmail, click "Show original," and check the three pass/fail lines directly.

Does Gmail require DMARC for all senders?

As of February 2024, Gmail requires DMARC at a minimum of p=none for bulk senders sending 5,000+ messages a day. Every sender, regardless of volume, must have at least SPF or DKIM. The full requirements live in Google's sender guidelines.

What is DMARC alignment?

Alignment means the domain in your From: header matches the domain that SPF or DKIM validated. Send from marketing@yourbrand.com while SPF only covers sendingservice.com and DMARC fails, because the domains don't align, even though SPF passed. Most ESPs solve this with a custom return-path domain.

My emails pass SPF but still go to spam. What's wrong?

Passing SPF doesn't guarantee the inbox. Placement also depends on sender reputation, list quality, engagement, and content. Authentication is the floor, not the ceiling. See our guides to email deliverability issues and email sender reputation.

What is DKIM-2 and do I need it now?

DKIM-2 is a next-generation standard under active development. It would sign at every hop and could eventually simplify or replace parts of SPF and DMARC. It is not deployed or required as of 2026. LB Blair, who's tracking it closely, sees it coming fast but still relies on today's tools:

"DKIM-2 is going to make authentication a whole lot simpler, and it's going to make maybe even SPF and possibly DMARC kind of irrelevant. Though they can pry those DMARC reports from my cold dead hands." — LB Blair, email deliverability consultant, April 2026

Treat DKIM-2 as a future concern. Implement SPF, DKIM, and DMARC now. They remain the required baseline.