Email Security

What is SPF (Sender Policy Framework)?

SPF is the record published in a domain's DNS that lists which servers are authorized to send email on its behalf. When a message arrives, the receiving server checks that list and learns whether it came from an authorized place or not. It is the domain's front desk, and the first of the three email authentication records. On its own, however, it is not enough: SPF checks the envelope address used in transport, not the sender the person reads on screen.

Zamak TechnologiesUpdated on August 6, 2026

How SPF works

SPF is a short conversation between the receiving server and the DNS of whoever claims to have sent the message. It happens in milliseconds, before the message is accepted.

The company publishes the list

A text record goes into the domain's DNS declaring which servers may send for it: corporate mail, the marketing platform, the system that issues invoices.

The receiving server reads the envelope

On receiving the message it extracts the domain from the envelope address, the one used in transport and in bounce handling.

It compares the sending address against the list

It queries the record published on that domain and checks whether the server delivering the message is among the authorized ones.

It applies the instruction at the end of the record

On a match, the message passes. With no match, what counts is what the domain owner wrote at the end of the list: a firm refusal or merely a weak flag.

Source: RFC 7208, the official SPF specification published by the IETF, which defines host authorization and the identity being verified, and N-able University's email DNS configuration material.

What SPF does not cover

It checks the envelope, not what you read. The specification itself warns that SPF-authorized email may contain other false identities. The sender displayed on screen can belong to a different domain, and SPF never looks at it.
It breaks when a message is forwarded. A forwarding server becomes the origin, and it is not on the original domain's list. Legitimate email fails the check without anyone doing anything wrong.
It has a query budget. The specification caps at ten the number of record terms that require a DNS lookup. Past the tenth lookup the check returns a permanent error and stops there: whoever sits at the end of the list stops being authorized, legitimate or not.
It does not tell the receiver what to do. SPF reports whether the origin was authorized; what turns that result into action on the visible sender is DMARC.

What changes at the end of the record

Firm refusal (-all) Written as a minus sign before all, it declares that anyone not on the list is not authorized, full stop. It is the only instruction that a good share of filters actually act upon.
Weak flag (~all) Written as a tilde before all, it says the message is probably not authorized but asks for nothing. Many filters simply log it and deliver anyway, which makes the domain look protected without being protected.
Neutral (?all) Written with a question mark, it explicitly states that the domain commits to no answer at all. The standard says to treat it exactly like the absence of a policy (RFC 7208, section 8.2).
Authorize everyone (+all) A plus sign before all authorizes any server on the planet to send for the domain. It shows up by accident in records copied from tutorials, and it is worse than having no SPF.

Why so many SPF records protect nothing

is the ceiling of record terms that require a DNS lookup; past that point the check returns a permanent error (permerror) and the sender stops being authorized (RFC 7208, section 4.6.4)

of the two sender addresses in a message is checked by SPF: the envelope one, used in transport, not the one shown to whoever reads it (RFC 7208)

-all

is the only ending that asks the receiver to act; on the weak version (~all) the standard says a message should not be rejected on that result alone (RFC 7208, section 8.5)

SPF is the oldest of the three records and the one that accumulates the most maintenance: every new service that starts sending on the company's behalf requires a change to it. That is where the two silent defects that explain most cases come in. The first is ending the list with the weak flag: the domain shows up with SPF published in any check, the internal report says the company is compliant, and the forged message still gets delivered, because the weak ending asks nothing of the receiver. Microsoft's documentation goes further: when the message carries no signature either, the DMARC policy ends up ignored on weak-ending failures. That is why the official recommendation is to close with a firm refusal. The second is blowing the query budget: every third-party service added to the record consumes part of the limit of ten, and a company that has accumulated corporate mail, a marketing platform, an invoicing system and a support tool crosses the ceiling without noticing. When that happens the check starts returning a permanent error for the senders sitting at the end of the list, and the domain ends up worse off than before it published the record: on top of not stopping the forgery, it starts taking down part of the company's own legitimate email. In both cases the record exists and does not protect, which is the worst of the situations: the company believes it is covered and it is not. And the second defect charges its price on the other side too: the invoice that never lands, the proposal that vanishes, the campaign that bounces. That cost never shows up on an invoice, it shows up as the customer calling to ask why nothing arrived.

How to publish an SPF record that actually counts

A well-built SPF record is short, single and closed. Getting there takes five steps:

Inventory every sender firstList everything that sends using the domain, including whatever was bought outside IT: the email marketing tool, the invoicing system, the website form, the document signing service. Whatever is left out will land in spam the moment the list is closed.
Publish one single record per domainTwo SPF records on the same domain invalidate the check. If there are several services, they all go into the same record, never into separate ones.
Stay under the ten-lookup ceiling (past it the record returns permerror)Count the terms that require a DNS lookup and keep headroom. If it has overflowed, remove services that no longer send or consolidate the includes, rather than living with a permanent error.
End with a firm refusal once the inventory is closedThe weak ending is a transition stage, not a destination. It exists for the period when you are still discovering who sends.
Publish on the subdomains that send tooA subdomain does not inherit the parent domain's SPF. Each sending subdomain needs its own record, and the ones that do not send benefit from a record that authorizes nobody.

In practice

There is an enormous difference between having SPF and being protected by SPF. A record that ends in the weak flag, or that blew the ten-query budget, shows up as present in every checking tool and stops not a single forged message. Checking the ending and the query count takes a minute, and it is what separates the decorative record from the record that acts.

How Zamak handles SPF

Zamak Technologies publishes SPF from the sender inventory, keeps a single record per domain within the query budget, and only closes the list with a firm refusal once measurement shows every legitimate send is passing, alongside whoever already administers the domain. The email spoofing check shows in seconds what your domain's record ends with today. Keeping those records current is part of Managed Email Security and of Managed Cybersecurity in the Zamak Method.

Frequently asked questions about SPF

Does SPF alone stop my domain from being spoofed?

No. SPF checks the envelope address used in transport, not the sender that appears on the recipient's screen. A criminal can publish a perfect SPF record for a domain of his own and still write your company's name in the field the victim reads. What ties the two together is DMARC.

SPF -all vs ~all: what is the difference between hard fail and soft fail?

The dash declares that anyone not on the list is not authorized, and that is the instruction filters act upon. The tilde only says the message is probably not authorized, and a good share of filters deliver it anyway. The practical recommendation is to use the tilde while you are still mapping who sends, and switch to the dash as soon as the inventory is closed.

What happens when SPF exceeds the 10 DNS lookup limit (permerror)?

The check returns a permanent error the moment evaluation goes past the tenth term. The effect is treacherous because it is partial: the record is read left to right and reading stops at the first server that matches, so whoever sits at the start of the list keeps passing and whoever sits at the end does not. One system delivers normally, another starts bouncing the message back saying the record required too many lookups, and nobody understands why only half the email vanished. It is one of the most common defects in companies that kept adding email services over the years.

Do I need SPF on domains that do not send email?

Yes, and it is one of the cheapest measures available. A parked domain, kept for a brand or a future campaign, is an easy target precisely because nobody looks at it. Publishing a record there that authorizes no server, together with a reject policy, closes that door for good.

My email stopped arriving after I changed SPF. Why?

Almost always because a legitimate sender was left off the list at the moment it was closed. The usual suspect is a system nobody remembered to map: the invoicing system, the campaign platform or the website form. That is exactly why the inventory comes before publication.