Guide Email

How to set up an SPF record

How to build, publish and check an SPF record so receiving servers recognise your legitimate mail senders.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

An SPF record is a single line of text, published in your domain's DNS, that lists which servers are allowed to send email claiming to be from your domain. Receiving mail servers check incoming mail against it. Get the list wrong or leave a sender off it, and that sender's mail either fails the check outright or arrives marked as suspicious — so building the list correctly the first time is worth the extra ten minutes.

If you have not read SPF, DKIM and DMARC explained yet, it covers what SPF actually proves and how it fits alongside the other two records. This guide is the practical follow-up: building and publishing the record itself.

Step 1: list every service that sends as your domain

This is the step that takes the longest, and skipping it is the single most common reason a freshly published SPF record breaks something. Go through everywhere mail is sent using an address at your domain:

Your hosting mailboxes
Website contact forms or order confirmation emails
Newsletter or marketing email tools
Invoicing or accounting software
A CRM or helpdesk system
Any third-party app that sends "on behalf of" your address

Leaving something off this list is the actual risk

A sender missing from your SPF record does not necessarily bounce — most receiving servers still deliver it, just with a lower trust signal, which quietly increases the odds it lands in spam. The record still works technically even if the list is incomplete; it just protects less of your mail than it should.

Step 2: get the include value for each sender

Your hosting provider's mail servers are usually covered by an include: value shown in your control panel or welcome documentation — copy it directly rather than guessing. Every other service that sends mail on your behalf publishes its own include: value in its own setup documentation, typically under a heading like "email authentication" or "SPF setup".

Step 3: write the record

An SPF record always starts with v=spf1 and ends with an "all" mechanism. Everything in between is one include: per sender:

v=spf1 include:_spf.example-host.com include:example-newsletter-tool.com ~all

Part	Meaning
`v=spf1`	Marks this as an SPF record, version 1. Always first.
`include:`	Adds another provider's list of sending servers to yours. One per service.
`~all`	Soft fail. Anything not covered above is treated as suspicious but not rejected outright.
`-all`	Hard fail. Use only once you are certain the list above is complete.

Start with ~all, move to -all later

A soft fail gives you room to discover a sender you forgot without it being rejected outright while you find it. Once the record has been live a while with no legitimate mail failing, switching to -all closes the gap and stops anyone else sending forged mail as your domain.

Step 4: publish it as a TXT record

Open the DNS section of your control panel
Find where DNS records are managed for the domain.
Add a new TXT record
Set the host or name to @ (this represents the domain itself in most control panels — some show it as blank instead).
Paste the record as the value
Enter the full v=spf1 … line exactly as written, with no line breaks.
Check for an existing SPF record first
If a TXT record starting v=spf1 already exists on the domain, edit that one rather than adding a second — two SPF records is invalid and both are ignored.
Save
The record takes effect gradually as DNS changes spread; see how long DNS propagation takes for what to expect.

Checking it worked

Query the domain's TXT records from a command line:

dig TXT yourdomain.com +short
nslookup -type=TXT yourdomain.com    # Windows

Look for a single line starting v=spf1. If you see more than one, remove the duplicate. Several free online SPF checking tools will also parse the record and flag syntax errors or a lookup count approaching the limit of ten, which is worth running once before you consider the record finished.

Common mistakes

Two SPF records on one domain. Always merge into one record rather than publishing a second.
Exceeding the 10-lookup limit. Each include: counts, and some providers' includes chain to further includes of their own. Remove senders you no longer use rather than letting the list grow indefinitely.
Using +all. This explicitly authorises any server on the internet to send as your domain and should never appear in a real record.
Forgetting a subdomain that sends its own mail. SPF records are not inherited automatically by every subdomain in every configuration — check whether a subdomain sending mail independently needs its own record.

Once SPF is in place, move on to setting up DKIM and then setting up a DMARC record — the three work together, and DMARC in particular reports back on senders your SPF record may still be missing.

Frequently asked questions

Can I have more than one SPF record?

No. A domain must have exactly one SPF record. Two records is a configuration error that receiving servers treat as a failure rather than combining, so if you need to add a sender, extend your existing record with another include: instead of publishing a second one.

What is the 10-lookup limit?

Each include:, a, mx and a few other mechanisms in an SPF record triggers a DNS lookup when it is checked, and the standard caps a record at ten of these. A record that exceeds it fails for everyone, including senders that are correctly listed, so keep the number of include: statements as low as the services you actually use require.

Do I need SPF if I only send from my hosting mailbox?

Yes. Without any SPF record, receiving servers have no list to check a sending server against at all, which several major mailbox providers treat as a negative signal by itself. A short record covering just your host is still worth publishing even if nothing else sends on the domain's behalf.