SPF: how a domain says who's allowed to send its mail

Think of SPF (Sender Policy Framework) as a guest list your domain publishes for the entire internet to read: "these are the mail servers allowed to send email claiming to be from me." It lives as a small text record in DNS — the same system that turns a domain name into a website address — so any mailbox that receives a message from your domain can check the sending server against that list before deciding whether to trust it.

Without SPF, anyone can put your domain in the "From" field of an email and send it from their own server, and nothing technical stops them. SPF doesn't make that impossible, but it gives the receiving mailbox — Gmail, Outlook, Yahoo — a fast, checkable fact: was this message actually sent by a server this domain vouches for? A missing or weak SPF record is one of the most common reasons legitimate outreach ends up in spam.

An SPF record is a single line of text published as a TXT record on the domain itself (not a subdomain). It always starts with a fixed version tag, v=spf1 — this exact string, case-sensitive, is what tells anything checking it "the rest of this text record is an SPF policy, evaluate it as one." A TXT record on the domain that doesn't start with this literal string isn't SPF at all, no matter what else it contains — and a domain that publishes two separate v=spf1 records by mistake breaks the check entirely, since only one is allowed.

Every SPF record closes with a catch-all instruction, written as a qualifier symbol immediately before the word "all." That symbol is what actually determines how strict — or how toothless — the record is for any server not otherwise listed as approved.

SPF checks where a message technically came from, not who wrote it — so when an email gets forwarded through another mailbox before reaching its final destination, the original SPF check can break, because the message is now arriving from the forwarding server, not the original sender. This is a known, structural limitation of SPF itself, not something any one domain's record can fix.

• Publishing two separate v=spf1 records by accident — only one is permitted per domain.
• Forgetting to add a newly adopted sending tool to the approved list, so its mail starts failing SPF the moment it goes live.
• Never tightening the final instruction from ~all to -all once every real sending source has actually been accounted for.

SPF alone won't get an email into the inbox, and a broken SPF record alone won't necessarily send it to spam either — mailbox providers weigh dozens of signals together. But it's one of the very first, cheapest checks a receiving server runs, and a domain that can't even pass this basic test gives every other spam filter a reason to be more suspicious about everything else that follows.