What Is SPF? Your Domain's Allowed-Senders List, Explained

Email lets any server claim to send for any domain. SPF was the first widely adopted fix: you publish a TXT record in your domain's DNS (the Domain Name System, the public directory that maps names to servers) listing every service authorized to send mail as you: your email provider, your newsletter tool, your invoicing system.

Receivers treat everything not on the list as suspect. If a server in a country you've never done business with sends mail claiming to be your domain, an SPF check fails, and that failure feeds into spam filtering and, when you have DMARC, your published policy.

Here is the detail most explanations skip: SPF does not check the From address you see in your mail client. It checks the envelope sender (also called the return-path or MAIL FROM address), which is a hidden address used during the server-to-server handshake, mainly for routing bounces.

The receiving server takes the domain from that envelope address, fetches its SPF record from DNS, and checks whether the connecting server's IP address matches one of the entries. The whole check happens before the message body is even transmitted.

This distinction matters because the envelope domain and the visible From domain are often different, especially with newsletter tools, which usually put their own bounce domain in the envelope. That gap is exactly what DMARC alignment exists to close.

An SPF record is a single line made of mechanisms (ways to match a sending server) and qualifiers (what to do on a match). The record is evaluated left to right, and the first mechanism that matches decides the result.

A typical record for a business on Google Workspace looks like this: one TXT record at the root of the domain. Read it as: mail from Google's servers passes; everything else is a soft fail.

SPF has a hard rule: evaluating a record may trigger at most 10 DNS lookups. Every include:, a, mx, and a few other mechanisms count, and includes nest, so a single include: for one vendor can quietly consume three or four lookups on its own.

Go over 10 and receivers return permerror, which many providers treat the same as a failure. This is the most common way a working SPF record silently breaks: someone adds one more marketing tool, the count crosses 10, and legitimate mail starts failing. If you accumulate services, count your lookups, or use monitoring that counts them for you.

First, forwarding breaks it. When someone auto-forwards your message (a personal Gmail rule, a university alumni address), the forwarding server becomes the new sender. That server isn't in your SPF record, so the check fails even though the message is completely legitimate. SPF verifies the last server that touched a message, not the original author.

Second, SPF checks the wrong address for anti-spoofing purposes. Because it validates the hidden envelope domain, an attacker can pass SPF for a domain they control while displaying yourcompany.com in the visible From line. DMARC fixes this by requiring alignment: the domain that passes SPF (or DKIM, its cryptographic sibling) must match the From domain the recipient sees. SPF is necessary, but it only becomes anti-spoofing protection when DMARC ties it to the visible sender.