What is SPF and how does it work?

8 May 2026 · 13 min read

Every day, mail servers across the internet receive messages claiming to come from your domain. Some are genuine: your invoices, your password resets, your newsletters. Some are not: phishing attempts, spoofed invoices, and outright fraud sent by people who have never had any authority over your domain. The receiving server has to make a fast decision about which is which, and one of the oldest signals it relies on is SPF.

SPF, the Sender Policy Framework, is a way for you to publish a public list of the mail servers that are allowed to send email for your domain. A receiver can read that list and check whether the server in front of it is on it. If you have ever wondered how Gmail or Microsoft decides that a message "failed authentication", SPF is usually part of the answer.

This article explains what SPF actually is, how the syntax works (including the much-misunderstood all qualifier and each mechanism), what SPF does and does not authorise, the practical limits that trip people up, and the crucial gap that SPF leaves open: it checks an address your recipient never sees. Closing that gap is the job of DMARC alignment, and we will cover exactly how the two fit together.

The problem SPF was built to solve

In the original design of email, any server could connect to any other server and say "I have a message from billing@yourcompany.com". Nothing in the protocol forced that claim to be true. There was no step where the receiving server asked "wait, are you actually allowed to send for that domain?" The Simple Mail Transfer Protocol, SMTP, was built on trust between a small number of cooperating machines, and that trust did not survive contact with a hostile internet.

SPF was introduced to add exactly that missing step. The idea is simple and powerful: the owner of a domain is the right person to declare which servers are authorised to send its mail, and DNS is a public, authenticated place to publish that declaration. So you publish a record in your domain's DNS that lists your approved senders, and any receiver in the world can look it up and verify the connection against it.

It helps to be precise about which "from" address SPF is talking about, because email has two of them and they do not have to match.

• The envelope sender, also called the MAIL FROM address or the Return-Path. This is exchanged during the SMTP conversation between the two servers. Your recipient almost never sees it.
• The header From, the friendly From: line that appears in the inbox. This is the address a human reads and trusts.

Hold on to that distinction. SPF authenticates the envelope sender domain, not the header From. That single fact is the root of both SPF's usefulness and its biggest blind spot, and we will return to it when we get to alignment.

How an SPF check actually runs

Picture a message arriving at a receiving mail server. Here is the sequence SPF triggers, step by step.

1. The sending server connects and announces an envelope sender, for example bounce@mail.yourcompany.com.
2. The receiver extracts the domain from that address: mail.yourcompany.com.
3. The receiver looks up the SPF record, a TXT record in DNS, for that domain.
4. The receiver reads the mechanisms in the record from left to right, expanding any that point to IP ranges or other domains, and checks whether the IP address that actually connected is authorised.
5. The first mechanism that matches the connecting IP decides the result, and its qualifier (pass, fail, soft fail, or neutral) is returned.

The whole thing happens in a fraction of a second, before the message body is even fully transferred. You can watch this evaluation play out against any domain with the free SPF checker, which expands the record exactly the way a receiver would and shows you which IP ranges it resolves to.

The result of that check is one of a small set of outcomes: pass, fail, softfail, neutral, none (no record published), permerror (the record is broken or too expensive to evaluate), or temperror (a temporary DNS problem). What the receiver does with each result is up to its own policy, which is an important point we will come back to.

Anatomy of an SPF record

An SPF record is a single DNS TXT record on the domain itself. It always starts with the version tag v=spf1 and is followed by a series of mechanisms and an all term at the end. A typical record for a business using Google Workspace and an email service provider looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Read left to right, that says: mail is authorised if it comes from the ranges that Google publishes, or the ranges that SendGrid publishes, and everything else should fail (-all). Let us pull each piece apart.

The mechanisms

Mechanisms are the building blocks that match a connecting IP address. These are the ones you will actually use.

• include: pulls in another domain's SPF record and treats its authorised senders as authorised for you too. include:_spf.google.com is how you say "trust whatever Google says its sending servers are". This is the workhorse of modern SPF, because most of your mail is sent by third parties (Google, Microsoft, Mailchimp, Zendesk, and so on) who maintain their own published ranges.
• a authorises the IP address found in the domain's A or AAAA record. a:mail.yourcompany.com means "the server that this hostname points to is allowed to send".
• mx authorises the servers listed in your domain's MX records. The logic is that the machines that receive your mail often also send it, so mx is a convenient shorthand.
• ip4: and ip6: authorise a specific address or range directly, for example ip4:203.0.113.0/24. Use these for your own fixed-IP servers.
• exists: and ptr: are advanced and rarely needed. ptr in particular is discouraged because it is slow and unreliable, and many receivers ignore it.

