First off you should never SMTP Block on any ONE test.  No tests are 100% accurate and if you're going to SMTP Block you should require the message to fail at least two tests.

 

Secondly, if you SMTP Block on SPF failure you're going to block a LOT of valid messages that were simply forwarded thru a server that doesn't support SRS.

 

If you're going to do ANY SMTP Blocking make sure you disable the SmarterMail DNS cache and use your own DNS resolver that doesn't cache, or lets you set a maximum TTL of 1 minute or so.  DNS queries use very little data and there's no reason to risk blocking messages due to stale records.

 

A lot of people use registrar DNS services.  Most of them use a default TTL of 86,400 seconds (one day).  So if your resolver honors TTL it will use the existing cached record until TTL expires.  So even if the real DNS data was changed or corrected you're blocking based off stale value.  

 

-Joe

 

Still digging into this issue.  We have recently lowered RDNS and SPF weights to non-blocking levels to get the mail flowing (albeit to the junk mail folder) but in looking at the SMTP logs from the day before yesterday there still appears to be something strange going on and Outlook.com appears to be "the canary in the coal mine".

 

Searching SMTP logfiles with the following regular expression returned a list of all transactions that were blocked solely due to SPF and reverse DNS failure

^[0-9]{2}:[0-9]{2}:[0-9]{2}\s\[([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\]\[[0-9]+\]\sMail\srejected\sdue\sto\sSMTP\sSpam\sBlocking:\s_REVERSEDNSLOOKUP,\s_SPF\s\(Fail\)$

Interesting reply I found in a post in another forum

 

 

Smartermail needs better SPF failure logging and handling.