Brian Reid – Microsoft 365 Subject Matter Expert

Anonymous Emails Between On-Premises and Exchange Online

When you set up Exchange Hybrid, it should configure your Exchange organizations (both on-premises and cloud) to support the fact that an email from a person in one of the organizations should appear as internal to a recipient in the other organization. In Outlook that means you will see “Display Name” at the top of the message and not “Display Name” <email address>. An email from the internet is rightly treated as anonymous and so should appear as “Display Name” <email address> but when it comes from your on-premises environment or your cloud tenant it should be authenticated.

In the email headers you should see a header called AuthAs that reads internal. The SCL (Spam Confidence Level) should always be –1 and you should not have a header called X-CrossPremisesHeadersFilteredBySendConnector visible on internal emails.

Your hybrid setup can be incorrectly configured and cause this, and depending upon what Exchange Server version you are running and when you last ran the hybrid wizard you can end up with different results.

Lets take a quick view to some of the settings you should see:

  1. Exchange Server 2010 (with or without Edge Server 2010)
    1. Hybrid wizard will use Remote Domains to control internal vs external and authentication state. You should have a Remote Domain for tenant.mail.onmicrosoft.com that shows TNEFEnabled, TrustedMailOutboundEnabled, TargetDeliverDomain, and IsInternal all set to True on-premises
    2. TrustedMailnboundEnabled attribute is set to True on Get-RemoteDomain domain.com in the cloud
    3. The AllowedOOFType, which controls Out Of Office is set to InternalLegacy
  2. Exchange Server 2013 and later
    1. Your “Outbound to Office 365” send connector on-premises should have CloudServicesMailEnabled set to True
    2. The Remote Domains matter for Out of Office and moderated emails/voting buttons, but not for authentication as mentioned in #1 above
    3. The Inbound Connector for “Inbound from GUID” should have CloudServicesMailEnabled set to True
  3. Exchange Server 2010 with Exchange Server 2013 or later Edge (no 2013 on-premises, only Edge)
    1. The setting CloudServicesMailEnabled needs to be True, but 2010 does not support this setting, so you need to edit the directory using ADSIEdit and change the msExchSmtpSendFlags on the send connector from 64 to 131136. All this does is tell the 2013 or later Edge to enable CloudServicesMailEnabled
    2. See https://support.microsoft.com/en-us/help/3212872/email-sent-from-an-on-premises-exchange-2013-edge-transport-server-to for the steps to do this
  4. As #3 but with 2010 and 2013 on-premises – run the cmdlets and hybrid wizard from the 2013 server and not connected to the 2010 server!

Posted

in

, , , , , , , ,

by

Brian Reid

Tags:

Comments

9 responses to “Anonymous Emails Between On-Premises and Exchange Online”

  1. Anonymous Emails Between On-Premises and Exchange Online – C7 Solutions – JC's Blog-O-Gibberish

    […] Anonymous Emails Between On-Premises and Exchange Online – C7 Solutions — Read on c7solutions.com/2018/05/anonymous-emails-between-on-premises-and-exchange-online […]

    Reply
  2. Andy Cippico avatar
    Andy Cippico

    Hi, I have a scenario which I’m not sure you covered (forgive me if I’ve missed it). I have Exchange 2013 and Edge Transport Server 2013 on-premises. It is operating in Hybrid mode and all is well except emails from MS365 are arriving as Anonymous rather than Internal. I assume I should change something on the Edge Server as that’s where our MX currently points to. Where should I be looking?

    Reply
    1. Brian Reid avatar
      Brian Reid

      I’ll assume that you have EdgeSync running and that the connectors on the Edge where built by the Hybrid Wizard and not made by hand? If they were made by hand, get the Wizard to make them – it will set the Oorg settings correctly.

      Reply
  3. QTum avatar
    QTum

    Hi, another case that (surprisingly) I was not able to find:
    We have Barracuda for Relay/mx in front of a single Exchange2013 configured for HCW.
    Emails from on-prem users to O365 are seen as internal – all good
    Emails from O365 to on-prem users are seen as internal – all good

    Emails from Internet to a migrated user = anonymous, SCL 5

    Any clues ?
    Searching and trying for 2weeks 🙁

    PS: Voting buttons, free/busy works as expected.

    Reply
    1. Brian Reid avatar
      Brian Reid

      “Emails from Internet to a migrated user = anonymous, SCL 5” – but that is correct. The email is originally anonymous and so it stays anonymous when it arrives in Exchange Online. Emails between unmigrated users and migrated users should be authenticated, but not between external and internal users.

      Reply
  4. Sandy Singh avatar
    Sandy Singh

    Hi Brian,
    I have a client using exchange hybrid with centralized mailflow pointing MX at PP, all was good when user mailboxes were at on premise but after migration email from internet to mailbox(o365) getting treated as internal with scl -1 which is causing issues as user block sender list is not getting honored.

    Reply
    1. Brian Reid avatar
      Brian Reid

      Hybrid and centralized mail flow have nothing to do with your MX pointing at Proofpoint. If you have MX to a separate email filtering solution then you need to manage the block lists etc. in that product. This is especially true if you have added the settings often recommended by the email filtering solution to whitelist everything that comes through the filter. If you do this everything comes through PP and so is all whitelisted at EOP. A better solution is “skip listing”.

      Reply
      1. Sandy Singh avatar
        Sandy Singh

        Thanks for the response.
        This is the current inbound mailflow they have in place:
        Internet->PP->on premise->o365.
        All was good until they moved milbox to o365.
        Question, do they need to change something in connector in exchange on premise?

        Reply
        1. Brian Reid avatar
          Brian Reid

          I’ve seen this before. Someone in the past has been adjusting the receive connectors on-premises so that the previous hop (PP in your case) is hitting an already authenticated connection – the connector probably has ‘externally authenticated’ enabled. This means Exchange Server sees all the anonymous Internet traffic as trust led internal traffic and so Exchange Online sees the same thing as authentication info is shared between them. Fix your PP to Exchange Server connector – it should hit the default receive connector and this should not be modified from the product default in any way

          Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.