How to Add an SPF Record for a WordPress Site

First, the thing that confuses everyone

You will not find this setting in WordPress. There is no plugin to install and nothing in wp-admin to change. SPF is a DNS record, and DNS is separate from your site.

So the real question is: where is your DNS hosted? It is one of three places. Your domain registrar, where you bought the name. Your web host, if you pointed the domain at their nameservers. Or Cloudflare, or something similar, if you moved DNS there. Log in to whichever one it is, and look for a DNS records editor.

What SPF actually does

SPF is a list of who is allowed to send email using your domain name. You publish it, receiving mail servers read it, and anything sending from an address not on your list looks suspicious.

Without it, anyone can put your domain in the From line of an email. That is the everyday version of phishing your customers, and it is a lot more common than someone attacking your WordPress install directly.

Work out who sends mail for you

Do this before you write anything. Missing a sender is what causes real email to disappear later. Think through:

→Your mailbox provider. Google Workspace, Microsoft 365, or your web host's own mail server.
→Your WordPress site itself. Password resets, contact form replies, WooCommerce order confirmations. These send from your server, or through an SMTP plugin pointed at a mail service.
→Your marketing and transactional mail. Newsletter tools, invoicing, help desk, review requests.
→Anything else in your name. A booking system, an accountant's portal, anything that emails your customers as you.

Write one record, not several

This is the single most common SPF fault. A domain may only have one SPF record. Two records is not twice the protection, it is a permanent error, and receiving servers treat the whole thing as broken. That means every sender is unverified again.

It happens because people add a record for their mailbox, then months later add another for their newsletter tool. Merge them instead. One record, several include: parts, one all at the end.

Type:  TXT
Name:  @        (or leave blank, depending on the UI)
Value: v=spf1 include:_spf.google.com include:sendgrid.net ~all

That is an example combining two senders. Use only the includes for services you actually use. The Google Workspace value is include:_spf.google.com and Microsoft 365 is include:spf.protection.outlook.com. For any other service, get the value from that vendor's own documentation rather than from a blog post.

A note on SendGrid and similar services

Do not add an include for a service just because you use it. SendGrid is the clearest example. With Automated Security switched on, which is the default, SendGrid authenticates through CNAME records instead and no SPF include is needed at all. Adding one anyway wastes part of your budget for nothing. Only use include:sendgrid.net if you have deliberately turned Automated Security off.

This is a wider trend worth knowing. Vendors are moving away from "add our include" towards CNAME-delegated sending subdomains. Treat any include value you read anywhere, including here, as something to verify with the vendor at the time you set it up.

The 10-lookup limit

SPF allows a maximum of ten DNS lookups when it evaluates your record. Go over, and the record fails with a permanent error, exactly as if you had two records.

The mechanisms that cost a lookup are include:, a, mx, exists and redirect. Worse, they nest: an include can pull in a vendor record that has includes of its own, and those count too. The ones that are free are ip4:, ip6: and all.

In practice a small site with three or four senders is fine. If you have collected seven or eight includes over the years, check it. And if you use a vendor that offers CNAME-based setup, take it, because it does not touch your lookup budget.

Ending the record: ~all or -all

The last part tells receivers what to do with mail that is not on your list.

~all is softfail, meaning "this is probably not us". -all is fail, meaning "this is not us". ?all is neutral and does essentially nothing.

Vendors genuinely disagree here, so be sceptical of anyone who tells you there is one right answer. Google recommends ~all for Workspace. Microsoft recommends -all. Both are defensible.

Our advice: start with ~all. Leave it there while you confirm every legitimate sender is passing, which is exactly what DMARC reports are for. Then tighten to -all. Going straight to -all when you have missed a sender means real mail, possibly your WooCommerce order confirmations, getting rejected outright.

Entering it at your DNS host

The UI differs everywhere, but the pattern is the same. Add a TXT record, set the name to the root of your domain, paste the value.

→Cloudflare: DNS > Records > Add record > TXT, with @ as the name. TXT records are always DNS-only and cannot be proxied, so there is no orange cloud to worry about here.
→Namecheap: Advanced DNS > Add New Record > TXT, with @ as the host. Their own guidance is that the domain name itself should not go in the Host field. Allow around 30 minutes to apply.
→Route 53: leave the name blank for the apex, and the value must be wrapped in double quotes.
→Other registrars: look for TXT and use @ or a blank name for the root. If your host offers a specific SPF record type, it still writes a TXT record underneath.

Two more things worth knowing

Subdomains are not covered. Your SPF record at example.com does nothing for mail.example.com or news.example.com. If a subdomain sends mail, it needs its own record.

Domains that never send mail still need one. A parked domain or an old brand you kept is a free identity for a spammer. Give it v=spf1 -all, which says plainly that nothing sends from here.

Once the record is live, give it a little time to spread, then run a check to confirm it is being seen correctly.

Check your work in seconds

Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.

Run a free check

Frequently asked questions

Is there a WordPress plugin for SPF?

No, and any plugin claiming to add one is misunderstanding the problem. SPF is a DNS record, published by whoever hosts your DNS. That is your registrar, your web host, or Cloudflare. WordPress cannot publish DNS records for your domain.

I have two SPF records. Is that a problem?

Yes, it is a hard failure. The specification allows exactly one SPF record per domain, and receiving servers treat two as a permanent error rather than picking one. The effect is that none of your senders are verified. Merge them into a single record with multiple include mechanisms and one all at the end.

Should I use ~all or -all?

Vendors disagree, which tells you it is a judgement call. Google recommends ~all for Workspace and Microsoft recommends -all. Start with ~all while you confirm every legitimate sender passes, then move to -all once you are confident. If you jump to -all with a sender missing from your record, that mail gets rejected.

Do I need an SPF include for my contact form or WooCommerce emails?

It depends on how they are sent. If they go out through your web host's mail server, that host's SPF value covers them. If you use an SMTP plugin pointed at a mail service, that service's sending setup is what needs authorising, and many services now do this with CNAME records instead of an SPF include. Check the vendor documentation.

What is the 10-lookup limit?

SPF evaluation is capped at ten DNS lookups. Each include, a, mx, exists and redirect costs one, and they nest, so a vendor include can consume several on its own. Exceeding the cap fails the record entirely. ip4, ip6 and all cost nothing. If you have accumulated a lot of includes over the years, it is worth checking.

My domain does not send email. Do I still need SPF?

Yes. An unprotected domain is an easy one to forge. Publish v=spf1 -all on it, which says nothing is authorised to send from this domain at all.