Understanding SPF and DKIM Authentication (and Where DMARC Fits)

Gmail bouncing your order receipts with “Gmail requires all senders to authenticate with either SPF or DKIM”? Your host says to add SPF and DKIM records, and you don’t know what those are or who gives them to you? Or your contact form says “sent” and the email lands in spam?

Search “what is SPF?” or “what is DKIM?” and the answers about email authentication tend to start with RFCs and acronyms. And you’re nervous about touching DNS and breaking the email that still gets through.

Frustrating, yes. Fixable, also yes. Here’s what we’ll do: learn what SPF and DKIM authentication checks, add what’s missing without breaking what works, and send a test email from your site to prove it.

Why Gmail turned your email away, and what proves it’s yours

Gmail checks your email’s ID at the door, and SPF, DKIM and DMARC are the three email authentication records it checks against. All three live in your domain’s DNS, the internet’s public directory for your domain.

Record	What it checks	Where it lives
SPF	Was the email sent from a server your domain allows?	A TXT record at example.com
DKIM	Does the email carry a valid signature for your domain?	A public key at selector._domainkey.example.com
DMARC	Did SPF or DKIM pass for the From address’s domain, and what happens if not?	A TXT record at _dmarc.example.com

Your order receipts, password resets and form notifications, the transactional email your site sends, get checked too.

What is SPF?

SPF (Sender Policy Framework) is a list of the servers allowed to send email for your domain, published as one TXT record. Receiving servers compare the delivering server’s IP address with that list, and SPF authentication passes if it’s there.

One catch: SPF checks the domain in the envelope sender, an address servers use while handing the message over, not the From address your customer sees. DMARC closes that gap.

Here’s an example SPF record (swap in your own services):

v=spf1 ip4:192.0.2.10 ip4:198.51.100.0/24 include:_spf.example.net ~all

Part	What it tells the receiving server
v=spf1	Marks this TXT record as your SPF record. Other TXT records are ignored.
ip4:192.0.2.10, ip4:198.51.100.0/24	This IP address, and any IP address in this range, may send.
include:_spf.example.net	Servers listed in another service’s SPF record may send. This is how you add a sending service.
~all	Any other IP address gets a “softfail”.

What ~all, -all, ?all and +all tell receiving servers

The last part of your SPF record covers every server you didn’t list:

• ~all (softfail): probably not allowed.
• -all (fail): not allowed.
• ?all (neutral): no opinion, treated the same as no SPF record.
• +all (pass): every IP address in the world may send as you. That’s a guest list that says “everyone.” Never use it.

The SPF standard (RFC 7208) says softfail alone shouldn’t get a message rejected, while Google’s SPF page says ~all tells receivers to mark that mail as spam.

With -all, Gmail rejects that mail outright. Google recommends ~all, and so do we.

One domain, one SPF record

If your domain already has an SPF record, add to that one; the services it lists stay as they are. Two SPF records break SPF for every message (a “permerror”). A long record stays one TXT record too, holding several strings of up to 255 characters that receivers read as one.

Each include, a, mx, ptr, exists and redirect counts as one DNS lookup, nested includes count too, and more than 10 lookups in total is a permerror.

What is DKIM?

With DKIM (DomainKeys Identified Mail), the service that sends your email signs each message with a private key that never leaves it. The matching public key sits in your DNS, so receivers can verify the signature.

The DKIM signature covers the body and the headers it lists, always including From. If any of those change on the way, DKIM verification fails. Nothing in the email is encrypted.

Your DKIM key goes in a DNS record like this

The record’s name is a selector (a label the sending service picks), then _domainkey and your domain. The standard uses a TXT record, but follow your sending service’s instructions on the type.

Here’s a working example, with a throwaway key we made for this page. Don’t publish it: your sending service gives you your own.

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxq9d66G98C1cbmfFYB4ea14cnFveEGXEs7Oe5qtcZGXgGPPgFzca9Is94JVOG1EZA7DGjM6YeMELCd4IGVFJDTTqAoLNBlAgEeX4N2MSRewOnFvt3Ph6Op3SEMnEzwd72KbbbTvMh00s0YgjMNy5nOZ/oGYsoq664GWN5nAcu9dpwBqBPxS4+UwH1gaVD3oB2hsCBzGDLcdRX3B+hdMTG/C6CrZ5y9jLnz+sRCJ+iOxIfeKVxMXqm6bwIF0U/x4nuLV8N+CC/CupsDD7iI6fITfYjiWrAugmo1vIfsfY0CceIZER1xnavmJfp45yudgbyOkOTxxNAJ3ScHGN8ef+TQIDAQAB

