What an SPF record does, and writing yours

SPF is a DNS record that tells receiving mail servers which hosts are permitted to send email using your domain in the SMTP HELO/EHLO and MAIL FROM identities. Receivers evaluate your policy during the SMTP transaction using the sender’s domain and the connecting client IP. Your record should authorise every service you use, exist as exactly one TXT record at the domain being checked, and end with an explicit default result.

Before you start

• This picks up from you controlling your domain’s DNS and knowing every system that sends mail for you. If your DNS is hosted with us on cPanel and your domain uses Hostworld nameservers (ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk, ns4.serverworld.uk), you can manage the record in cPanel.
• Publish SPF as a TXT record only. The old “SPF” type was removed from the protocol.
• Publish exactly one v=spf1 TXT record at any given name. More than one causes a permanent error and many receivers will treat evaluation as failed.
• Mechanisms are processed left to right. The first match decides the result. If nothing matches and there is no redirect, the result is neutral.
• The all mechanism must be last. Anything after all is ignored, and redirect is ignored if all is present.
• SPF evaluation may do at most 10 DNS lookups across include, a, mx, exists, ptr and redirect terms. Exceeding the limit is a permanent error. Void lookups should be limited too.
• Avoid ptr. Publishing ptr in SPF is discouraged as slow and unreliable.
• Sender ID records (spf2.0/… or PRA) are historic and not part of SPF.
• Place the TXT record at the exact domain being checked. That is the envelope MAIL FROM domain or the HELO/EHLO name. Publishing at “_spf.example.com” has no effect unless you reference it from a record at the domain being checked.
• If you never send mail from a domain, publish a policy that authorises no hosts, for example v=spf1 -all.
• Bulk senders to Gmail and Yahoo: as of February 2024 they enforce requirements for 5,000+ messages per day to their users. You must authenticate with SPF or DKIM and publish DMARC.

Step 1: List every system that sends email for you

SPF is an authorisation list. Miss a sender and that mail will not match your policy. Include:

• Your primary mail platform, for example Google Workspace or Microsoft 365.
• Your website or application servers that send directly.
• Marketing, CRM or ticketing platforms that send using your domain.
• Any subdomains that send, such as billing.example.com or mail.example.com.

Receivers evaluate SPF on the identities used in the SMTP transaction. They may check HELO/EHLO as well as MAIL FROM, and checking HELO first is recommended in the standard. If you run your own MTA and control the HELO name, publish SPF for that name as well.

Step 2: Choose your default result

SPF qualifiers map to outcomes:

• + pass
• - fail
• ~ softfail
• ? neutral

Records are evaluated left to right. The first match sets the outcome. The final all is your explicit default for any sender that did not match earlier terms:

• ~all says unauthorised mail should softfail. This is often chosen while you build and verify your record. Google cautions that a hard fail may be too strict if your record is incomplete.
• -all is a hard fail for everything not explicitly authorised. Use this once you are confident your policy covers every legitimate sender.

For DMARC, SPF must pass and be aligned with the RFC5322.From domain to count. Softfail or fail does not pass DMARC. That means legitimate mail must match an earlier mechanism and be aligned. The all qualifier does not help pass DMARC.

Step 3: Write a correct base record for common cases

Every SPF record must begin with exactly v=spf1. Publish one TXT record per sending domain or subdomain. Examples:

• Only Google Workspace
  v=spf1 include:_spf.google.com ~all
• Only Microsoft 365
  v=spf1 include:spf.protection.outlook.com ~all
• Google Workspace and Microsoft 365
  v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
• Domain that never sends email
  v=spf1 -all

These examples show the includes recommended by Google and Microsoft. If you use additional services, add their mechanisms to this one record. Keep all last. Do not create a second v=spf1 TXT record at the same name.

Step 4: Publish the TXT record at the right place

Publish SPF as a TXT record at the exact domain that appears in SMTP MAIL FROM or the HELO/EHLO name used by your sender:

• If your DNS is on Hostworld cPanel: use cPanel’s Email Deliverability to diagnose and install SPF when your domain’s DNS is on the server. If you prefer to edit manually, use cPanel’s Zone Editor to add a TXT record. Keep to one SPF record. We can host DNS when your domain points to our nameservers: ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk, ns4.serverworld.uk.
• If your DNS is elsewhere: sign in to your DNS host or registrar’s control panel. Add a single TXT record at the sending domain name with your SPF content. Editing DNS in cPanel when your DNS is authoritative elsewhere has no effect.

Details to get right:

