- September 11, 2023: Separated finding messages.
- April 20, 2023: 2023 RAU risk category weight adjustment.
- October 20, 2021: Ratings Algorithm Update 2021.
⇤ How is the Diligence Risk Category Calculated?
To assess the SPF Domains risk vector, we look for the presence of SPF records in the company’s primary domain, subdomains, and any domains that have sent or attempted to send email. These domains typically correspond to mail servers. We also look at subdomains.
Impact
| Field | Description | Details & Values | |
|---|---|---|---|
| Finding Behavior | How findings behave, depending on the action taken. | Impact is immediate. Grades improve when a new SPF Domains finding is detected. | |
| Lifetime | The number of days a finding will impact the risk vector grade, assuming nothing changes in the future and the finding is not updated with new information. Learn why findings have a decay and lifetime period. | 60 Days | |
| No Findings | The letter grade if there are no findings for this risk vector. |
Having SPF records for all domains (including SMTP servers and those that aren’t configured to send email) is best practice. If a company does not intend to send email from a domain, an attacker can still use that domain to spoof email. Only domains that are sending email and don’t have SPF records are affected. |
|
| Refresh | The Bitsight platform regularly checks for new observations. Bitsight findings are updated as these observations change, e.g., newly observed Diligence findings or an existing finding was remediated. | ||
| Automated Scan Duration | The duration of a regularly scheduled finding refresh, as the Bitsight platform checks for new observations. | 2 Weeks | |
| User-Requested Refresh Duration | The duration of a user-requested refresh, which initiates a refresh of eligible findings upon request. This is recommended when a change in the finding is expected, such as when a finding has been remediated. | 1 Business Day | |
| Weight | Out of 70.5% in Diligence. | 1% | |
Evaluation
An assessment is provided based on syntactical correctness and effectiveness of hosts that are authorized to send emails on behalf of a domain:
Syntactical Correctness
A record is syntactically correct if it conforms to the SPF RFC. An effective SPF record identifies a set of hosts that are allowed to send email on behalf of the domain. In addition, that record states that email from all other hosts should either be assigned the state “reject” or “accept but mark.”
Effectiveness
A syntactically correct SPF record may still be ineffective if it contains conflicting elements or assigns the state “accept” or “neutral” to all other hosts. A domain must only have one SPF answer specified in the DNS TXT record and the SPF record of a domain. If both a TXT answer and SPF answer exist, they must match.
Number of Authorized Hosts
The larger the number of hosts authorized to send emails on behalf of a domain, the higher the chances of a mail server getting compromised. All domains should have SPF records, even those that aren’t configured to send mail and SMTP servers. Even if a company does not intend to send mail from a domain, an attacker can still use that domain to spoof email. Because of this, companies without SPF records will have an SPF grade of “F.” Domains that aren’t being used to send mail should have null SPF records.
Example null record:
example.com. IN TXT "v=spf1 a:mail.example.com -all" mail.example.com. IN TXT "v=spf1 a -all" www.example.com. IN TXT "v=spf1 -all"
Finding Grades
Diligence findings are evaluated as GOOD, BAD, or NEUTRAL. An overall letter grade is calculated, using the evaluations of individual findings.
If there’s no message, the SPF record is effectively preventing unauthorized individuals from sending spoofed email from this domain. It is properly configured and only authorizes necessary domains to send email. An effective SPF record is graded as “GOOD.”
See finding messages.