Home / server / Questions / 580278
Accepted
Rook
Asked: 2014-03-07 08:15:12 +0800 CST

Why is email being delivered normally despite an SPF "hardfail"?

  • 772

I'm trying to figure out why forged email is being delivered to major email providers (gmail.com, outlook.com) even though email is marked with an SPF hardfail. The email is also delivered to Microsoft Exchange, which is throwing a PermError for the same SPF record.

I am sending email using the SOME_DOMAIN.com domain, which defines a broken SPF record. The email is transmitted from my own IP address which is not explicitly listed in SOME_DOMAIN.com's SPF record. The SPF record for SOME_DOMAIN.com has the following three properties, the first two are a violation of the SPF RFC-4408:

  1. Requires more than 10 DNS queries to resolve the entire SPF record, due to include:.
  2. Syntax error in one of the SPF records, python-spf throws a parse error.
  3. The SPF record contains both the rules ~all and -all, both saying that the set of all addresses should softfail and hardfail

Email sent to an outlook.com address impersonating admin@SOME_DOMAIN.com will contain the following error in the SMTP header of the delivered email. This email was delivered normally to the user's inbox: 

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail will also deliver the email to the user's inbox, but will throw a different SPF error:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

So what is going on here? Why is email being delivered despite an SPF hardfail? Does having a broken SPF record mean that other SMTP servers disregard the SPF entirely? Or is there something I'm missing here...

email

2 Answers

  1. Best Answer

    SPF is so badly configured by so many sites that receiving MTAs often count hardfail as advisory only, and merely factor it into their spam detection scores. In the end it's up to the MTA's administrator as to how SPF failures will be treated.

    • 17

  2. SPF error conditions do not indicate anything about the desired policy. As such they provide no guidance as to whether or not to accept the message. It is possible that the intended policy is +all. It is normal to accept mail in this case. It appears Google is being lenient with this domains failure to comply with the standard.

    Even SPF policy rejections (-all) are unreliable when validating sender addresses. There are a number of cases where rejecting such mail would be inappropriate including:

    • Mail sent by contracted mailers (These people get paid to violate the policy.);
    • Mail sent from web forms and other such automated system;
    • Mail forwarded by mailing lists or other forwarding mechanisms; and
    • Just plain misconfiguration of the SPF records (not common, but not rare enough).

    I run a fairly small server where I can defer on hard-fails. This allows me to white list legitimate failures. If the sender notices the mail isn't get delivered, they may fix their configuration. In some cases I will attempt to contact the relevant postmaster, but many domains don't have a postmaster address.

    Users who want to enforce a stronger policy can use DMARC, which is not yet a standard. Mail is still likely to be delivered, but may be quarantined or rejected as specified in that policy. Mail which fails the policy may to be delivered to the spam folder, rather than the normal inbox.

    SPF hard fails do seem to be reliable to validate the sending server's identity. I did some research a while ago, and found that even soft fails on the HELO name are a reasonable reason to fail or defer incoming messages.

    Many mail servers don't have an SPF record. If the mail server does not have an SPF record, I check against the parent domain for an an SPF record. This is non-standard, but effective. I encourage email administrators to ensure there is a an SPF record for the servers IP as listed in the PTR record. Your server should identify itself by the name returned by its PTR record as well. Verify you have a corresponding A record for reverse DNS verification.

    • 6