Broken DKIM Signatures on Forwards via External Connector

Hi Samuel Melrose,

If there is any update, please share when you have time.

Thanks,

Carlos

Hi Samuel Melrose,

Given this situation, it is suggested to contact the external email provider and ask the provider to add your domain to white list. Then check if the issue persists.

According to "The problem is external emails ...external email provider"(Your third paragraph), may I know if the external emails are delivered successfully to your domain? And the issue occurs when you send the emails to the external mail provider? Please disable the mail flow rule and send the emails manually to check if the issue persists. 

Regards,

Carlos

Hello Hans,

I think we are going around in circles, the SPF error message is returned incorrectly.

Internal mail is delivered fine as we don't have DKIM enabled for our domain.

The problem is external emails in to our  ***Removed***.com domain, some of which is then sent out again via an External Connector (Mail Flow Rule) to an external email provider.

It is the external email provider that is returning two SMTP errors, which is what is causing the SPF error to be sent.

The first error is about SPF, but the second error is the actual error, stating it is because of the sending domains DMARC policy.

• 550 5.7.23 The message was rejected because of Sender Policy Framework violation
• 550 5.7.1 Unauthenticated email from **.co.uk is not accepted due to;domain's DMARC policy.

External email gets delivered fine to users residing on Office365 (although I can't say if the DKIM signature is broken here too, as Outlook doesn't make it obvious if it is doing any signature validation client side).

It is email sent out via the External Connector that gets altered in a way that breaks the DKIM signature for the body of the message, if it is one with a signature, but only if it's a message with an attachment.

Then, because the sending domain **.co.uk has a strict DMARC policy which tells mail servers they should only accept messages where that domain is the sender if they have a valid DKIM signature, they message is rejected.

Office365 is then passing this rejection back to the external sender, via the NDR that I sent you.

As you can see here, example diff from the email with attachment:

24,25c161,163

< --001a114733c035484b056025d07f--

< --001a114733c0354850056025d081

> --001a114b306e43341b056025d01a--

>

> --001a114b306e43341e056025d01c

Compared to the email without the attachment:

26,27c88,89

< --001a1148e7ba4a6e8b05604cdd8c--

< --001a1148e7ba4a6e9105604cdd8e

> --001a11468748570c3605604cdd36--

> --001a11468748570c3a05604cdd38

On the two diffs above, you can see on the email with the attachment, a newline is being added around the multi-part boundaries.

This is the change that is breaking the signature hash, as that part of the message counts as part of the body, which is used in signature generation.

To verify this is the problem, I used a command line tool to show DKIM signature broken, then removed the space and showed it fixed the message to show the signature is valid again:

smelrose@vdev2:-$ python dkimpy-0.6.2/dkimverify.py < broken_email_received.txt

signature verification failed

smelrose@vdev2:-$ cp broken_email_received.txt br_test.txt; vi br_test.txt

[ edited the file and removed the newline ]

smelrose@vdev2:-$ python dkimpy-0.6.2/dkimverify.py < br_test.txt

signature ok

--------Personal Information Removed---------

Hi Samuel Melrose,

According to the NDR, it is the Sender Policy Framework (SPF) setting caused the validation failed. Please refer to this article to check whether you have set the SPF record properly:

How Office 365 uses Sender Policy Framework (SPF) to prevent spoofing

If it does not work for you, please provide some more details:

1. Does the issue occur to all internal users every time when sending emails to external? Or, does the issue occur to a special external domain?
2. Please provide the entire NDR email via private via private message. (do not mask any word, the info will be highly protected by us.)

( I have removed the blog link for privacy. )

Regards,

Hans