Mechanisms are evaluated in order, and the first match wins. If the connecting IP is authorised by the second include, evaluation stops there and returns a pass; later mechanisms are never reached. This ordering matters when you reason about why a particular sender passed or failed.

The qualifiers, and the all term

Every mechanism can carry a qualifier prefix that decides what a match means. There are four.

• + means pass. This is the default, so +include: and include: are identical, and you almost never write the + explicitly.
• - means fail (a hard fail). The receiver is being told this source is not authorised, full stop.
• ~ means soft fail. The source is probably not authorised, but the receiver is asked to accept the mail and mark it rather than reject it outright.
• ? means neutral. No assertion is made either way.

These qualifiers come into their own on the final term, all, which is a catch-all mechanism that matches every IP that did not match anything earlier. The qualifier you put on all therefore defines your policy for unknown senders.

• -all (hard fail) is the strong, correct setting for most domains. It says "if a server is not on my list, it is not authorised, treat it as a failure". This is what you should be aiming for.
• ~all (soft fail) is the cautious setting. It says "if a server is not on my list, it is probably not me, but please do not reject the message". Many organisations start here while they are still discovering their legitimate senders.
• ?all and +all are mistakes in nearly all cases. +all literally authorises the entire internet to send as your domain, which is the opposite of what SPF is for.

A subtle and important point: the qualifier on all is a recommendation to the receiver, not a command. SPF on its own does not let you mandate that failing mail be rejected. A receiver is free to deliver a -all failure to the inbox anyway. This is one of several reasons SPF alone is not enough, and it is precisely the gap that a DMARC policy fills, because DMARC does let you publish an enforceable instruction.

What SPF authorises, and what it does not

It is worth being blunt about the boundaries of SPF, because misunderstanding them is the source of most authentication failures and most false confidence.

SPF authorises a sending server, identified by IP, against the envelope sender domain. That is the whole of what it does. It is a check on "is this machine allowed to send for this domain", and nothing more.

From that, three consequences follow that surprise people.

First, SPF says nothing about the header From address your recipient sees. A spammer can pass SPF perfectly on a domain they own, bounce@spammer-domain.com, while putting From: billing@yourcompany.com in the visible header. SPF checked the envelope domain, was satisfied, and never looked at the part the human reads. The message displays your brand and still earns an SPF pass. On its own, SPF does nothing to stop this.

Second, SPF does not check the message content. It does not sign or verify the body or the headers. A message can be modified in transit and still pass SPF, because SPF only ever looked at the connecting IP. Content integrity is the job of DKIM, the cryptographic signature mechanism, which you can read about in what is DMARC and how does it work and verify with the DKIM checker.

Third, SPF breaks on forwarding. When someone forwards your mail, or a mailing list relays it, the message reaches the final receiver from the forwarder's IP, not yours. That IP is not on your SPF list, so SPF fails, even though the mail is entirely legitimate. This is not a bug you can fix in your record; it is inherent to how SPF works, and it is the main reason DKIM exists alongside it.

The ten-lookup limit, the rule that catches everyone

There is one operational limit in SPF that causes more real-world breakage than any other, so it deserves its own section.

To stop SPF evaluation from becoming a denial-of-service vector, the specification caps the number of DNS lookups a single evaluation may perform at ten. Every include, a, mx, ptr, and exists mechanism costs at least one lookup, and an include that itself contains more includes costs all of theirs too. The count is recursive.

If your record exceeds ten lookups, the result is not a soft failure; it is permerror, a permanent error. And crucially, a permerror is treated by most receivers as an SPF failure. So a record that has simply grown too large, perhaps because you added a few SaaS tools that each contribute several nested includes, can silently start failing for legitimate mail.

