Initial situation:

The customer uses an SEPPmail Secure E-Mail Gateway. Email domains hosted under M365 are connected to this in parallel (see Connecting Exchange Online with ATP / EOP).

The option Send internal mails (between two managed domains) to the smarthost of the sending managed domain is active machine-wide via On for all domains or for individual email domains via Use domain settings and in the affected managed domain if the Internal mail handling setting is active.

Furthermore, the affected emails are routed via another third-party system (such as CodeTwo or Exclaimer) before they reach the SEPPmail Secure E-Mail Gateway.

 

Problem:

In some cases, outgoing e-mails to the Internet are recognised as incoming. The following line can be found in the detail log of an affected e-mail:

 

X-MS-Exchange-CrossTenant-AuthAs is Anonymous

 

Cause:

The "X-Header X-MS-Exchange-CrossTenant-AuthAs" set by Microsoft describes the origin of an email. Possible values are:

•External: external, authenticated source

•Internal: internal source within the same Exchange organisation

•Anonymous: external, unauthenticated source

 

As the email no longer originates directly from Microsoft due to the routing via the additional third-party provider (see above), the source is categorised as Anonymous.

Based on this value, the SEPPmail Secure E-Mail Gateway in conjunction with the option "Send internal mails (between two managed domains) to the smarthost of the sending managed domain" classifies the respective email as "incoming".

 

Solution:

In this case either:

a) Deactivate the option "Send internal mails (between two managed domains) to the smarthost of the sending managed domain" for the affected Managed Domain.

=> However, this has a significant influence on the routing between two managed domains hosted on M365 (see description above).

 

b) Rewriting the value of the X header from  "Anonymous" to "Internal" for the affected emails. Usually, the circumstances and requirements for this must be checked in a corresponding rule.

 

Note: seppmail.cloud is not affected by this behaviour, as the email direction is determined elsewhere.