p= is the public key, and k= is the key type: rsa, or ed25519.

You’ll see k=rsa-sha256 in older examples, including an earlier version of this page. It isn’t a valid value, and in our test the check failed with it.

Each email carries a DKIM signature in its header

Here’s the DKIM signature our example key produced:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 [email protected]; q=dns/txt; s=selector1; t=1790991585; h=from : to :
 subject : date; bh=xnMwzZvPgT0WRhrd1ka7kk2P8LOAUGjtAkS6QIoki74=;
 b=WEJW7NKSw+QGx3Q/80iJudn2jW/jooDv/3rLSd9WmrMoBtdev1al1Py3HDC3HIBTrfbQz
 fTOHw52fiEH5UJADi/0VtFsteQTwSXf5EaZANP+X1fvNJ9csbESYzXlikPNtNpZA/2S1Mxc
 K4IFyH2nko1QYCww0818GeD8SgthVMT3z+F65q0B/raKVsCpiHduJHICDcGFwA469jwX3To
 7aVjTff38XcPgSb7Bq8mjkLi+IY6c9YzVmsnvpUmsY9h8gATrhOTLz/S6d7hgfWkl3dPdHb
 YV0gkN7kO8VuyPujpzdnL7DP5YoB3/rLIIL8gQd9uNYOLkwAN7dHVS9pItxw==

The part you’ll use later is d=, the domain that signed and where receivers look up the key to verify it. b= is the signature itself.

Does DKIM depend on the sending IP address?

No. DKIM verification uses the DKIM signature, the message and the public key from DNS. The sending IP address isn’t part of it, and the DKIM standard (RFC 6376) never mentions IP addresses.

That’s the difference between the two: SPF checks the IP address of the server that delivered the message, and DKIM checks the signature. So a signed message passes DKIM authentication from any IP address, as long as nothing it covers was changed. Receivers can still weigh an IP address’s reputation separately, but that isn’t DKIM authentication.

What is DMARC?

DMARC ties SPF and DKIM authentication to the From address your customer sees. A message passes DMARC when either SPF or DKIM passes for a domain that matches your From domain.

That match is called alignment. By default it’s relaxed, so mail signed by mail.example.com counts for a From address at example.com. Strict alignment wants the exact domain.

Your DMARC policy, p=, tells receivers what you’d like done with your mail that fails:

• none: nothing changes in how receivers handle your mail.
• quarantine: treat it as suspicious.
• reject: treat it as not really from you.

Under quarantine or reject, Gmail can bounce your own mail if it fails, so you start at none.

Add rua= with an email address and receivers send aggregate reports there, as XML files. Gmail doesn’t send the other kind, forensic reports. DMARC is now defined by RFC 9989, which replaced RFC 7489 in May 2026.

Do you need SPF, DKIM and DMARC?

Since February 2024, Gmail and Yahoo ask every sender for SPF or DKIM email authentication at minimum, transactional email included. Miss Gmail’s or Yahoo’s rule and your mail can go to spam or bounce, like the message at the top of this page.

Send them a lot of email and you need SPF and DKIM, plus DMARC. For Gmail, that’s close to 5,000 messages a day to personal Gmail accounts, counting all mail from your primary domain (Google’s sender guidelines), and Yahoo gives no number (Yahoo’s sender requirements). We’d set up all three anyway, as Google recommends.

Google and Yahoo require one-click unsubscribe only for marketing mail, not transactional email, so set up one-click unsubscribe if you send marketing too. Every sender also needs to keep its spam complaint rate below 0.3%.

Set up SPF and DKIM authentication for everything that sends as your domain

Here’s the order Google’s own setup pages give:

1. List every service that sends email as your domain: your WordPress site, your mailbox provider, a newsletter tool. Google’s list even includes “Contact us” forms.
2. At your DNS host (whoever runs your domain’s DNS, not always where you bought it), find your domain’s TXT record starting v=spf1, if there is one.
3. Get each service’s SPF value and DKIM record from its setup instructions. Add each SPF value to your one SPF record, never a second one, and each DKIM record the way the service asks.
4. Wait for DNS to update, which can take up to 48 hours. Then send a test email through each service and verify it, as in the next section.

