I searched the Web and the forum, but could not find an answer.
We have DMARC in place for some days now, and it does not look so bad. But still, I see too much orange in the Dmarcian reports. Worse. I do not know if this is normal or not. Our SPF/DKIM/DMARC seems setup correctly, but sometimes SPF or DKIM fail.
See attached screenshot from last Saturday mails. Is this a usual picture, or are the failing rates too high?
If SPF fails, I sometimes see “temperror”.
If DKIM fails, it’s just
See the other attached screenshot. Does it look like a (temporary) MS365 misconfiguration? I am not sure how we could accidentally provide a wrong envelope from header?
First I would like to point out I can only comment on the screenshot, which shows DKIM passing and aligned. The SPF column groups is what is showing a pass/unaligned, and this is due to the SPF identifier evaluated not being aligned.
Alignment occurs when domain evaluated for SPF or DKIM pass their respective check AND the domain verified as part of the check matches the one being evaluated for DMARC, which is the “from” header.
The particular example you are showing is common and expected. The MAIL FROM columns shows a hostname related to an email server doing the delivery of this email. This is due to the MAIL FROM being null, or empty, when this email was sent. The MAIL FROM, commonly known as the return-path, is what is used by receivers to perform an SPF check. If that address is not provided by the sender, the receivers falls back to the HELO/EHLO string to check SPF. The HELO/EHLO will normally be the FQDN of the server sending the email, hence why it looks like that in the DMARC report.
Regarding Temperror, I assume you noticed this for emails reported by either Outlook or Enterprise Outlook. If so, this is a common outcome. We have noticed that Microsoft will occasionally (usually less than 1% of total emails) experience a DNS timeout when looking up DKIM or SPF for verification. What I found through testing is that when this occurs, should the email fail DMARC because of it, MS does not enforce the DMARC policy, though still reports the policy applied as if it did. It is not ideal, but at least you can rest assured emails are going where they need to.
yes, this did help a lot. Thanks! I do understand (now even better) why SPF did not DMARC align. Let me reformulate my question, to make clearer the type of answer I’m looking for.
Assume our mail system is set up 100% correct. Is it still possible (common, usual) that we see SPF 97.26% and DKIM 97.62 (last 7 days) from Microsoft 365 Source? Or do you mail experts suspect config/setup errors?
I ask because I do not have any practical experience and just read docs. Our expertise is more on web app side. If I see successful requests below 99.99% I get alerted.
If I just focus on MS365 I got 2% SPF temperrors the last 7 days. You wrote: “usually” less the 1%. I interpret this as still in the “normal MS365 range”. Wrong Mail From Headers sum up to 1.5% (DMARC unaligned, SPF pass). All failed DKIM failed “raw” and of course, DMARC.
The sending source
Who reports data the most (who you send to the most).
Since Microsoft is prone to DNS timeouts when looking up SPF and DKIM records, sending to predominantly MS recipients will typically result in a lower compliance rate, but without impact to mail flow. This means it’s perfectly normal to expect such rates.
You can filter based on Reporter in dmarcian. Type in Outlook and Enterprise Outlook in the reporter field of the detail viewer, and you will see volumes reported by Microsoft.
Alternatively, you can use the advanced filter list to search for “temperror” SPF or DKIM raw verdict. Then look at the reporters, it will make more obvious if a particular reporter, such as Microsoft, is the cause of the compliance gap.