This is easy to hit. A single record with Google Workspace, an email marketing platform, a helpdesk, and a billing provider can blow through ten lookups without anything looking obviously wrong. The fix is SPF flattening, which replaces expensive nested includes with the resolved IP ranges directly, keeping you under the limit. We explain the mechanics in how SPF flattening works, and our SPF product keeps a flattened record automatically maintained and updated as your providers change their ranges, so it never drifts back over the limit. The SPF checker will tell you your current lookup count so you know how close to the edge you are.

The gap SPF leaves, and how DMARC alignment closes it

We now have everything we need to state the central problem clearly.

SPF can return a perfectly valid pass for a message that is spoofing your brand, because the pass applies to the envelope sender domain while the fraud lives in the header From. The two domains are checked, or not checked, independently. SPF on its own has no concept of requiring them to relate to each other.

DMARC introduces that missing requirement, and it is called alignment. DMARC sits on top of SPF and DKIM and adds one decisive rule: for a message to pass DMARC, it must pass SPF or DKIM and the domain that passed must align with the domain in the header From, the one your recipient actually sees.

For SPF specifically, alignment means the envelope sender domain must match the header From domain.

• In strict alignment, the two domains must be identical.
• In relaxed alignment, the default, they must share the same organisational domain, so mail.yourcompany.com aligns with yourcompany.com.

Now reconsider the spammer. They send from bounce@spammer-domain.com with From: billing@yourcompany.com. SPF still passes for spammer-domain.com. But that domain does not align with the header From domain yourcompany.com. So SPF alignment fails, and therefore DMARC fails. The receiver, acting on your published DMARC policy, can now quarantine or reject the message. The exact-domain spoof that SPF waved through is finally stopped, not by SPF, but by SPF plus alignment under DMARC.

This is why you should think of SPF as a necessary building block rather than a complete defence. SPF tells the world which servers send your mail. DMARC takes that signal, insists it line up with the visible sender, and turns it into something a receiver can enforce. We go deep on this relationship in DMARC alignment explained, and the wider picture in what is DMARC and how does it work.

Building and checking a correct SPF record

Putting the theory into practice, here is the sensible way to get SPF right.

1. Inventory every legitimate sender. List every service that sends mail as your domain: your mailbox provider, marketing platform, CRM, helpdesk, billing system, transactional email service, and any on-premises servers. Mail you forget about is mail that will fail once you enforce.
2. Translate each into the correct mechanism. Use the include value your provider documents, an ip4/ip6 for your own fixed servers, and mx only if your inbound servers genuinely send outbound too. Our SPF generator assembles a valid record from your senders.
3. Mind the lookup count. Keep the total includes and lookups under ten. If you are close, flatten rather than keep adding nested includes.
4. Choose your all qualifier deliberately. Start at ~all if you are not yet certain you have found every sender, then move to -all once monitoring confirms your list is complete. The goal is -all.
5. Publish one record only. A domain must have exactly one SPF TXT record. Two SPF records is a configuration error that produces permerror. If different teams each added one, merge them.
6. Verify against reality. Run the SPF checker to confirm the record parses, resolves, stays under ten lookups, and ends in the qualifier you intended.

Once SPF is solid, the natural next step is to add DKIM, publish a DMARC record, and use the reports DMARC sends back to confirm that every legitimate sender is both passing and aligned before you tighten enforcement. That progression, from monitoring to a safe p=reject, is exactly what our monitoring keeps an eye on, and what the done-for-you service in our products handles end to end without an email outage.

The practical takeaway

SPF is the layer that lets you publish, in public DNS, the list of servers allowed to send for your domain, and lets any receiver verify a connection against it. The mechanisms (include, a, mx, ip4, ip6) name your senders, and the qualifier on the final all term sets your stance on everyone else, with -all as the goal. But SPF checks the envelope sender, an address your recipient never sees, it breaks on forwarding, and it caps out at ten DNS lookups. Most importantly, a valid SPF pass does not, by itself, stop someone spoofing your visible From address. That gap is closed by DMARC alignment, which requires the SPF-passing domain to line up with the header From before a message is trusted.

If you want to see exactly how your domain's SPF record evaluates right now, including its lookup count and its all qualifier, run it through the free SPF checker. And if keeping a correct, flattened, never-over-the-limit SPF record maintained for you sounds better than doing it by hand, that is precisely what the SPF product is for.