DKIM and SPF are the two DNS-based authentication standards that let mailbox providers (Gmail, Microsoft 365, Yahoo, and everyone else) verify that mail claiming to come from your WordPress site’s domain is actually authorised to send as that domain. Neither is WordPress-specific: they are internet-standard email authentication protocols that any sending domain needs. But every WordPress site that sends outbound mail (which is every site with password resets, comment notifications, WooCommerce order emails, or contact form notifications) depends on both being correctly set up.
Without SPF and DKIM published on your domain, Gmail rejects your mail outright since February 2024, and Microsoft 365 downgrades it to Junk. With both correctly configured, mail leaves your site’s authenticated pipeline, arrives at the receiving mailbox with a verified signature, and lands in the inbox.
SPF: which servers are allowed to send as your domain
SPF (Sender Policy Framework) is a TXT record published on your domain’s DNS that lists the servers and services authorised to send email as @yourdomain.com. It looks like this:
v=spf1 include:spf.mailgun.org include:_spf.google.com -allWhen a mailbox provider receives a message claiming to be from your domain, it looks up the SPF record on the domain, checks whether the sending IP matches one of the authorised includes, and decides whether SPF passes or fails. The -all at the end tells the receiver to reject any mail from an IP not on the list.
A WordPress site typically has one SPF record with multiple include: clauses, one per sending service. Your transactional email provider is one include. Google Workspace or Microsoft 365 (if your human mail lives there) is another. If your host’s own MTA is also sending mail, its include is a third.
DKIM: cryptographic signatures on every outgoing message
DKIM (DomainKeys Identified Mail) is a pair of DNS records on a provider-specific subdomain that publishes the public half of a cryptographic signing key. The provider signs every outgoing message with the private half; the mailbox receiving the message fetches your public key and verifies the signature.
The record lives at a subdomain that the provider tells you to use, typically something like s1._domainkey.yourdomain.com, and the contents contain the public key material:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...The key exchange happens on every message. If a message was altered in transit, or came from someone who does not hold the private key, DKIM fails and the message is treated as unauthenticated. DKIM is what proves the mail actually came from a service authorised to sign as your domain, rather than a spammer who happened to spoof the From header.
How they relate to WordPress specifically
WordPress calls wp_mail(), which by default falls through to PHP’s mail() function, which hands the message to the local host’s mail transport agent. Mail sent this way leaves the host’s shared IP with the host’s From address, not your domain’s. It is unauthenticated: no SPF alignment against your domain, no DKIM signature signed by your key.
A mailer plugin (FluentSMTP, WP Mail SMTP, Post SMTP) replaces that path with an authenticated connection to a transactional email provider (Postmark, SMTP2GO, Amazon SES, Brevo, and so on). The provider signs the outgoing message with a DKIM key aligned to your domain, and the provider’s sending IPs are covered by the SPF include you publish. Now the mail authenticates correctly: SPF passes because the IP is in your record, DKIM passes because the signature verifies against your public key, and the mail arrives at Gmail or Microsoft 365 with both checks green.
Every provider’s onboarding tells you exactly which SPF include to publish and which DKIM records to add. Copy the values from the provider’s admin panel into your domain’s DNS.
What happens if only one is set up
- SPF alone. Mail authenticates but a forwarding hop (an intermediate mail server relaying the message) can break SPF because the sending IP changes. Gmail’s post-February-2024 rules require either SPF or DKIM to pass with domain alignment; SPF-only is fragile. DKIM survives forwarding because the signature is on the message itself.
- DKIM alone. Mail authenticates cryptographically but the receiver has no positive signal that the sending IP is legitimate. Not enough for compliance with Gmail’s bulk-sender requirements; also enables partial spoofing.
- Neither. Rejected at Gmail, junked at Microsoft 365, silently dropped at Yahoo. The WordPress site technically sends mail; the recipients never see it.
Publishing both is a five-minute job at your domain registrar. Do it once, verify with the provider’s admin panel that both show green, and the WordPress site’s mail authenticates correctly forever after.
The extended guide, and the sending side
For the full DNS setup with DMARC layered on top, see How to set up DNS for WordPress email: SPF, DKIM, DMARC. For the sending-side of the equation (choosing a provider, configuring the mailer plugin), see How can WordPress send emails under my own domain name? and WordPress email setup: the complete guide.