Move from explanation to action with the matching DomainCheck.co.uk tools for this topic.
Confirm the domain is resolving cleanly before troubleshooting email delivery.
Useful when auditing email-related domains across many records or assets.
Escalate when email setup touches DNS, registrar access, and live business mail.
SPF is one part of email authentication, but it solves a specific problem: deciding which mail servers are allowed to send mail for your domain. That is different from MX routing and different from general DNS propagation. A separate article keeps the explanation focused and avoids mixing email security concepts together.
An SPF record is a DNS TXT record that tells receiving mail servers which servers are allowed to send email on behalf of your domain. SPF stands for Sender Policy Framework.
In plain English, it is a permission list. If a message claims to come from your domain, the receiving server can check whether the sending server is on that list.
SPF was created to reduce email spoofing. Spoofing is when a sender pretends to use your domain name in the envelope sender or related mail checks, even though they are not authorised to do so.
For a business, this matters because customers and suppliers may receive fake emails that appear to come from your brand. SPF helps receivers make a basic trust decision.
SPF can help verify whether a sending server is allowed to send for your domain, but it does not by itself make email secure.
SPF does not:
It is one control in a larger email authentication setup. In practice, it usually works alongside DKIM and DMARC.
SPF helps inbox providers see that your invoicing platform is allowed to send mail for your domain.
Your newsletter platform or CRM needs to be listed in SPF if it sends mail as your domain.
SPF can fail simply because the new DNS zone is missing the record or the TXT value was copied badly.
SPF will not solve reputation issues on its own, but it is one of the checks worth confirming first.
SPF is published in DNS, usually as a TXT record. The content names one or more allowed senders using SPF mechanisms and qualifiers.
The exact syntax can look technical, but the idea is simple:
Because the syntax can become complex, it is best to build SPF from the services you actually use rather than copying a random example.
| Part | What it usually means | Why it matters |
|---|---|---|
| v=spf1 | The record is an SPF policy | Signals that the TXT value is meant to be processed as SPF |
| ip4 / ip6 | Specific sending IP ranges | Useful for fixed mail servers or dedicated infrastructure |
| include | Pull in another provider's policy | Common with hosted email and marketing services |
| ~all / -all | How strict the policy is at the end | Controls what happens to senders not listed earlier |
A domain’s SPF record often needs to include providers such as:
If you send mail from multiple services, your SPF record must account for all of them. That is where many setups go wrong.
For a single hostname, you normally want one SPF policy published as one TXT record. If you accidentally create multiple SPF records for the same name, some receivers may treat the result as invalid or unpredictable.
That is why SPF should be managed carefully. People often add a new service, create another TXT record, and assume everything will merge automatically. It usually will not.
The usual problems are:
There is also a practical limit to how much SPF can do. The more services you add, the more careful you need to be with DNS lookups and maintenance. Some providers simplify this by using include mechanisms, but the exact behaviour depends on how the record is built.
SPF can become fragile when too many vendors are added to the same domain. If the record grows into a long chain of includes and lookups, maintenance gets harder and the risk of breakage goes up.
SPF is stored in DNS, so any update is subject to the same caching behaviour as other records. That means a corrected SPF record may not be visible everywhere at once.
If email starts failing after a DNS change, it is worth checking whether:
Sometimes the SPF value is right, but the new zone was not copied correctly after a nameserver move.
MX records and SPF records are often confused because they both live in DNS and both affect email. They do different jobs.
MX tells the world where to deliver mail for the domain.
SPF tells the world which senders are allowed to send mail using the domain.
You usually need both, but neither replaces the other.
If you need to edit SPF, use this order:
This is safer than editing the record from memory or using old snippets.
SPF issues often appear after:
That is because one overlooked sender can cause legitimate mail to fail authentication even though the mailbox itself still exists.
The simplest way to remember SPF is this: it is a public allow-list for sending mail. If your business sends from more than one system, that allow-list needs to match reality.
If the record and the actual sending systems drift apart, mail authentication can start failing without any obvious visible DNS error.
If a service sends mail on behalf of your domain, it should be in SPF. If it does not send mail, it should not be there.