DKIM Fail when receiver is O365 customer

[rolelael]

Hi All, let me first try to schematize our setup :

O365 TENANT --> LINUX POSTFIX ( for sender based routing ) --> CISCO ESA ( DKIM signing )--> OUTSIDE WORLD

When a mail is sent from one of our email domains in our O365 tenant ( and DKIM signing is not enabled there ) , it goes through our postfix ( in postfix we have sender based rules ), we then route through our cisco's ( where we sign DKIM ) to the internet

If we sent out an email to a non O365 customer in the big big bad world, like gmail , DKIM is PASS 

--> dkim=pass header.i=@domainx.be header.s=selector-x header.b=RFxvGv4P;

If we sent out an email to a O365 customer ( also the public one hotmail.com ) , DKIM is FAIL

--> dkim=fail (signature did not verify) header.d=domainx.be;hotmail.com; dmarc=pass action=none header.from=domainx.be;compauth=pass reason=100

--> dkim=fail (signature did not verify) header.d=domainx.be;o365Extdomain.be; dmarc=pass action=none header.from=domainx.be;compauth=pass reason=100

Why I don't know......

Anyone else has seen this ?? I know MS started to use ARC in October 2019....

The result is that some O365 customers get our mails in phishing quarantaine, spam, or rejects etc.....

we use seperate dkim signing profiles on our cisco's, key length is 2048 nothing special

[marc.luescherFRE]

Hi there,

without seeing all the SMTP headers I can only suspect what is happening here but this is very common for O365 routing to ESA when not using O365 DNS services. When you setup O365 Microsoft setup wizard will create a default DKIM key pair for your domain.onmicrosoft.com default account. Every email message leaving O365 will always use this DKIM signature unless you have changed the DKIM setup in O365.

An outbound message will then always have two signatures:

DKIM-Signature: v=1 ... d=domain.com

DKIM-Signature: v=1 ...: d=domain.onmicrosoft.com

If you check the top ARC record (ARC-Authentication-Results) you will that ARC detects both DKIM keys as valid (pass) giving you the discovered header.b fields (subjects).

The problem is that since the DKIM domain.onmicrosoft.com is only hosted in the O365 DNS there is no way an external sender can validate this key and it will most likely fail if checked per key.

What are your options :

a) Properly enable your production domain DKIM key in O365 and publish the key to your external DNS 

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email

b) Remove the "domain.onmicrosoft.com" DKIM key with a message filter on the ESA when the email is received from your relay server and sign again with the proper key. 

In both cases your DKIM messages will pass afterwards.

I hope that helps

-Marc

[rolelael]

Marc

Tx

But dkim is disabled in o365 and if i checked the headerq, the dkim from microsoft is not listed

So there is only one dkim
In it and thats the one from our esa

Strangly this started last week to go wrong out of the blue

We have dkim alignment setup also on the global dkim settings and another strange thing we see is when sending from a shared mail ox where a user has send as rights, it really goes wrong ( worked before )

Example : funct box shared@domain.a with iser sending mails with user@domain.b

Esa signs the mail with the dkim keu of domain.a according to our logs

That mail when received on gmail is set to dkim=pass , received in another o365 dkim=fail and ends up in junk mail of recipients o365 box

We really didn’t change anything, and the above Worked fine before last week

Really... i don’t see it

Have a case opened at ms also

[marc.luescherFRE]

Hi Rob,

lets wait for Microsoft to shed some light into why their ARC implementation is working the way it does and also open a feature request for ESA to support ARC. With MS now also being a player in o365 this becomes very critical for support before end of this year.

-Marc

[rmoat]

I know this is a topic over 3 years ago, but also seeing this same issue here. DKIM passes for non-O365 recipients, but O365 recipients are getting dkim=fail (signature did not verify). Was there ever an update on this? Or if it's ARC implementation related?

[José L. Dávila]

Hello there,

Probably a TAC ticket may be best, as this would need us to take a look to the headers of the affected message and the message tracking if possible.

Hope it helps.

José L. Dávila

[alisha_rascon01]

Based on the information provided, it seems that you are experiencing DKIM failures when sending emails from your O365 tenant to O365 customers or recipients using the Outlook.com domain (e.g., hotmail.com). DKIM is passing for emails sent to non-O365 customers, such as Gmail.

There could be several reasons why DKIM fails for O365 customers specifically. Here are a few possibilities to consider:

1. DKIM alignment: O365 might have stricter alignment checks for DKIM signatures compared to other email providers. DKIM alignment ensures that the "d=" (domain) value in the DKIM signature matches the "From" header domain. If the alignment fails, DKIM will show as a fail.

