Manage SPF records

The SPF record authorises servers for the SMTP MAIL FROM identity or, in some cases, HELO. It does not necessarily authenticate the address shown in From. If the server is not authorised, the outcome depends on the published policy; the receiver decides how to treat the message according to its own policy and the rest of the authentication. SPF helps fight spoofing, but it does not guarantee delivery.

In most cases you will not need to change the value recommended by Email Deliverability. Review the SPF and DKIM records and the PTR-related status there. The final qualifier, such as -all or ~all, is part of each policy and should not be changed without checking every sending source.

However, if mail is also sent from an external provider, you will need to add to the SPF the exact authorisation that provider gives you.

Before editing it, check which DNS servers are authoritative for the domain. If it uses our DNS, you can manage it from cPanel; if it uses Cloudflare or another provider, the change has to be made there. There must be a single TXT record starting with v=spf1: merge the new authorisations into that record and do not publish a second SPF.

To do this from cPanel, go to Email Deliverability and click Manage next to the domain you want to change.

Then find the SPF section and open Customize. Add only the mechanisms the external provider gives you, such as its IPs or include domains.

For example, if messages are sent from Google Workspace, add _spf.google.com to the list of includes.

Do not add Google to the SPF just because you read your mail in Gmail. If the Send mail as option delivers the message through the Hostsuar SMTP, the sending server is still Hostsuar, not Google. If Gmail sends it from its own servers, adding Google does not stop it going to spam either: we explain why here.

Save the customisation and then check the TXT published on the authoritative DNS. Also count the DNS lookups caused by include, a, mx, redirect and exists: an SPF evaluation cannot exceed ten, nested mechanisms included. If the provider suggests several include entries, check the total before adding them. Our SPF checker reads the record live from the authoritative servers, follows every include to the end and gives you the count.

Check the change without opening up the policy

Keep the previous value and test a sample from each sender: everyday mail, website, shop, CRM and campaigns. On the receiving side, check the SPF result and the domain it applies to. If the service uses its own return-path domain, changing the SPF of your visible domain may play no part in that check.

Do not use +all to make an error go away: it authorises any sender. Do not copy the IPs an include resolves to today to replace it with a fixed list either; the provider can change them. Check the lookup limit and remove only sources you have confirmed no longer send.

SPF does not replace DKIM and can fail after forwarding. To work out why a message was rejected, keep the actual error and also check DMARC alignment.