That’s it for the services you know about. The easy one to forget is your WordPress site.

The SPF and DKIM records for your WordPress site

By default, WordPress hands its transactional email to your web host, and many hosts block or throttle it. Google’s advice holds whatever sends it: “If you use an email service provider, verify that they authenticate your domain’s email with SPF and DKIM.”

Our suggestion is SendWP, a paid transactional email service for WordPress, because unauthenticated WordPress email is the problem we built it for. Once your site is connected, every email it sends goes out through SendWP instead of your host, and your SendWP account shows you the SPF and DKIM records to add for your domain. Our docs walk you through how to add the SPF record and add the DKIM record.

SendWP can also give you the most basic DMARC record to publish. Choosing a policy and reading the reports stay with you.

How do I check that my email passes SPF, DKIM and DMARC?

Verify your email authentication with a real transactional email from your site, and let Gmail tell you how it did. It’s free, and it tests the email your customers get.

1. Send something from your site to a Gmail address you control, not the mailbox your site sends from: a password reset or a test form submission.
2. Open it and click the down arrow below the sender’s name. Google says it’s authenticated if you see a “Mailed by” line with a domain name and a “Signed by” line with the sending domain. A question mark next to the sender’s name means it isn’t.
3. For the detail, click More next to Reply, then Show original. Find the “Authentication-Results” header and verify it shows spf=pass and dkim=pass.

Before you add DMARC, look at the domain beside each pass, as in spf=pass smtp.mailfrom=example.net and dkim=pass header.d=example.com. DMARC passes when at least one is your From domain or a domain under it. For a From address at example.com, that’s DKIM here, since example.net doesn’t match.

If something didn’t pass:

What you see	What it means	What to do
“best guess record”	SPF is missing or set up wrong.	Check you have one SPF record with the right syntax.
spf=softfail, fail or neutral	The sending server’s IP address isn’t in your SPF record.	Add that service to your SPF record.
spf=permerror	Two SPF records, or more than 10 lookups.	Merge into one record and cut lookups to 10 or fewer.
No DKIM result	The message carries no DKIM signature.	Redo the DKIM steps for that service.

Read your records straight from DNS

Any DNS lookup tool shows what your domain publishes, or use dig:

dig +short TXT example.com
dig +short TXT _dmarc.example.com

You want one line starting v=spf1 from the first, and, once you’ve added DMARC, one starting v=DMARC1 from the second.

Add DMARC once SPF and DKIM are passing

Once your test email shows spf=pass and dkim=pass, you’re ready. Google says to set up SPF and DKIM at least 48 hours before DMARC, and to start with p=none. That start can’t hurt your mail: the DMARC standard says none must not change how receivers handle it.

Add this record at your DNS host, swapping in your domain and a mailbox at that domain:

Type	Name	Value	TTL
TXT	_dmarc.example.com	v=DMARC1; p=none; rua=mailto:[email protected]	Your DNS host’s default

Some DNS hosts add your domain to the name, so verify the saved name is exactly _dmarc. plus your domain. Then:

1. Send another test email from your site and check it as before. Google’s advice is to verify messages pass all three checks: SPF, DKIM and DMARC.
2. Read the reports daily for about a week, which Google says is usually enough for them to “contain data representative of all your mail streams.” Google warns they can arrive in high volume and suggests a dedicated mailbox or group, or a service that specializes in DMARC reports, rather than your own inbox.
3. Fix any service that fails by giving it SPF and DKIM records, as in the setup section.
4. Move p=none to p=quarantine, then p=reject if you want the strictest setting. If Gmail starts bouncing mail with “Unauthenticated email from [your domain] is not accepted due to domain’s DMARC policy”, a sender you missed is usually failing, so go back to none while you fix it.

Give your WordPress email the ID Gmail and Yahoo ask for

You came here with a bounce, or a host’s instruction, that named SPF and DKIM. Now your email carries the ID Gmail checks at the door: SPF and DKIM email authentication, and you’ve seen it pass on a real message.

From here, keep DMARC at none until the reports are clean, then tighten it. DNS is nobody’s idea of fun, and you got through it. Nice work.

For the transactional email your WordPress site sends, we think SendWP is the easiest way to get SPF and DKIM authentication in place: one connection moves every email WordPress sends onto one service, so there’s one sender to set up for all of it. See what SendWP costs.