When your WordPress site sends an email (a password reset, a WooCommerce order confirmation, a contact form reply routed through an external service like Postmark or SMTP2GO) the receiving mail server has to decide whether to accept it. SPF is the first of three short entries you add to your domain’s DNS to help it decide. The entry is a plain-text list of the mail servers that are allowed to send email using your domain. When a message arrives, the receiver looks up your SPF entry, compares the server the message came from against the list, and records a result. “On the list” is one point in favour of delivery.
For a WordPress operator, the practical shape of SPF is this. Once you have installed a mailer plugin and configured it to send through an external service, that service’s mail servers need to appear in your SPF entry. Without that, Gmail, Outlook, and Yahoo see mail from your domain arriving from a server your domain has not claimed, and the deliverability consequences follow. The alternatives this publication covers, from Postmark through Brevo, SMTP2GO, and Amazon SES, each publish their own include string to drop in; the rest of this reference is how the record is put together, how it goes wrong, and what it does not cover.
What the record looks like
An SPF record is one TXT entry at the domain apex. It starts with v=spf1, lists authorised sources, and ends with a qualifier for everything else:
v=spf1 include:_spf.google.com include:spf.mailgun.org ~allThe three parts, left to right: the version tag, one or more mechanisms (here, two include: directives that fold in Google’s and Mailgun’s own SPF records), and a trailing all with a qualifier (~all for softfail, -all for hard fail). RFC 7208 is the authoritative specification; §3 of the RFC walks through each mechanism (a, mx, ip4, ip6, include, exists, redirect).
The two mechanisms a WordPress site uses in practice are include: for an external sending provider and, occasionally, ip4: or ip6: for a specific sending host. Most provider documentation gives the exact include string to add. The record must be a single TXT entry: publishing two SPF records on the same domain is a configuration error that fails SPF outright.
How receivers use the result
An SPF pass is a positive signal, not a guarantee. Receivers combine it with DKIM, DMARC alignment, sender reputation, and content filtering before accepting or rejecting the message. An SPF fail on an otherwise reputable sender may still deliver, if DKIM aligns and reputation is strong; conversely, an SPF pass from a brand-new sending domain is not enough to beat a cold-start reputation. The record is one input, weighted higher by some receivers than others.
Where SPF matters most is in combination with DMARC. DMARC requires at least one of SPF or DKIM to both authenticate the message and align with the From: domain the recipient sees. Without an aligned SPF or DKIM pass, DMARC fails, and a p=quarantine or p=reject policy will act on the result.
The 10-lookup limit, and how WordPress sites trip it
RFC 7208 §4.6.4 caps the number of DNS lookups an SPF evaluation may perform at 10 per message. Each include:, a, mx, ptr, exists, and redirect mechanism counts. A record that triggers more than 10 lookups fails with a permerror, which receivers treat as a hard SPF fail regardless of what the record otherwise says.
The failure mode on WordPress is cumulative. A site adds Google Workspace’s include for mailboxes, then a transactional provider for wp_mail() sending, then a marketing provider for newsletters, then a form-handling service, then a help-desk tool. Each include is a few lookups inside; the Workspace include alone pulls in several. The record hits 10 lookups before the operator notices, and SPF starts failing silently for every outbound message.
The fix is to flatten (hard-code the IPs the include would resolve to) or to drop providers from the record and rely on DKIM alignment for those senders. SPF flatteners exist as a service, but a flattened record goes stale as the provider’s hosts change; the maintenance cost is real. nanoPost’s SPF merger tool handles the common cases without flattening.
What SPF cannot do on its own
SPF authenticates the envelope sender (the SMTP MAIL FROM address, often called the return-path), not the From: header the recipient sees in their mail client. A message that passes SPF because the envelope sender is a provider’s bounce address can still carry a spoofed From: header the recipient trusts. DMARC closes that gap by requiring alignment between the authenticated identity and the visible From: domain.
SPF also does not survive forwarding. A message forwarded by a legitimate recipient’s server is re-sent from that server’s IP, which is not in the original domain’s SPF record. DKIM, which signs the message itself rather than authenticating the sending IP, does survive forwarding. The two authentication methods complement each other for this reason; DMARC’s requirement of alignment on either SPF or DKIM reflects it.
For the delivery chain SPF sits inside, see how email works on WordPress. For the DMARC side, see DMARC for WordPress email. For the full outbound setup walkthrough, set up DNS for WordPress email covers SPF, DKIM, and DMARC together.