How to Set Up SPF

Sender Policy Framework, commonly called SPF, is a foundational email authentication standard. It tells receiving mail servers which systems may send email for your domain. When SPF is missing or incorrect, mailbox providers are forced to guess. Guessing rarely works in your favour.

SPF works by publishing a DNS record. That record lists approved sending sources, such as IP addresses or third-party services. When an email arrives, the sending IP is checked against that list. If it matches, SPF passes. If it does not, trust drops immediately.

A useful way to think about SPF is a guest list. If the sender is not listed, they should be treated with suspicion.

Remember in 2024 Google and Yahoo announced that proper authentication SPF, DKIM, and DMARC are all required for sending mail to their networks, since then many other Mailbox Providers have updated their guidelines to reflect similar requirements. 

Where to Start With SPF

Start by identifying every service that sends email for your brand. This usually includes your ESP, marketing tools, CRM platforms, and support systems. Each provider should publish SPF instructions. Always follow those instructions rather than copying examples from other domains.

Next, decide which domains or subdomains send each mail stream. Marketing, transactional, and operational email often benefit from separate subdomains. This keeps records simpler and reduces risk when changes are needed.

Once senders are known, create a single SPF record per domain or subdomain. Add the required include mechanisms and any dedicated IP addresses – either ip4, or ip6 can be published. Publish the record in your DNS, then test it carefully.

An Example SPF Record, Explained

Here is a simple but realistic SPF record:

     v=spf1 ip4:192.0.2.10 ip6:2001:db8:abcd:0012::1 
     include:send.exampleesp.com ~all

Each part serves a clear purpose.

v=spf1 declares the record type and version. Every SPF record must start this way.

ip4:192.0.2.10 authorises a specific IPv4 address. This is common for dedicated servers or internal mail systems.

ip6:2001:db8:abcd:0012::1 does the same as ip4, but for ip6 networks. 

include:send.exampleesp.com allows a third-party service to send on your behalf. The receiving server evaluates that provider’s SPF record as part of yours.

~all defines how to treat unauthorised senders. A soft fail signals that the sender is likely not permitted, but the message may still be accepted with reduced trust.

You may also see -all used instead. A hard fail explicitly states that mail failing SPF is unauthorised. This is appropriate only when you are confident every legitimate sender is accounted for. Many teams start with ~all and move to -all after monitoring and cleanup.

SPF is evaluated from left to right and stops once a definitive result is reached. Keep records intentional and readable.

Common SPF Pitfalls to Avoid

SPF can be broken in many ways, a few of the most common can be found here: 

• Typos remain one of the most common SPF failures. A small spelling error in an include domain can unintentionally authorise the wrong infrastructure. This can lead to SPF hijacking, where unauthorised mail still authenticates. The fix is simple: copy domains directly from provider documentation and validate after every change.
• Multiple SPF records cause immediate failure or confusion for authentication services. Each domain or subdomain may have only one SPF record. If duplicates exist, merge them into a single record without delay or you may experience inconsistent results with authentication.
• The ten DNS lookup limit regularly causes problems. Looping includes waste lookups and push records over the limit. Remove redundant or circular includes as soon as they are identified.
• Too many included sending services create similar issues. Old vendors often remain listed long after they stop sending. Remove unused includes and move secondary services onto dedicated subdomains.
• Using ?all or +all is also risky. These options tell receiving servers to treat all senders as acceptable or neutral. That effectively disables SPF protection and provides no meaningful signal to mailbox providers.
• Missing policy, an SPF record missing an all mechanism does not explicitly state a policy, so receiving servers may treat the result as neutral, which weakens the authentication signal and reduces its effectiveness.

These issues are common enough and easily fixed with a quick review of active services and typo review. 

When SPF Might Not Be Required

Some ESPs control the envelope sender address for their customers. In those cases, the provider’s domain handles SPF evaluation instead of yours. That means SPF may not be required on your domain for that specific mail stream.

This does not remove the need to understand SPF. It simply shifts responsibility to the Email provider to ensure accuracy. You might notice this in your DMARC reports where SPF is reported as one of your vendors instead of your organization’s domain.

SPF can also fail when email is forwarded, because the forwarding server sends the message from its own IP, not the original authorised sender, which makes it important to understand when forwarding occurs and how it may affect delivery. This is why it is paired with DKIM, when we consider alignment and pass or fail under DMARC. You might see authenticated mail say that SPF fails, but DKIM passes, this is an expected behaviour for forwarded mail.

SPF is simple in theory but unforgiving in practice. Small mistakes quietly erode trust and deliverability over time. Regular reviews, clean records, and clear ownership make a measurable difference.

If you want help getting authentication fixed, validated, and future-proofed, we can help. Want to review your SPF before it turns into a delivery problem?