Ok, maybe I spoke too soon, while there is not as many SPF and reverseDNS lookup failures, it appears they are still happening enough that my clients are still reporting the issue.
I am seeing this in my delivery logs this morning (I bolded the problem areas):
[2023.09.14] 11:56:30.560  Spam Check results: [_DMARC: 0,none], [REVERSE DNS LOOKUP: 10,ReverseFailed], [NULL SENDER: 0,passed], [_SPF: 30,Fail], [_DKIM: 0,None], [ZERO SPAM: 0], [PSBL: 0], [SORBS-NEW: 0], [SPAMCOP: 0], [SEM - BLACKLIST: 0], [IADB: 0], [VIRUS RBL - MSRBL: 0], [BARRACUDA - RBL: 0], [UBL: 0], [VIRBL: 0], [SENDERSCORE: 0], [GBUDB: 0], [ABUSEAT - CBL: 0], [MAILSPIKE-H1, MAILSPIKE-H2, MAILSPIKE-H3, MAILSPIKE-H4, MAILSPIKE-H5, MAILSPIKE-L1, MAILSPIKE-L2, MAILSPIKE-L3, MAILSPIKE-L4, MAILSPIKE-L5: 0], [SORBS-DUL: 0], [UCEPROTECT LEVEL 2: 0], [SORBS-RECENT: 0], [SEM-BL: 0], [LASHBACK: 0], [UCEPROTECT LEVEL 1: 0], [BACKSCATTER: 0], [HOSTKARMA - BLACKLIST: 0], [RFC2 REALTIME LIST: 0], [BONDEDSENDER: 0], [NOABUSE: 0], [SPAMRATS: 0], [SORBS-NOMAIL: 0], [SEM-BS: 0], [IX: 0], [MSRBL: 0], [SURRIEL: 0], [SPAMHAUS - ZEN: 0], [WPBL - RBL: 0], [UCEPROTECT LEVEL 3: 0], [SEM - BACKSCATTER: 0], [NOPOSTMASTER: 0], [HOSTKARMA - YELLOW: 0], [MCAFFEE: 0]
[2023.09.14] 11:56:30.560  Spam Checks completed.
This email was from a client that my customer has been doing business with for years, HarmonyCastings.com
I performed a SPF lookup on MXToolbox and they have a valid SPF record specified. Looking at the header information harmoncastings is using Office365 for their email provider. I can see the ReverseDNS failing if it's expecting to see the client's name attached to it, but the SPF should not have failed at all but yet it still is.
This is part of the header from the email that SmarterMail claimed the SPF failed:
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=harmonycastings.com; dmarc=pass action=none
header.from=harmonycastings.com; dkim=pass header.d=harmonycastings.com;
As you can see clearly right there SPF passed, but yet SmarterMail has it in our delivery logs as SPF failing?
It does appear the client has a cross tenant on Office 365, I see this in the header as well:
So is this a case where Smartermail is only looking at the last section of information? I am at a loss here as to why the SPF failed. Any ideas? Do I have to open a ticket for this?
I am at the point to either shutoff SPF checks (which I really do not want to do) or score it really low at least until I can get some resolution on this. Please let me know.