Multiple records returned for TXT query |
Only one SPF record is allowed per domain. If more than one record exists, all records become invalid. |
Choose one TXT record for a particular domain by removing the extras to ensure that SPF is validated properly. |
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. |
Choose one SPF record for a particular domain by removing the extras to ensure that SPF is validated properly. |
SPF record has a recursion error. |
The “include” and “redirect” SPF features allow administrators to manage the records of their domains easier, by reusing previously-configured SPF records for new domains. For example, if Example Company launches a new domain at example.net, they can include the SPF record they’ve already configured for example.com. If the records are exactly the same, they can just redirect the SPF record of example.net to that of example.com. In the case of a recursion error, the include or redirect mechanism is improperly configured so that the record has a circular or self-referencing loop. This will occur if example.net’s SPF record includes the SPF record of example.com, and example.com’s SPF record also includes example.net’s record. |
To locate the included or redirect domain that points back to an SPF record that references it, carefully examine the linked SPF records to fix the SPF record of the offending redirect domain. |
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. |
Implement an SPF record for the domain. For example, www.example.com. IN TXT ""v=spf1 a mx -all. If a server or domain is not going to send mail, implement a null spf record. For example, www.example.com. IN TXT ""v=spf1 -all |
No SPF record for domain |
This domain does not have an SPF record and we have not detected any attempts to send email from it. Without an SPF record, anyone can send email appearing to be from this domain. An attacker can use this during a phishing attack to pretend to be from the company or to send out legitimate-looking spam messages. All domains should have SPF records, even those that aren’t configured to send mail and SMTP servers. |
Implement an SPF record for the domain. Example: www.example.com. IN TXT "v=spf1 a mx -all". If a server or domain is not going to send mail, implement a null spf record. Example: www.example.com.IN TXT "v=spf1 -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. |
Ensure the SPF record for the “include” or “redirect” domain is configured properly and that it is a domain that exists. |
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. |
Check the formatting of your record. A common problem with SPF records is that they include typos. 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 record is formatted in a way that makes it ineffective. This can occur for many reasons, but the most common is a neutral “all” mechanism. This mechanism states that the SPF record will neither pass nor fail any mail agents or servers not explicitly stated in the SPF record. When using a “redirect“, remove any “all“ mechanisms (~all, -all, ?all) from the record (recall that +all is always bad). See https://www.mailhardener.com/blog/spf-redirect-explained for redirect details. |
Check any “?” modifiers in your “all” mechanisms, which defeats the ability of an SPF record to be specific about allowed/restricted domains. Likewise make sure that the “all” mechanism is present. When using a “redirect“, remove any “all“ mechanisms (~all, -all, ?all) from the record (recall that +all is always bad). |
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. |
Limit the number of DNS lookups to 10 or fewer. This includes the following mechanisms: include, redirect, a, mx, ptr, and exists. |
Feedback
0 comments
Please sign in to leave a comment.