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. Receivers evaluate SPF against the message’s envelope sender domain, not the visible From address. Google Workspace and Microsoft 365 publish SPF instructions for the domain used in their envelope sender. Postmark and SMTP2GO document provider-managed SPF on their default return paths. Amazon SES uses a subdomain of amazonses.com by default; if you configure a custom MAIL FROM domain, publish the MX and SPF TXT records AWS specifies on that domain. Brevo says SPF is not required for standard domain authentication; dedicated-IP setup provides SPF for the associated subdomain. Follow each provider’s instructions for the sending mode you use. The Postmark, SMTP2GO, Amazon SES, and Brevo pages cover each one’s setup. 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.
Corrections
- 2026-11-12: an earlier version said any external sending service’s mail servers need to appear in the domain’s SPF record and that Postmark, Brevo, SMTP2GO, and Amazon SES each publish an include for the root. SPF is evaluated for the envelope sender domain. Postmark and SMTP2GO document provider-managed SPF on their default return paths; Brevo’s SPF setup depends on sending mode; Amazon SES uses its own MAIL FROM domain by default and specifies MX plus SPF TXT records for a custom MAIL FROM domain.