• Type: TXT. Do not publish a separate type “SPF”.
• Name: the domain being checked. For example, if MAIL FROM is [email protected], publish at example.com unless you intentionally use a subdomain.
• Value: begins with v=spf1, followed by your mechanisms, and ending with ~all or -all.

Do not publish “spf2.0/…” or any Sender ID PRA records. They are historic and not SPF.

Step 5: Merge multiple services safely and stay within lookup limits

All authorised senders must be in the same record. Common tools:

• include: references the other domain’s SPF. SPF only uses the pass/not-pass result of that include and then continues evaluation. Example: include:_spf.google.com.
• redirect= hands evaluation over to another domain when nothing matched earlier. It is intended for domains under the same administration. It should appear last and is ignored if all is present. Do not redirect to domains you do not control.

Mind the evaluation limits:

• 10-lookup limit: include, a, mx, exists, ptr and redirect together may trigger at most 10 DNS lookups during a single SPF evaluation. Exceeding the limit yields a permanent error.
• Void lookups: receivers should limit NXDOMAIN or empty answers. Too many void lookups can also lead to a permanent error.
• MX and PTR extras: evaluating mx must not query more than 10 address records per MX name. ptr is rate-limited and discouraged for publication.

Practical tips:

• Prefer provider-maintained include: names for major services rather than hard-coding IPs. Avoid chaining many includes that themselves include others if it risks the 10-lookup limit.
• Do not add include: for a service that has no SPF. That returns a permanent error.
• Keep evaluation simple. The fewer mechanisms you need, the better.

Step 6: Keep the record small and syntactically correct

DNS imposes size rules:

• A single TXT “character-string” is limited to 255 octets. Longer SPF content must be split across multiple quoted strings. The strings are concatenated by DNS without adding spaces.
• Keep the full DNS answer small enough to fit within a typical UDP response (around 512 octets) to avoid truncation.

Example of a split TXT value if your line becomes long:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com "
"ip4:198.51.100.24 ip4:198.51.100.25 ~all"

Other points that break SPF and how to avoid them:

• Only one v=spf1 record per name. If you see two, merge the contents and delete the extra.
• Start with exactly v=spf1. Anything else at the start is not an SPF record.
• Put all last. Terms after all are ignored.

If you are not sure how to merge records or you are hitting lookup limits, open a support ticket and we will help you plan a compact policy.

Step 7: Verify the DNS record is live and unique

Check that exactly one v=spf1 TXT record appears at the name you intended, and that its content matches what you planned.

On macOS or Linux

These commands query the TXT records for your domain. They do not change anything.

# Query the root domain used in MAIL FROM (replace example.com)
dig +short TXT example.com

# If you publish SPF on a subdomain identity, query that name as well
dig +short TXT mail.example.com

Look for a single line that begins with "v=spf1. If you see multiple v=spf1 records at the same name, merge them into one in your DNS and remove the duplicates.

On Windows

Use nslookup to retrieve the TXT records.

nslookup -type=TXT example.com
nslookup -type=TXT mail.example.com

Again, verify there is exactly one v=spf1 record at each name you use. Confirm it ends with your chosen all qualifier.

Step 8: Align SPF for DMARC and meet bulk-sender requirements

DMARC requires either SPF or DKIM to pass and to be aligned with the RFC5322.From domain. SPF softfail or fail does not satisfy DMARC. If you want SPF to satisfy DMARC, ensure that your legitimate mail matches your SPF policy and that the domain used in MAIL FROM aligns with the From domain you present to recipients.

If you send 5,000 or more messages per day to Gmail or Yahoo users, their 2024 rules require you to authenticate with SPF or DKIM and to publish a DMARC record. SPF is one of the supported authentication methods, so a correct and aligned SPF record helps you meet that requirement.

Hostworld on cPanel: the short route

If your domain’s DNS is hosted on your Hostworld cPanel server, use cPanel’s Email Deliverability feature to install and validate SPF and DKIM. It generates a recommended SPF for mail sent from that server. If your DNS is hosted elsewhere, you can still see the recommended value in Email Deliverability, then add it at your external DNS host using their TXT editor. If you prefer a click-by-click walkthrough in cPanel, raise a ticket and we will point you to the right steps for your account.

What next

Publish DKIM and DMARC so receivers can authenticate your mail and enforce a policy. That is the next step in this playbook.

If you want dedicated control over outbound mail from your application, take a look at our UK location options on Linux VPS, or browse more of our VPS guides to choose an approach that fits how you build and send mail.

If something here does not match what you see, or you need help merging records or staying under the lookup limit, open a support ticket.