Skip to main content

SPF Record Contains a Soft Fail

Lester Ma
  • Updated

In this article:

    API name: spf_record_softfail
    Severity: Low (in Scoring 2.0)
                   Medium (in Scoring 3.0)
    Factor: DNS Health

    Why this issue is important

    A soft fail in an SPF record means that suspicious emails, or emails from unauthorized servers, are not rejected, but forwarded to a spam folder, or marked as suspicious. This raises the risk that users in your organization may open spoofed, or potentially malicious, emails.

    The Sender Policy Framework (SPF) is a simple, but effective, email-validation technique designed to detect forged emails, or spoofing. An SPF record is a list of authorized sending hosts for the domain listed in the return path of an email. It is published as a Domain Name System (DNS) record for that domain in the form of a specially formatted TXT record.

    An SPF record is required for spoofed e-mail prevention and anti-spam control. Simple Mail Transfer Protocol (SMTP) does not allow for complete prevention of spoofed emails; however, the SPF header reveals whether or not the email is authentic.

    What are SPF failures, hard fails, and soft fails?

    SPF failure occurs when the sender's IP address is not found in the SPF record. The email is then sent to a spam folder or rejected.

    A hard fail means that emails from unauthorized senders are deleted only. In the following example of an SPF record, only the IP address 192.168.0.1 is authorized to send emails. The -a flag preceding the address means that all other senders—those not listed in the record—are unauthorized, and their emails are discarded.

    v=spf1 ip4:192.168.0.1 -all

    A soft fail means that emails from unauthorized senders are not discarded but forwarded to a spam folder, or marked suspicious. In this case, a tilde (~), not a hyphen (-) precedes the all argument. In the following example, only Microsoft Office 365 is authorized to send emails, but emails from other senders are not rejected.

    v=spf1 include:spf.protection.outlook.com ~all

    How does DMARC work with SPF?

    Enabling Domain-based Message Authentication, Reporting and Conformance (DMARC) is an important control that complements SPF. DMARC is an email authentication protocol that sets policies for handling emails that are failed by SPF:

    • none – No action is taken.  
    • quarantine – Failed emails are delivered to the recipient's quarantine mailbox, and the mail server decides whether the email gets delivered or rejected.
    • reject – Failed emails are prevented from reaching the recipient, who is never made aware of these emails.

    In the following example, a DMARC policy is configured to reject emails that are failed by SPF checks:

    v=DMARC1; p=reject; rua=mailto:dmarc_agg@vali.email,mailto:dmarc_agg@dmarc.everest.email; ruf=mailto:dmarc_fr@dmarc.everest.email
    Tip: Learn more about enabling and configuring DMARC.

    How this issue is discovered

    We examine two controls for each domain in your Digital Footprint:

    • We assess how SPF records fail unauthorized email senders. A record with a soft fail is flagged as a finding. SPF records are typically refreshed approximately every 48 hours. 
    • We verify that a DMARC policy is enabled and set to quarantine or reject. The absence of an enabled policy, or the presence of a policy with a value that is empty or set to none, is flagged as a finding.

    How you can remediate this issue

    Take the following remediation actions:

    • Compile a list of email servers that are authorized to send email on behalf of the domain. Update the SPF record with the correct email authorization list and use the hard fail flag:  -all
    • Even if a domain in your organization does not send emails, as with a parked domain, provide a defensive SPF record for it. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) recommends this as well. Malicious parties can mimic any domain to send spoofed and malicious emails.
    • Enable a DMARC policy, and set it to quarantine or reject for emails from unauthorized sources.

    How you can resolve this issue in SecurityScorecard

    Follow issue resolution steps and provide one of the following reasons to remove it from your Scorecard:

    I have fixed this

    If you add an SPF record to a domain and validate it with an independent tool, such as SPF Checker, ask us to inspect the record in the resolution process. This will accelerate the removal of the finding. 

    If you do not accelerate the removal, the finding will decay as in the time period defined in our Scoring methodology whitepaper.

    I have a compensating control

    A valid compensating control for having an SPF soft fail is to have DMARC set up to quarantine or reject.

    Screen_Shot_2021-07-28_at_4.16.17_PM.png

    This is not my IP or domain

    Indicate that IP does not belong to your organization, and the DNS entry has been corrected for the IP.

    I cannot reproduce this issue and I think it is incorrect

    Validate the SPF record with a tool such as SPF Checker, and show us the result.

    Related articles