What Is SPF (and Why Your Email Goes to Spam)?

Acutis · plain-English network help · updated June 2026

What is SPF, in plain English?

SPF stands for Sender Policy Framework. In one sentence: it is a public list of the servers that are allowed to send email on behalf of your domain. When a message claiming to be from you@example.com arrives, the receiving server looks up your SPF record and asks a simple question — "did this message actually come from a server you authorized?" If the answer is no, the message is treated as suspicious, and that often means the spam folder.

SPF exists because the email system was built on trust. By default, anyone can put your address in the "From" field, the same way anyone can write a fake return address on an envelope. SPF is your way of publishing, for the whole internet to see, exactly which post offices are allowed to send mail in your name.

The v=spf1 TXT record

An SPF record is just a single line of text published in your domain's DNS as a TXT record. It always begins with v=spf1, which marks it as a version-1 SPF policy. A simple one looks like this:

v=spf1 include:_spf.google.com ~all

Reading left to right: the record says "this is an SPF policy; the servers listed by Google are allowed to send for us; treat anything else with suspicion." Every part after v=spf1 is a mechanism that either lists allowed senders or sets the final rule. A few you will see often:

• include: — pulls in another domain's allowed senders, used for services like Google, Microsoft, or a mailing platform.
• ip4: and ip6: — authorize a specific server address directly.
• a and mx — authorize the servers named in your A or MX records.
• all — the catch-all at the end that decides what happens to everyone not listed.

Includes: borrowing other senders' permission

Most people never send email directly from their own server. They use Google Workspace, Microsoft 365, a newsletter tool, or a help-desk platform. Each of those sends from its own large pool of servers, and those addresses change over time. The include: mechanism solves this neatly: instead of listing every server yourself, you point at the provider's own SPF record and inherit their list.

So a business that uses Google for mail and a separate tool for marketing might publish: v=spf1 include:_spf.google.com include:sendgrid.net ~all. One important limit: SPF allows a maximum of ten DNS lookups, and each include counts toward it. Stacking too many services can break the record entirely — a common, silent cause of delivery problems.

~all vs -all: the rule at the end

The very end of the record is the most important part, because it tells receivers what to do with mail that is not on your list. There are two common choices:

• ~all (soft fail). "Anything not listed is probably not us — mark it as suspicious, but still accept it." This is the safer setting while you are getting your records right, because legitimate mail you forgot to list won't be hard-blocked.
• -all (hard fail). "Anything not listed is definitely not us — reject it." This is the strongest stance against spoofing, but only adopt it once you are certain every legitimate sender is included, or you will block your own mail.

A third option, +all, authorizes everyone and is effectively useless — never use it. The usual journey is to start at ~all, confirm everything works, then tighten to -all.

How missing or broken SPF sends you to spam

This is the part that bites real businesses. When SPF is wrong, three things tend to happen:

• Spam-foldering. If you have no SPF record at all, modern providers like Gmail and Outlook trust you less, and your legitimate mail is far more likely to be filed as spam or rejected outright.
• A broken record is worse than none. A typo, two SPF records on one domain (only one is allowed), or blowing past the ten-lookup limit can cause an SPF "permerror," and receivers may treat that as a failure.
• Spoofing through the gap. With no policy, scammers can send mail that looks exactly like it came from your domain — to your customers, your staff, anyone. SPF is the first line that shuts that door.

The fix is almost always to publish one clean, correct SPF record that lists every service you actually send from, ending in ~all or -all.

SPF is one of three records, not the whole story

SPF proves a message came from an authorized server, but it has a blind spot: it can break when mail is forwarded, and on its own it does not protect the visible "From" address users actually see. That is why SPF works best alongside DKIM (which cryptographically signs the message) and DMARC (which ties the two together and tells receivers how to act). Get all three right and your mail stops landing in spam — and nobody can convincingly forge your domain.