SPF Authentication: SPF-all vs ~all
What is SPF? Sender Policy Framework (SPF) lets the admin specify what IP addresses are allowed to send emails on a domain’s behalf. This authorization is published as a TXT record in the DNS Provider (Cloudflare, GoDaddy, etc.). Note that SPF checks against the 5321.MailFrom address (also known as Return-Path, Envelope From, or Bounce address) to authorize sending IP addresses. The recipient’s mail server, if it adheres to the sender’s domain’s SPF policy, should act in accordance with the published SPF policy. In this article, we’ll discuss why you should use SPF -all vs ~all?
SPF Record: what does it look like?
SPF TXT record starts with the SPF version indicator followed by all the ‘whitelisted’ IP addresses that are authorized to send emails on a domain’s behalf, ending with an all tag (-all, ~all, +all, ?all) indicating what policy should be applied to email when MBPs (Mailbox Providers like Google, Microsoft, Yahoo!, etc.) detect that mail was sent from servers / IP addresses not listed in the SPF record. Also, check our free SPF Record check tool.
SPF Record Example:
v=spf1 ip4:172.16.254.1 ip4:188.8.131.52/24 ip6:2001:db8:0:1234:0:567:8:1 include:_spf.google.com -all
- v=spf1: SPF record should always start with v=spf1 version number.
- ip4 and ip6 mechanisms: Lists the single IP address (e.g 172.16.254.1 and 2001:db8:0:1234:0:567:8:1) or IP subnets (e.g. ip4:184.108.40.206/24) that are authorized to send emails on a domain’s behalf. Note that IPv4 addresses should be prefixed as “ip4”, and IPv6 as “ip6” tags.
- “include” mechanism: Used to authorize third-party services that are used to send emails on your domain’s behalf. In this example, the “_spf.google.com” authorizes Google Workspace (formerly G Suite) to send emails on behalf of your domain.
- “all” mechanism: In this example, the “-all” (Fail) tag is used. Tags include:
- -all (Fail): email from servers / IP addresses, not listed in the SPF record, should be rejected.
- ~all (SoftFail): emails from servers / IP addresses, not listed in the SPF record, should be accepted but marked
- +all (Pass): any servers can send emails on your domain’s behalf. We highly recommend not to use this option.
- ?all (Neutral): Interpreted as None / No policy. We highly recommend not to use this option.
For generating an SPF Record, check our SPF Generator tool.
Also, read our ultimate guide about SPF to improve email delivery.
SPF -all vs ~all: what should I use?
Before DMARC adoption (in 2012), SPF alone (which was introduced in 2004) played a major role, despite its limitations, in fighting against Return-Path or MailFrom email spoofing attempts. MBPs applied rules based on the admins’ expressed SPF record policies (~all or -all). Thus, this caused major issues with blocking legitimate emails due to SPF configuration errors, which led the majority and well-known MBPs to use both SoftFail (~all) and Fail (-all) as accept but mark method.
We at EasyDMARC advise our users to publish SPF records with SoftFail (~all) for 3 main reasons:
- Since DMARC adoption, MBPs use domains’ DMARC policies (p=quarantine or p=reject) to apply rules on the failed emails. SPF ~all is the same as -all, stating “Not Passed” or “SPF Fail”
- Using SPF ~all can make the debugging process of DMARC Aggregate reports easier (Identifying Return-Path addresses)
- Once in a while, you may come across some not-well-known MBPs who still treat SPF “Fail” and “SoftFail” as it was originally intended and produce various false-positive results with bouncing legitimate emails. Thus this can be avoided with ~all.
Optimizing SPF records can be pretty challenging. Also, check our guide.
Also, check our SPF Raw Checker to validate your SPF Record prior to implementing it in your DNS.