Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to figure out why forged email is being delivered to major email providers (, 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 domain, which defines a broken SPF record. The email is transmitted from my own IP address which is not explicitly listed in's SPF record. The SPF record for 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 address impersonating 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 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 ( 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...

share|improve this question
up vote 14 down vote accepted

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.

share|improve this answer
Agreed. A hard fail doesn't mean that the email will automatically be rejected. It's dependent upon how the receiving server is configured to handle SPF fails. – joeqwerty Mar 6 '14 at 16:35

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.

share|improve this answer is more lenient. I haven't heard of DMARC, that is interesting. – Rook Mar 7 '14 at 15:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.