SPF, short for Sender Policy Framework, is a DNS record that allows a domain owner to say which servers are allowed to send email on behalf of that domain. In practice, it is one of the basic technical pillars of email trust and deliverability, because the receiving side can check whether a message came from an authorised source or from a foreign server only pretending to use the domain.

Put simply, SPF is a list of permitted sending sources. If an email arrives from somewhere else, that is a warning signal for spam filters and receiving systems that the message may not be legitimate.

At first glance, SPF can look like one more hidden DNS detail that only matters to mail administrators. In reality, it matters to any business or website that sends email from its own domain. As soon as a company uses normal staff mailboxes, a newsletter tool, a CRM, a webshop, a billing system, Google Workspace, Microsoft 365 or another sending platform, SPF becomes part of the domain’s real email infrastructure.

What SPF actually checks

This is one of the most important things to understand. SPF does not mainly check the address the ordinary recipient sees in the From field. Instead, it checks the technical sending identity used during SMTP delivery – most often the MAIL FROM domain, also commonly associated with the Return-Path.

That matters because many people assume SPF directly protects the visible From address on its own. That is not fully correct. SPF is valuable, but by itself it does not authenticate the visible sender identity in the way many non-technical users first imagine. That is one of the reasons why SPF is normally discussed together with DKIM and DMARC.

In practical terms, SPF answers a very specific question: Was this server allowed to send email using this domain as the envelope sender identity? That is already extremely useful, but it is still only one layer of email authentication.

Why SPF matters

SPF matters because email is easy to forge at the visible level. Without technical checks, attackers can try to send messages that appear to come from a real company domain even when the sending server has nothing to do with that company.

A properly configured SPF record helps in several ways:

• it limits domain spoofing – an attacker cannot freely use your domain from any random server without creating a technical mismatch,
• it improves trust signals – receiving systems can see that your domain has at least one basic authentication layer properly declared,
• it supports deliverability – SPF is no longer an optional bonus for serious senders, but a basic technical expectation,
• it makes troubleshooting easier – when mail fails, SPF helps narrow down whether the issue is caused by an unauthorised sending source.

One important clarification: SPF alone does not guarantee inbox placement. It is an important signal, but it works alongside other factors such as DKIM, DMARC, IP reputation, complaint rates and overall mailing quality.

What an SPF record looks like

SPF is normally published in DNS as a TXT record. A simple example may look like this:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.mailprovider.example -all

At first sight, that string can look confusing, but the individual parts follow clear logic:

• v=spf1 – declares that this is an SPF record in SPF version 1 format,
• ip4:203.0.113.10 – allows a specific IPv4 address to send mail,
• include:_spf.google.com – includes the sending policy of another service, such as Google Workspace,
• include:spf.mailprovider.example – allows another external provider to send on behalf of the domain,
• -all – says that all other sending sources should be treated as not authorised.

That is why SPF is best understood as a structured policy rather than as one yes-or-no switch. It tells receiving systems which technical sources are allowed, and what attitude they should take towards everything else.

The SPF mechanisms people see most often

In real setups, a few SPF elements appear again and again:

• ip4: – allows a specific IPv4 address or range,
• ip6: – allows a specific IPv6 address or range,
• include: – imports the SPF policy of another provider,
• a – allows the IP address resolved from the A record of the domain or hostname,
• mx – allows the IP addresses of servers listed in the domain’s MX records.

And then there are the qualifiers at the end:

• ~all – softfail, a softer signal that other sources are not expected to be legitimate,
• -all – hard fail, a stronger statement that other sources are not authorised,
• ?all – neutral, which usually does not help very much in practice,
• +all – effectively allows everything, which defeats most of SPF’s practical purpose.

In day-to-day operations, ~all is often used during transition or cleanup phases, while -all is used when the sending infrastructure is already well mapped and controlled.

How to build SPF in real life

The practical setup process is usually straightforward in theory, but often messy in reality.

A sensible approach is usually this:

• list every system that sends email on behalf of your domain,
• check what each provider requires – some give IP addresses, others require an include: mechanism,
• combine everything into one SPF record, because one domain should have one effective SPF TXT policy,
• publish that record in DNS,
• test with real messages as well as DNS-level validation.

