Email did not always include guardrails. In the early 2000s, inbox providers needed a practical way to verify where email actually came from. Spoofing was cheap, easy, and effective. Sender Policy Framework(SPF), emerged around 2003 to solve one narrow but important problem: confirming which mail servers may send email for a domain.

SPF lives in DNS, not inside your email platform. It publishes a list of approved sending sources for a domain. Receiving servers check that list when mail arrives. If the sending server appears, SPF passes. If it does not, SPF fails. That simplicity explains why SPF still matters today, and why it breaks so easily.

SPF checks the return path, often called the envelope-from address. It does not protect the visible From address that subscribers see. It does not encrypt messages. It does not block phishing by itself. Think of SPF as a guest list at the door. It confirms who may enter, not how they behave once inside.

Here is a simple SPF example:

v=spf1 include:_spf.examplesp.com ip4:203.0.113.10 -all

This record allows one sending service (via an include:) and one IP address, everything else should be noted as a fail.

Understanding ~all vs -all

Every SPF record ends with an all mechanism. This setting tells mailbox providers how to treat unlisted senders.

A record ending with ~all, called a soft fail, signals uncertainty. It says the sender likely should not be sending, but do not reject outright. Providers often accept these messages but treat them cautiously. Teams commonly use ~all during migrations or early setup.

A record ending with -all, called a hard fail, sets a firm boundary. It tells receivers to reject mail from any unapproved source. Once all legitimate senders appear in the record, -all offers stronger brand protection.

Avoid +all and ?all. +all allows anyone to send mail using your domain, which enables authenticated impersonation. ?all returns a neutral result and provides no protection value. Both options undermine SPF and should never appear on production domains.

Common SPF Points of Failure

Typos cause real damage. A misspelled include may still resolve, but point somewhere unintended. That mistake can authorize a sender you never approved. This scenario often appears in SPF include hijacking, where overly permissive records allow impersonation that technically passes authentication.

DNS lookups create another hidden risk. SPF limits evaluations to ten lookups. Each include, redirect, or nested reference counts. Exceed the limit, and SPF fails completely. Many teams only discover this after delivery drops. Some respond by flattening SPF records into IP lists. Flattening reduces lookups but increases maintenance risk. Better subdomain usage usually solves the problem cleanly.

Multiple SPF records break evaluation entirely. Domains may publish only one SPF record. Adding another does not merge them, this also means each subdomain will also need a record of it’s own. Receivers may treat this as an error and fail SPF, or use the first record found leading to unexpected results. Records published on the wrong domain cause similar confusion. SPF belongs on the domain used in the return path, not wherever feels convenient.

Keeping SPF Healthy Over Time

Like all things in life, SPF needs maintenance from time to time. Treat it like infrastructure, not a one-time task.

Review records annually. Confirm every listed service still sends mail. Remove platforms tied to old campaigns, pilots, or agencies. Prune unnecessary includes. Each one increases risk. DMARC reporting can help you identify which services are still necessary, and which are no longer sending on your behalf.

Check provider alignment. Ask whether a vendor even needs SPF authorization. Some services send from shared domains and never touch yours. Listing them adds exposure without benefit.

Document ownership. Someone must remain accountable for SPF changes. Without ownership, small mistakes quietly turn into deliverability and trust problems. Even Experts can make mistakes which is another reason to regularly review your configuration.

SPF still matters, but it’s fragile. It protects brands that keep it simple and current. It fails brands that ignore it for years. When marketers take responsibility for DNS, inbox placement improves quietly. When no one owns it, mistakes authenticate just as easily as legitimate mail.

When was the last time you actually read your SPF record?