3
votes

We had some problems with spoofing, so we had to add all the security checks on the DNS, one of them was the SPF records, first we just added it as a softFail

"~all" and the emails were going to the Spam folder, thats good, on the email headers you can see the SPF did not pass and it gets classified as a softfail.

Received-SPF: softfail

We changed it to a Hard Fail using "-all"

I'm not sure if I'm just getting it wrong, but this is suppose to make it reject the email right? so the user shouldn't even get it correct?, we are still getting it, but now it says

Received-SPF: fail (google.com: domain of [email protected] does not designate xx.xx.xxx.xxx as permitted sender) client-ip=xx.xx.xxx.xxx; Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of [email protected] does not designate xx.xx.xxx.zzz as permitted sender)

Meaning it is a hard fail but I'm still getting it, is that correct?, shouldn't it be completely rejected?

1
DMARC, the setter of policy, is sort of confusing but I found this Return Path article that I think does a good job of explaining it and it's relationship to other records such as SPF. blog.returnpath.com/how-to-explain-dmarc-in-plain-englishNeil Anuskiewicz

1 Answers

1
votes

The SPF is telling the receiving MTA that the check is a fail. However, it is up to the receiving MTA what it does next. Quite possibly, the receiving MTA in this case is not configured to reject emails with a hard fail on the SPF check. I have seen several mail systems deliberately configured to treat both soft and hard SPF fails as a warning, and to tag them and deliver to the spam folder.

If you have DMARC as well, then that may be configured to recommend a behaviour, but again it is up to the receiving MTA if it acts on it.