Disable Your Email Security to Help Email Deliverability? The Problems of SPF Neutral ?all

Why Are Emails Insecure by Default?

Emails are inherently insecure by default, with the email protocol established in 1981, nine years before HTTP, which we use to browse the World Wide Web. Every domain (e.g., stellastra.com, microsoft.com, amazon.com, or one of the more than 260 million registered domain names) has several attached textual records indicating the actual IP address of a computer to your laptop, phone, etc. These records serve various purposes, including email destination and email authentication (SPF, DKIM, and DMARC). By default, domains do not have these records. However, your DNS host may set them up for you, or you may use an automatic email/DNS zone integration when setting up your email account. It’s important to note that all domains must have DNS records set to function properly.

How Many Types of SPF Are There?

There are four types of SPF records, denoted by the final bit of text in the record. These are ranked from most to least secure: -all, ~all, ?all, and +all. All domains should ideally use “-all”, although “~all” is also acceptable. Both of these are referred to as “fail” modifiers, meaning that if the sending IP does not match, the result should be either a hard SPF authentication fail (-all) or a soft SPF authentication fail (~all). Over 90% of cybersecurity companies employ either an SPF hard fail or an SPF soft fail as of May 2024. One type should only be used for testing purposes or as a temporary measure: the “neutral” modifier, denoted by “?all”.

Is SPF Neutral ?all Used?

To explore the usage of the neutral modifier, Stellastra analyzed over 800 email marketing, billing, invoicing, and other transactional/direct and mass-marketing software applications to compile a list of recommendations and best practices. Additionally, it scanned the internet for one million randomly sampled domain names to understand where neutral SPF risk originated. When adding a new service, you must add an SPF and/or DKIM record to permit the sending service to use your domain. While many articles recommended adding SPF hard fails or SPF soft fails, several recommended “?all”. Fortunately, we did not find any articles explicitly recommending “+all”, the insecure ‘allow all’.

Among the articles recommending ?all, some did so without mentioning other modifiers, such as -all or ~all. Others at least acknowledged their existence, indicating that ?all should only be temporary, allowing for future change control. Interestingly, there was often a discrepancy between what a company recommended to new customers compared to what they did with their own SPF record. For example, the larger provider, gandi.net, recommends “?all” to new clients, but their own SPF is set to “-all”. Our study showed several thousand domains using gandi.net with the ?all modifier, representing 95% of all observed instances. Extrapolated to all domains, this suggests hundreds of thousands of domains authorizing gandi.net to send email with a neutral SPF record. Another email provider, lcn.com, recommends setting SPF to ?all, yet in another article, they acknowledge that while they recommend a neutral SPF policy at the onset, they advise switching to -all if you’re getting spoofed (i.e., malicious actors using your domain name without your approval). According to our study, 72% of such records including lcn.com had a neutral authorization, while lcn.com has set their own policy to -all.

By default, the SPF policy for domains hosted with LCN is set to neutral.

lcn.com

You can change the SPF policy for your domain to a strict policy... This is applied by changing the flag at the end of the record to: -all.

lcn.com

These high percentages of the neutral ?all modifier are significant, especially when compared to policies authorizing other senders, such as Google.com (4.38%), Shopify.com (0.6%), Mimecast.com (0.5%), Outlook.com (0.23%), Zoho.com (0.44%), Cloudflare.net (0.07%), PPhosted (0.2%), and PPE-hosted (0.006%). For example, an SPF record of “v=spf1 include:spf.protection.outlook.com include:spf.example.com ?all” would increase the percentages of ?all found for outlook.com and example.com.

Why Use SPF Neutral ?all?

Using an SPF record with Neutral ?all might be considered in specific email domain configurations, particularly during transitional phases or when performing detailed monitoring and debugging. The Neutral ?all mechanism in an SPF (Sender Policy Framework) record indicates that a mail server receiving an email should neither explicitly accept nor reject messages based solely on the SPF check. Instead, the result is neutral, providing no definitive guidance. It is also often used when a company’s budget is tight, and they cannot hire an email deliverability specialist to build an email sending inventory.

Reasons to Use Neutral ?all

• Gradual Implementation: It can be used when you’re in the process of gradually implementing or updating SPF policies. This allows time to observe how well your email passes SPF checks without risking immediate delivery issues.
• Avoid Hard Failures: Employing Neutral ?all helps to avoid potential hard failures (like bounces) while still logging SPF check results. This is particularly useful if IP addresses or sending servers have not yet been fully validated and confirmed.
• Testing and Monitoring: During the testing phase of SPF deployment, setting ?all helps monitor sender IPs that are legitimate vs. rogue without negatively affecting email deliverability.
• Feedback and Adjustment: It provides a basis for receiving feedback on which servers are sending emails and tweaking your SPF records accordingly before shifting to a more stringent policy.

While Neutral ?all has its place, it is generally seen as a temporary or transitional configuration. Long-term use might not significantly enhance email security, but it does prepare the groundwork for a stricter enforcement policy like ~all (SoftFail) or -all (Fail) once testing and validation are complete.

The Issues with Using SPF Neutral ?all

Neutral SPF records do not clarify whether a sender is authorized, and they are not supposed to count as a pass for the purposes of DMARC. Although they sometimes may, software developers, email inboxes, and companies are slowly tightening up SPF, DKIM, and DMARC requirements.

A 'neutral' result MUST be treated exactly like the 'none' result

RFC 7208

Consequently, those with neutral SPF records should begin by creating an email sender inventory. Once created, it’s simple to migrate the record to a more authoritative soft-fail, ~all, followed by an SPF (hard) fail of “-all”.

The Future of SPF Authentication

Google and Yahoo’s February 2024 DMARC requirements make it clear that DMARC is now a (requirement for bulk senders)[https://support.google.com/a/answer/81126]. Although a restrictive policy is not yet required, it seems likely that p=quarantine and p=reject will be mandatory in the near future. Senders should consider building an email sender inventory now to begin the migration towards the more secure policy of SPF hard failures (-all) to maintain high email deliverability and keep up with evolving authentication requirements. Ensuring a high delivery rate for day-to-day and marketing emails also involves controlling who can and cannot use their domain name.

Study Information

For the purposes of the study, one million domain names were chosen at random. Approximately 64% did not have an SPF record, while a further 4.8% had correctly written no-send SPF records (v=spf1 -all), indicating that no email is to be accepted via SPF authentication for that domain. This is common with sister domains, such as stellastra.co.uk, which uses such a record as all emails are sent from stellastra.com. It is not enough to simply avoid using stellastra.co.uk; there needs to be a definitive record within the SPF zone stating it should not be used. Redirects and nested domains were ignored for this study, as were those with syntax errors. Only records starting with v=spf1 and ending with one of the four types of all were included. Note that this data is not representative of the number of companies that do not have an SPF record. For example, as of May 2024, only 7.6% of cybersecurity companies did not have an SPF record.

DMARC Implementation Notes

This varies based on the email inbox implementation. It can be set at various levels by software developers, companies, or individual admins on a tenant-by-tenant or organization-wide basis. There is generally a slow tightening of email policy globally, and companies should aim for better-than-average SPF, DKIM, and DMARC policies to stay on top of requirements.