Jason Bertoch wrote:
A message passed through my server yesterday from an @allianzlife.com
address with the following Received header:
Received: from allianzlife.com (securemail.allianzlife.com
[204.52.250.91] (may be forged))
While investigating other issues with the message, I noted that (unless
my coffee hasn't kicked in yet) it should have matched on SPF_SOFTFAIL,
but didn't. In fact, it didn't match on _any_ SPF rules. I have a
number of other messages in my logs that hit all of the various SPF
rules, so I know that things are at least partially working. The ugly
spf trace is included in the pastebin link, but essentially this falls
back on "~all". Am I missing something obvious?
http://pastebin.com/m1134a08b
Replying to my own post, I've continued to dig around due to the fact
that no SPF rules hit. It occurred to me that the problem may be the
complex and somewhat malformed SPF record this company has produced.
"v=spf1 mx mx:alfemp01.allianzlife.com. mx:blfemp01.allianzlife.com.
mx:mail04.allianzlife.com.ppus.azmx.de.
mx:mail05.allianzlife.com.ppus.azmx.net.
include:cust-spf.exacttarget.com. ~all"
Notably, they use the mx: prefix where I suspect they needed an a:
prefix. (Actually, these are completely unnecessary as these hosts are
all listed as MX records and they've already specified the "mx"
parameter). I would expect that there should be some sanity checks on
the number of (failed) DNS lookups made in an SPF query. If that's the
case, it might explain why I have no match on SPF rules. Can anyone
confirm or deny that there are lookup restrictions with regard to SPF
records?
/Jason