The biggest problem is usually not adding the record itself. It is forgetting one of the systems that sends mail for the domain. Companies often think only about normal employee mailboxes, but email may also be sent by a webshop, contact forms, invoicing software, CRM workflows, marketing tools, helpdesk systems or another automated platform.

If one of those senders is missing from SPF, its mail may start looking unauthorised even though the business itself genuinely uses that service.

Examples of SPF records and what they mean

Simple SPF for one IP address
v=spf1 ip4:203.0.113.10 -all

This means only that one server is authorised to send mail for the domain. Everything else should be treated as unauthorised.

SPF for Google Workspace and one mailing platform
v=spf1 include:_spf.google.com include:spf.example-newsletter.com -all

This means Google and the specified email platform may send on behalf of the domain.

A more cautious transition version
v=spf1 include:_spf.google.com ~all

This means Google is authorised, while other sources are treated as suspicious rather than firmly rejected. This is often used when a domain owner is still verifying whether every legitimate sender has already been included.

The most common SPF mistakes

SPF usually goes wrong in a few predictable ways:

• there are multiple SPF TXT records trying to act as separate SPF policies for the same domain,
• a legitimate sender is missing, often after a new CRM or marketing tool is added,
• old services remain in the record long after they stopped being used,
• the record becomes too complex and relies on too many external lookups,
• subdomains are ignored even though sending also happens from a dedicated mail subdomain,
• +all is used, which weakens the whole point of SPF.

Another practical mistake is expecting SPF to solve identity problems that belong to DKIM or DMARC. SPF is useful, but it was never designed to solve every email trust problem by itself.

What SPF does not solve

SPF is important, but it does not answer everything.

By itself, SPF does not tell you:

• whether the message content is relevant or wanted,
• whether the sender has a good reputation,
• whether recipients actually want these emails,
• whether the visible From address fully matches the authenticated identity the way a business may expect,
• whether a forwarded message will preserve the same technical behaviour.

That is exactly why SPF is usually discussed together with DKIM and DMARC. SPF helps answer whether the sending server was authorised. DKIM helps prove message integrity and domain-based signing. DMARC then adds policy and alignment around the visible sender identity.

How SPF relates to DNS, nameservers and mail routing

SPF only works because it is published in DNS and served by authoritative nameservers. That means SPF is not an isolated email switch. It is part of the wider DNS configuration of the domain.

It is also useful to understand what SPF is not. It is not the same as an MX record. MX records handle where incoming mail should be delivered. SPF, by contrast, describes which servers are allowed to send mail for the domain.

And it is not the same as a CNAME alias either. SPF is a TXT-based policy record, not an alias from one hostname to another.

Why this term is worth understanding even outside technical roles

SPF is one of those terms that many people only meet when emails start landing in spam or when a domain is being protected more seriously. Yet it is one of the clearest examples of how email trust depends on the technical layer behind the message, not only on the wording the recipient sees.

If you understand what SPF does, it becomes much easier to understand why one platform can send successfully while another suddenly fails, why adding a new mailing service affects deliverability, or why a company domain can be technically spoofed if authentication is weak.

That is why SPF matters not only to mail administrators, but also to marketers, founders, e-commerce operators and anyone whose business relies on email sent from its own domain. It is a quiet DNS record, but one of the most important ones in everyday email infrastructure.

Related terms

• DNS – SPF is published as a DNS TXT record, so its role only makes full sense within the broader logic of DNS.
• Nameservers – SPF records are stored on authoritative nameservers and served from there to the rest of the internet.
• TXT record – the DNS record type normally used to publish SPF.
• MAIL FROM / Return-Path – important because SPF mainly checks the SMTP envelope identity, not the visible From header.
• MX records – useful for contrast, because MX handles incoming mail routing, while SPF defines authorised outgoing sending sources.
• CNAME – another DNS record type, but with completely different purpose from SPF.
• DKIM – a related authentication method that signs email cryptographically and works alongside SPF.
• DMARC – the policy layer that builds on SPF and DKIM and helps connect authentication to the visible sender domain.