2. DNS configuration: Ensure that the DKIM public key is properly configured in your DNS records for all domains involved. Check that the public key is accurate and matches the private key used for signing.

3. Key management: Confirm that the DKIM private key used for signing is valid and has not expired. Also, ensure that the public key is properly associated with the signing domain in your DNS records.

4. Signature modifications: Some intermediate servers or email gateways might modify the email content or headers, which can invalidate the DKIM signature. Ensure that the email is not altered during transit through your Linux Postfix and Cisco ESA.

5. DMARC policies: Check the DMARC (Domain-based Message Authentication, Reporting, and Conformance) policies for the affected domains. DMARC policies can influence how email providers handle emails that fail DKIM checks. Make sure your DMARC policy is properly configured and aligned with your DKIM settings.

Since you mentioned that Microsoft started using ARC (Authenticated Received Chain) in October 2019, ensure that ARC signing and verification are properly implemented in your setup if applicable.

Investigating the specific DKIM failure messages in the O365 customer's email headers can provide additional insights into the issue. Consider examining the DKIM signature headers and error messages for more detailed information.

If you continue to experience difficulties, it might be helpful to consult with Microsoft support or seek assistance from a professional specializing in email deliverability and authentication.

[rmoat]

I actually have a ticket opened up with Microsoft on this. I wouldn't necessarily say it's breaking at the Cisco ESA level (for rolelael above), but after it reaches the recipient's O365 (inbound protection) tenant. (José L. Dávila)

After doing extensive testing for the last three days, and researching similar issues with customers, it seems it happens when sending an e-mail from a non-Microsoft SMTP server.

Postfix, Mailman, Exim, etc. -> (Internal/External server that does DKIM signing - Cisco ESA for example, or third party Proofpoint, Mimecast) -> Microsoft Inbound Protection (DKIM breaks here) -> O365 Recipient

But an e-mail sent in this way, it will pass DKIM:

O365 (tenant -- Microsoft Outbound Protection) -> (Internal/External server that does DKIM signing - Cisco ESA for example, or third party Proofpoint, Mimecast) -> Microsoft Inbound Protection (DKIM Signature Valid) -> O365 Recipient

So, non-Microsoft SMTP server -> Service/Server that DKIM signs -> O365 = DKIM fail (signature cannot verify)
O365 -> Service/Server that DKIM signs -> O365 = DKIM pass

Since Microsoft uses ARC, I wonder if non-Microsoft SMTP servers, Postfix for example--what OP is using,  need (ARC) OpenArc implemented on the SMTP server as well? (What I believe alisha_rascon01 is mentioning above).

[Ken Stieers]

We have seen similar issues with SPF failures... we send in to O365, it bounces around for a while, then something decides the O365 ip needs to match and it fails...

[rmoat]

That's really strange, and can definitely be frustrating, especially since I'm guessing your e-mails are either going to junk or rejected? For my testing here, I've used the MXToolbox Deliverability and AppMailDev quite a bit to test DKIM, SPF, DomainKeys, etc. I'm not sure if I can post links to external sites like that here, but if you search for MXToolbox Deliverability it will give you the correct URL to a page where they provide an e-mail address that you can e-mail. Same for the AppMailDev website, which can generate a random mailbox and it will do a full report on SPF, DKIM, DMARC, DomainKeys, PTR, and RBL, after you e-mail the mailbox. 

This was just one of my methods to prove that DKIM/SPF/DMARC worked great, unless the recipient was on a O365 tenant and e-mail sent from Postfix (or any other non-MS SMTP server), which points to something happening on the Microsoft Inbound Protection server level before it reaches the recipient's mailbox.

[MatthewWilliams4257]

did anyone ever resolve this issue? I have a customer who is getting the two dkim signatures with one failing. For whatever reason CISCO's logic is going, "any failure means all fail" so when onmicrosoft can't get resolved, it fails and i get a false positive quarantine. Right now i had to create an exception dictionary for senders, which is obviously very manual to maintain.

Without ARC, what options are there? Just using an MFP to strip the onmicrosoft.com dkim header on ingestion?

[Ken Stieers]

So. They still aren't directly supporting ARC, but you can implement your own checking if that's your jam...

There is a discussion about it in this forum somewhere, with answers written by Marc...

I will see if I can dig it up.

[MatthewWilliams4257]

Did you ever get a chance too?  I couldn't find anything

[lbrabham]

Hey all - for anyone else that might get stuck on this, after getting nowhere with a TAC case, I resolved this by completely removing O365 DKIM from the equation. I disabled DKIM signing in O365, set the DKIM signing profile in the ESA to sign all headers, and enabled DKIM signing on both the inbound and outbound relay rules. It's now signing with the ESA selector only, and no more O365 receipt issues.