Office 365 Failing SPF Alignment

Good afternoon All,

New IT Manager and first time implementing SPF, DKIM, DMARC on my own here. I just started at a new company where some of the executives are being impersonated. From my research SPF DKIM and a strict DMARC policy should be the solution to help end this issue for good.

Iv’e been monitoring the DMARC reports before switching p=none to p=quarantine/reject but need to resolve an issue with failed allignment and hope someone can point me in a direction. We leverage Microsoft Office 365 as our emails service provider. I have the Microsoft’s recommened SPF record for Office 365 added to our DNS. However in the screenshot belolw I have two highlighted examples of differences in email allignment and I dont understand why they are different.

The first is a “Mail From” nam11-dm60… it’s Passing RAW SPF but failing the strict allignment. (I think I understand why its failing Strict Allignment, because it does not match the Organizational Domain). Logically enough, the service is technically covered under the SPF PTR Lookups, but the “mail from” domain is reporting air quote “incorrectly”. We are fully cloud no on prem services anymore. The company used to run Sharepoint and Exchange on-prem but migrated to cloud many years ago before I arrived. The question I think I need to ask is, why is the “mail from” server reporting this way? This is a common issue in my implementation of DMARC where my SPF for Microsoft is only passing alignment roughly 30% -45% of the time most days. If I understand correctly, if I am going to enforce a “strict” DMARC allignment I need to be 100%. or risk email delivery issues. We have fully implemented our Custom domain in Office 365, and you can see the aligned example below where the server domain is aligned as I would expect for the service with a custom domain.

Grasping at staws for ideas - could this be an old Sharepoint Server sending emails that might not be configured for the custom domain? We are a small org. I can’t imagine a SharePoint server or other service sending more emails than our regular end users.

Could it be automattic replies from a postmaster account for bounce backs? We get a ton of Junk email and this could easily offset 60% of our outbound emails accounting for the 35-45% alignment.

Thanks you for the feedback on this I am truely lost.


These mails are be autoreplies and NDRs, i.e. mails with no RFC5321.From/envelope-from/return-path headers, so the receiver is using the delivering server’s HELO/EHLO as the SPF Domain which does not align with the RFC5322.From address.

This is correct behaviour based on SPF RFC. When there is no RFC5321 Mail From (also know as return-path), also called a NULL return-path, the receiver will use the hostname given as part of the EHLO command of the SMTP conversation. What this looks like in a DMARC report is a receiver stating it verified SPF against a domain that looks like a hostname, so in your case, the exchange online server. This cannot be changed, but your source of email is fully DMARC compliant through your configuration of DKIM signing. No further action for you to take there.

Let me know if you have more questions.

1 Like