Individual SPF Records findings are graded as GOOD, NEUTRAL, WARN or BAD. These evaluations contribute to the overall letter grade for the risk vector. Having SPF records for all domains (including SMTP servers and those that aren’t configured to send email) is best practice. An attacker can still use a domain to spoof email even if the company does not intend to send email from that particular domain.
Please note that if there are no domains to pull records from, no Findings will be generated and thus will be graded with an “F” as a default letter grade.
Messages are used to alert you to the severity of the SPF Domains finding. Learn more about how SPF Domains findings impact your grade below:
Bad Findings Messages
Multiple records returned for TXT query: Your domain has more than one SPF TXT record, which makes all SPF records invalid.
Need to fix this?
- Keep only one SPF TXT record for your domain.
- Remove any extra SPF TXT records.
- Make sure the remaining record is correctly formatted.
Multiple SPF records: Only one unique SPF record is allowed per domain. If more than one record exists, all records become invalid, resulting in the same level of security as not having a record at all.
Need to fix this?
- Only one SPF record is allowed per domain.
- Remove all extra SPF records, keeping just one.
- Make sure the remaining SPF record is correctly formatted.
SPF record has a recursion error: SPF's "include" and "redirect" features simplify domain management by allowing administrators to reuse existing SPF records.
Example: Example Company can either include the existing example.com SPF record for its new example.net domain, or redirect to it if the records are identical. A recursion error occurs when an include or redirect mechanism is improperly configured, creating a circular loop, such as example.net including example.com, and example.com simultaneously including example.net.
Need to fix this?
- Carefully review all "include" and "redirect" domains in your SPF record.
- Check if any included or redirected domain points back to your original domain, causing a loop.
- Update the SPF records to remove the circular reference.
No SPF record: This company has not configured an SPF record. Without an SPF record, anyone can send email appearing to be from this domain.
Need to fix this?
- Create an SPF record for your domain as a TXT record in your DNS. Click here for detailed instructions on how to create an SPF record.
Good to know:
- For domains that do not send email, use: "v=spf1 -all"
- For domains that send email, include authorized mail servers, e.g.: "v=spf1 a mx -all"
- Add the record via your DNS provider’s control panel.
- Verify the record using tools like dig yourdomain.com txt.
No SPF record for domain: This domain lacks an SPF record, and no email sending attempts have been detected. Without an SPF record, the domain is vulnerable to phishing attacks and spam, as anyone can spoof emails. All domains, even those not sending mail, require an SPF record.
Need to fix this?
- Add an SPF record to your DNS. Click here for detailed instructions on how to create an SPF record.
Good to know:
- For domains that do not send mail, use: "v=spf1 -all"
- For domains that send mail, use: "v=spf1 a mx -all"
No SPF record for include or redirect domain: An include mechanism or redirect modifier is specified in this record, but the domain or SPF record on the domain does not exist.
Need to fix this?
- Log in to your DNS provider’s control panel.
- Locate the DNS settings for the affected domain.
- Add a new TXT record with these details:
- Name/Host: your domain (e.g., example.com)
- Type: TXT
- Value: v=spf1 include:otherdomain.com -all
Example
v=spf1 include:otherdomain.com -all- Save the changes.
- Verify the SPF record using: dig yourdomain.com txt
SPF record is improperly formatted: This record has formatting errors that prevent it from being effective. Because an SPF record has to be precise to work, errors can range from simple typos to large syntactical issues.
Formatting requirements and tips:
- The record must start with v=spf1 (e.g., "v=spf1 ...").
- Only one “all” statement or “redirect” is allowed, and “all” should be at the end.
- Use correct mechanisms: a, mx, ip4, ip6, include, etc.
- Avoid typos, missing spaces, or punctuation errors.
- The record should be a TXT type in DNS.
Need to fix this?
- Check the formatting of your record. A common problem with SPF records is that they include typos.
Need more tips?
- See our guide on how to create an SPF record for formatting requirements and update your record accordingly.
- If your record contains mechanisms not covered by our guide, review the SPF specifications.
SPF record is ineffective: This SPF record is considered ineffective because it does not produce a clear enforcement outcome during evaluation. Common causes include use of a neutral "?all" mechanism, improper combination of the "redirect" modifier with an "all" mechanism, structural or syntax errors, or misconfiguration within an included third-party domain. A neutral "?all" does not enforce restrictions on unauthorized senders. When "redirect" is used, no "all" mechanism ("~all", "-all", or "?all") should appear in the same record because "redirect" replaces the entire evaluation logic. This restriction does not apply to "include" mechanisms, which may validly coexist with a single "all" mechanism at the end of the record. Ineffective SPF configurations may weaken spoofing protection and negatively impact the SPF Domains assessment.
Need to fix this? Ensure each domain has a single, correctly formatted SPF record that only authorizes necessary mail servers, including:
- Reviewing the SPF TXT record to ensure proper structure and enforcement logic: replace any "?all" mechanism with "~all" or "-all" based on your enforcement requirements.
- Ensuring exactly one valid all mechanism is present at the end of the record unless "redirect" is used, and if "redirect" is configured, remove any "all" mechanism from that same record.
- If the issue originates from a domain referenced via "include", verify the included domain’s SPF configuration or contact the third-party provider, as you may not be able to modify their record directly.
- After correction, the SPF policy should return a definitive pass for authorized senders and a fail for unauthorized senders, resulting in an effective and enforceable SPF configuration.
Too many DNS lookups: To prevent denial of service (DoS) attacks against receiving mail servers, the SPF record should not require the receiving mail server to conduct more than 10 DNS transactions during the evaluation of the record as outlined in RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. More than 10 DNS lookups results in an error, making the SPF record ineffective.
Need to fix this?
- Limit DNS lookups in your SPF record to 10 or fewer.
- Review and reduce the use of mechanisms like include, redirect, a, mx, ptr, and exists.
- Simplify your SPF record by removing unnecessary includes or consolidating them.
Warn Finding Messages
Effective but allows a large number of hosts: SPF records are designed to help receiving mail servers determine if an email sender is authorized to use an organization's domain. In order for an SPF record to effectively protect an organization's domain, it should be restricted to only the exact domains and IP addresses that will be sending email. When an administrator specifies a range of IP addresses larger than necessary, it increases the chance of a compromise. BitSight recognizes that organizations acting as email service providers need to allow many mail servers to process outbound mail. We do not include them in the count of the number of defined entities allowing mail for either the service provider or their customers.
Need to fix this?
- Reduce the allowed number of hosts to 32 or below.
Neutral Finding Messages
No SPF record for subdomain: Companies are not penalized for not having SPF records on subdomains; however, systems looking for SPF records are observed.
Good Finding Messages
Summary: Aligned with best practices.
- March 31, 2026: Removed tables to align with AI chat bot needs. Added Warn and Good Finding messages that are seen in product.
- March 29, 2024: Linked to RFC 7208 for "Too many DNS lookups."
- September 11, 2023: Published.
Feedback
0 comments
Please sign in to leave a comment.