DKIM and SPF fail-unaligned due to outlook.com forwarding

Hi guys,

I’ve noted that the majority of my e-mails have been forwarded by “*.outlook.com” and after the forwarding DKIM and SPF shows status “fail-unaligned” and my messages have been marked as Quarantine. I see also that during forwarding outlook.com is changing the DKIM and SPF domain to recipient’s outlook account domain, which I believe causes the quarantine policy to be applied.

Can you please advise me, what can I do in order to make outlook.com to preserve my DKIM and SPF?

Kind Regards,
Nikolay Zhelev

Hi Nikolay,

Short answer, nothing as it is mostly not up to you. The effect forwarding has on an email can be hard to predict. The majority of forwarding will occur with some sort of address rewriting on the return-path, which will most often cause alignment failure with SPF. This is to be expected. All you can do, is to ensure your own systems are properly configured with both SPF and DKIM. DKIM can especially be helpful with forwarding, but there are instances where it could be stripped out.

If you have both DKIM and SPF configured and aligned with your From: header in a DMARC compliant manner, then the forwarder and how it is performing the forwarding will ultimately determine if the authentication will survive the forwarding. For instance, Outlook mailbox rule redirect action will typically save the original DKIM signature, and assuming no changes are made to the DKIM signed content of the mail, will be delivered with DMARC verdict of pass. However, any changes to the body or subject, such as tagging, disclaimer, banners etc, would break it.

In the end, there is no easy answer. Ensuring your systems are properly configured is the best and in many case only step realistically available to you. In case of known forwarders (i.e business partner with whom you have a critical relationship) then it makes sense to reach out to point out the issue.

I hope this helps.

Ash @ dmarcian

Hi Ash,

Thank you very much for your complete reply. I’m doing my best to keep my domain properly configured. If you have time, would you be able to perform a quick check on my records. I’ll send the address on PM.
Also I have critical relationship with my business partners and I’ll try to reach them to communicate this issue.
Kind Regards,
Nikolay

Hi Ash,

I can’t seem to get my head around this issue. Can you provide more background and/or a reference document to read.

Also, is there any way of identifying the specific emails that are being forwarded so we can trace them down?

Thanks.

There is no guide or written piece that I would be comfortable in sharing that would likely convey what I would want. However this is a good case for us here at dmarcian to begin work on a piece that will hopefully help.

As far as identifying specific emails, DMARC feedback reports and Failure reports can help. Failure reports (also known as forensic reports) are rarely sent by reporters, so you cannot rely on those to always provide an answer. In the case of feedback reports, this is where DKIM shines. The typical case of automated forwarding will keep all original headers of the mail sent, and since DKIM is a header, it will in most cases remain.

A receiver will validate in most case all signature which exist on an email. A DMARC feedback report will often contain which selector the receiver saw as part of the signature it verified. A DKIM selector can provide a lot of insight as to where the email comes from. For example, let’s assume an email is sent from Microsoft Office 365. The selector used by MS is selector1 and selector2. Now let’s assume the forwarder is Google. What you will see in the DMARC feedback report is Google as the sending network, but a DKIM signature (passing or failing) using a signature of selector1 or selector2, along with the signing domain. Knowing you use O365 in this example to send mail, then you know the original source of emails were from Office 365 sent to a Google environment.

Now, this won’t tell you which “specific” emails from O365 were sent, but it’s a start. Additional data points to look at is the return-path. If the return-path is different than your domain, and since you identified the source is your O365 tenant, than this means some kind of address rewriting took place. The typical behaviour is for the return-path to be changed to the domain owned by the forwarder, so that bounce backs will be sent to the forwarder in case of issues. This can be a bread crumb trail to knowing which domains your O365 emails were sent to that were forwarded.

Ultimately tho, Forwarding happens a LOT, and it is simply not realistic to identifying each individual forwarders unless your recipient audience is very thin.

I hope this helps.

Ash
dmarcian inc

1 Like