TNEFEnabled SMTP Forwarding Disrupting DKIM Signatures

Issue:

• DKIM signature is invalidating during SMTP forwarding between Microsoft 365 Tenants, between the 1st and 2nd hop.
• So DKIM/DMARC passes on i=1, but DMARC fails on i=2 due to invalidated DKIM signature.
• As an ancillary issue, ARC sealing is also not working because, although we get a dmarc=pass on server i=1 in the SMTP forwarding process, MS does not properly sign the ARC-seal. Giving us cv=none on the first hop, but then cv=fail on the next hop, before the ARC can be properly established.

Scenario:

We have 2 Office 365 Tenants:
Tenant 1: domain1.com
Tenant 2: domain2.com

• Mail sent from Tenant 1 comes in to a recipient on Tenant 2.
• Recipient(s) on Tenant 2 have SMTP forwarding to a corresponding mailbox back inside Tenant 1
• Microsoft’s Sender rewrite scheme systematically breaks SPF alignment by mismatching the smtp.mailfrom and the header.from
• Assuming we can’t fix this SRS mechanism, we rely on DKIM alignment to pass DMARC.
• When mail is forwarded, DMARC fails on i=2 because one of the DKIM-signed headers is changing between i=1 and i=2.
• These are the signed headers encapsulated in the DKIM signature.
  
  • From
  • Date
  • Subject
  • Message-ID
  • Content-Type
  • MIME-Version
  • X-MS-Exchange-SenderADCheck

What is TNEFEnabled?

When an email is forwarded from a remote domain (Tenant 2 – domain2.com) that has TNEFEnabled set to $true, it encapsulates the email’s content using TNEF.

TNEFEnabled refers to a setting in Microsoft Exchange Server environments “Transport Neutral Encapsulation Format.” It’s a proprietary email attachment format used by Microsoft Outlook and Exchange Server. When TNEF is enabled, Exchange Server will encapsulate certain types of email attachments using the TNEF format. This format can include things like rich text formatting (RTF), embedded images, and other Outlook-specific features. Administrators can enable or disable TNEF functionality in Exchange Server depending on their organization’s needs and the compatibility requirements of their email recipients.

Here is a screenshot of the setting in the AutoForward settings in EXO  

“Follow user settings” = -TNEFEnabled $null

To apply this setting, you can also use PowerShell in the Exchange Management Shell. Here’s a step-by-step guide:

1. Open Exchange Management Shell: Launch the Exchange Management Shell on your Exchange server.

2. Run the Command: In the Exchange Management Shell, execute the command to set -TNEFEnabled to $null. The command should look something like this:

This command sets the TNEF option to $null, effectively disabling it for the default remote domain. If you want to apply this to a specific remote domain, replace Default with the appropriate identity.

3. Verify Settings (Optional): You can verify that the setting has been applied correctly by running:

This command will display a list of remote domains and their TNEF settings. Make sure the one you modified reflects the change.

4. Restart Services (Optional): In some cases, you might need to restart Exchange services for the changes to take effect. You can do this by restarting the Exchange Transport service.

How TNEFEnabled affects Content-Type header

The Content-Type header in an email message describes the type of content being transmitted. As the email message transits through SMTP forwarding servers or other email relay points, these servers may inspect the email headers and content. If they detect that the email is encapsulated in TNEF, they may modify the Content-Type header accordingly to reflect the TNEF format.

We determined this was indeed happening.

Finally, when the email comes back in to the Tenant 1 email server, the Content-Type header will indicate whether the email content is in TNEF format. This ensures that recipients and their email clients can interpret the email content correctly, especially if they are using Microsoft Outlook or Exchange Server environments that support TNEF.

How Content-Type header affects the DKIM signature  

1. DKIM Signature: DKIM is an email authentication method that allows the sender to digitally sign certain email headers and the body of the email. This signature is added to the email headers by the sending server to provide a mechanism for the recipient server to verify the authenticity of the email.

2. Signed Headers: When configuring DKIM, the sender typically specifies which headers should be included in the signature. Common headers include From, Date, Subject, Message-ID, and Content-Type, among others.

3. Content-Type Modification: Enabling TNEF on SMTP forwarding settings can result in modifications to the Content-Type header of email messages, particularly if the email content is encapsulated using TNEF. This modification could alter the Content-Type header to indicate that the email content is in the TNEF format.

4. DKIM Verification: When the recipient’s email server receives the email with the DKIM signature, it verifies the signature by recalculating it based on the specified signed headers. If any of the signed headers have been modified after the DKIM signature was applied, the verification process may fail, indicating that the email has been tampered with in transit.

5. Breakage: If the Content-Type header, which is typically included in DKIM signatures, is modified due to TNEF encapsulation, the DKIM signature verification may fail because the signed Content-Type header no longer matches the actual Content-Type header after TNEF encapsulation. This can lead to the DKIM signature being considered invalid, potentially causing the email to be treated as suspicious or even rejected by the recipient’s email server.

Trusted ARC Sealer Workaround?

We explored ARC Sealing using microsoft.com as the trusted ARC sealer. The problem here is, when SMTP forwarding:

• At server i=1, the ARC-Seal header is there, but has cv=none, and ARC-Auth-Results header has dkim=pass, dmarc=pass, arc=none.
• Then we see on server i=2, cv=fail, dkim=fail, dmarc=fail, and arc=fail.

Here are the headers:

• ARC-Authentication-Results
  • i=2; mx.microsoft.com 1; dmarc=fail (p=quarantine sp=quarantine pct=100) action=quarantine header.from=domain1.com; dkim=fail (signature did not verify) header.d=domain1.com; arc=fail (47)
  • i=1; mx.microsoft.com 1; dmarc=pass action=none header.from=domain1.com; dkim=pass header.d=domain1.com; arc=none
    
• ARC-seal
  • i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=fail
  • i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none

So, with this underlying TNEFEnabled on SMTP forwarding, in our scenario it actually was breaking ARC sealing as well, due to DKIM hash already not verifying (thus DMARC failing) when it hits i=2, before the ARC chain is even established. Once we fixed DKIM, DMARC then passes at each intermediary server (and the destination) without the need for a trusted ARC-seal.

This appears to be an issue with microsoft’s SMTP forwarding hub not properly ARC-sealing the messages.When the messages reach i=1, we are not getting an ARC-seal with a valid chain validation (cv=none).

Why is that?

When they reach i=2, the chain validation of ARC cannot be established because DMARC fails on this 2nd hop. We can assume the Content-type header is edited after the message is ARC-sealed with a non-validated cv at i=1, but before it arrives at i=2.

Post-Incident Analysis

• TNEFEnabled was set to $true on the remote domain (Tenant 2) from which the email was being forwarded (@domain2.com).
• This was modifying the Content-Type header in transit, since that’s what this particular variable does.
• This was breaking the initial DKIM validation on the domain1.com signature, causing DMARC to fail early in the forwarding process.
• Because of this, DMARC was not passing, and not even ARC sealing was working on these remote domains.
• TNEFEnabled was changed to $null for the remote domain of the forwarder ( Tenant 2 – @domain2.com).
• Now the header.from domain1.com DKIM validates and aligns when it arrives at server i=2.
• Therefore DMARC now passes/aligns all the way along the Authenticated Received Chain (ARC) without the actual need for a trusted ARC sealer.

Remaining Questions:

• Why do we not get an ARC-seal with a cv=pass on hop #1 (i=1) ? This seems like a huge problem for anyone with a setup similar to ours.
• Why do we not get a new DKIM signature attached wherever the Content-Type header is modified somewhere between i=1 and i=2?