Is '-all' required in included SPF records if the main record has it?
Matthew Whittaker
Co-founder & CTO, Suped
Published 18 May 2025
Updated 15 Aug 2025
7 min read
The question of whether '-all' is required in included SPF records if the main record already has it is a common point of confusion for many organizations. It often arises when integrating third-party email service providers (ESPs) and configuring their recommended SPF includes into your domain's DNS.
This concern stems from a natural desire for completeness and robust security, as IT professionals might assume that every component of the SPF authentication chain needs its own definitive policy, including a final `all` mechanism. However, this isn't exactly how SPF evaluation works at a fundamental level.
Understanding the SPF evaluation process is key to clarifying why an explicit `-all` in an included record is not necessary and can even be redundant. The focus should always be on how the receiving server processes the primary SPF record, not on each sub-record being a standalone policy.
When an email server receives a message, it initiates an SPF check by looking up the sending domain's SPF record. This record always begins with `v=spf1` and contains a series of mechanisms, including `include`, which points to other SPF records hosted on different domains.
If your main SPF record contains an `include` mechanism, for instance, `include:service.com`, the receiving mail server will then query the SPF record for `service.com`. If that included record authorizes the sending IP address, meaning the IP is explicitly listed or covered by another mechanism within `service.com`'s SPF, then the `include` mechanism in your main record evaluates to a "pass". The SPF evaluation for your domain then stops, and the email passes SPF authentication. This is why properly configured included records are vital for email deliverability.
Crucially, if the included record *does not* authorize the sending IP address, the evaluation does not stop there. Instead, it "falls through" or "returns" to the main SPF record. The important point is that the `all` mechanism, like `-all` or `~all`, from the included record is not inherited or transferred back to the main record's evaluation. The main record's own `all` mechanism is what ultimately dictates the policy for unlisted senders at the top level, preventing your emails from being unexpectedly blocked or sent to a spam folder.
Evaluation with `include` success
IP match: If an email's sending IP matches an entry within the included SPF record, the `include` mechanism evaluates to a "pass" outcome.
Evaluation stops: The main SPF record's evaluation immediately stops at this point. No further mechanisms are checked.
Outcome: The email is considered SPF authenticated and proceeds to the next authentication check, such as DKIM and DMARC.
Evaluation with `include` non-match
No IP match: If an email's sending IP does not match any entry in the included SPF record, the `include` mechanism itself does *not* result in a pass.
Evaluation continues: The evaluation returns to the main SPF record and continues processing subsequent mechanisms.
Final policy: The main SPF record's `all` mechanism will ultimately dictate the policy for this email, not any `all` in the included record.
The specific role of the 'all' mechanism
The `all` mechanism, whether it's `-all` (hard fail) or `~all` (soft fail), acts as a definitive catch-all at the end of an SPF record. It specifies the policy for any IP addresses that haven't matched any of the preceding mechanisms within that specific SPF record. It serves as a final instruction to the receiving server for that particular record.
For your main domain's SPF record, the `all` mechanism is critically important. It defines the ultimate disposition of an email if no other mechanism in your record explicitly authorizes the sending IP. For example, a `-all` policy indicates that any email not explicitly authorized by your SPF record should be rejected by the recipient server, enhancing your domain's protection against spoofing. You can read more about the differences between SPF ~all versus -all.
Included SPF records, conversely, are merely lists of authorized sending sources for a particular service, like an email service provider (ESP). Their purpose is not to define a comprehensive policy for your domain, but rather to extend the authorization list of your main record. If an IP address isn't found within an included record, such as `esp.ip-blocks`, that specific `include` mechanism simply doesn't authorize it, and the SPF evaluation process continues to the next mechanism in your parent SPF record.
This means that the absence of an `all` mechanism in an included record is perfectly normal and expected. Its presence or absence within an included record does not alter the behavior of your primary SPF record's `all` mechanism. Your main record's `all` is the final arbiter for your domain's SPF policy, as highlighted in the RFC 7208 specification.
The non-cascading nature of `-all`
Local scope: The `all` mechanism, whether `-all` or `~all`, acts solely within the SPF record where it is explicitly defined.
No propagation: It is a final instruction for that specific record, not a global directive that propagates to other records via `include` mechanisms. This applies to Microsoft SPF records and any other third-party services.
Functional impact: Therefore, adding `-all` to an included record does not provide any additional security or functional benefit to the main domain's SPF policy. It's simply redundant.
Practical implications and common scenarios
The misconception that an `-all` is needed in included records often stems from a logical but incorrect assumption that every linked SPF record should be a complete, self-contained policy. However, as discussed, the SPF specification clarifies that the ultimate policy for a domain is solely determined by its *own* SPF record's `all` mechanism. The `include` mechanism simply allows for external authorization checks to be performed within the context of the main record.
Some email service providers might include an `all` mechanism in their SPF records, which are then included by their customers. This practice isn't inherently harmful, but it is redundant. Such inclusions might be for internal consistency or, as some experts suggest, to preemptively address customer support queries from IT teams who might mistakenly believe it's required. It adds a negligible amount to the DNS response size but has no functional impact on your domain's SPF policy.
Therefore, if your main SPF record already ends with a strict `-all` (hard fail) or a more lenient `~all` (soft fail) qualifier, the presence or absence of an `all` mechanism within an `include` record is irrelevant to your domain's overall SPF policy. Your primary SPF record controls the final outcome for unauthorized senders. This is a crucial distinction for proper email authentication setup and avoiding deliverability issues.
It is essential to ensure that your primary SPF record is well-formed and includes all legitimate sending sources. This includes your own servers and any third-party services you use for sending emails. Neglecting this can lead to legitimate emails being marked as spam or blocked, even if your `include` records are technically correct. Regularly checking your SPF record configuration is a key aspect of maintaining good domain reputation.
Always ensure your main SPF record has a clear `all` mechanism, like `-all` or `~all`.
Consolidate all legitimate sending sources into a single, comprehensive SPF record for your domain.
Verify that your SPF record adheres to the 10 DNS lookup limit to prevent `PermError` failures.
Common pitfalls
Believing that `all` mechanisms in included SPF records have an impact on your main domain's policy.
Exceeding the 10 DNS lookup limit by adding too many `include` mechanisms, leading to SPF failures.
Not updating your main SPF record when new sending services are adopted or old ones are retired.
Expert tips
Use DMARC to monitor SPF authentication results and gain visibility into email authentication issues.
Start with a `~all` policy (soft fail) on your main record while in a monitoring phase, especially if transitioning to DMARC.
Regularly review your SPF record to ensure it accurately reflects all authorized email sending sources and prevents blocklisting.
Marketer view
Marketer from Email Geeks says: The `-all` mechanism simply signifies that if the SPF evaluation reaches this point in the record, the email should be treated as a failure.
Feb 18, 2021 - Email Geeks
Marketer view
Marketer from Email Geeks says: When an SPF record includes another, if the included record passes, the main record also passes. If the included record fails or does not authorize, evaluation returns to the main SPF record after the include.
Feb 18, 2021 - Email Geeks
The bottom line on SPF includes
The core principle to remember is that the `all` mechanism's policy is local to the specific SPF record in which it appears. It does not cascade or transfer its directive to other SPF records, whether they are included or doing the including. Your main domain's SPF record stands as the authoritative source for your overall sending policy, and its `all` mechanism will be the final decision maker.
Therefore, the critical focus should be on ensuring your primary domain's SPF record is correctly configured with an appropriate `all` mechanism, such as `-all` for a strict reject policy, or `~all` if you are using DMARC in a monitoring phase. This proactive approach ensures robust email authentication and helps prevent your legitimate emails from being flagged as spam or spoofed, ultimately improving your email deliverability.
Microsoft SPF records and any other third-party services.
