1

I'm migrating from Exchange 2010 to Office 365/Exchange Online for a client this weekend. We have setup a Cutover Migration that's been chugging along happily for weeks.

Currently, the MX records for example.com point to: mx1.antispamprovider.com mx2.antispamprovider.com etc.

This cloud-based anti-spam provider (which we control) is configured to deliver mail to mail.example.com, which resolves to the static IP where Example Co's Exchange 2010 Server is NAT'ed behind.

All good, all is well.

As a smoke test, I figured I'd telnet into the Exchange Online mail endpoint (example-com.mail.protection.outlook.com port 25) and send a test email from myself to an existing licensed Exchange Online mailbox, then login as that user at outlook.office365.com and get that warm fuzzy feeling when I see my telnet message...

... half a dozen telnet messages later, and not a single one delivered, despite getting a 250 Queued Mail for Delivery each time leaves me scratching my head.

Well, it's probably quarantined by Exchange Online Protection...

...Checked the Protection (spam, bulk, malware, phish, policy, etc.) and message tracing shows nothing either (tried the "New and Improved" one and the old one, just to be sure).

On a whim, I thought I'd login to the anti-spam provider's management interface and lo and behold, all my telnet messages are shown as being delivered to the Exchange 2010 Server.

So how in the heck does a direct telnet to an Exchange Online mail endpoint, an endpoint which is configured as authoritative for example.com, magically relay the telnet messages out via (presumably) an MX record lookup and not accept and deliver to the local Exchange Online mailbox?

I'm hesitant to actually change the delivery destination in the anti-spam provider, for fear of creating a loop.

EDIT: headers confirm that it indeed is routing out through the Internet by way of an MX lookup.

tl;dr:

Exchange Online (EO) is accepting mail for delivery, but not actually inserting mail in the EO mailbox, despite being licensed and authoritative for example.com. Headers confirm that MS EO/EOP are relaying to current MX records, which point to on-premise Exchange.

gravyface
  • 13,947
  • 16
  • 65
  • 100
  • Are you using Azure AD Connect? – joeqwerty Jan 11 '19 at 04:12
  • Does the SPF fit your source from where you telnet ? as in O365 usually the wizard make your SPF as only accepted from the cloud (or your SPF only list your antispam provider) – yagmoth555 Jan 11 '19 at 04:37
  • I'm telneting from my office IP, which is in my SPF record for my domain, if that's what you mean... in other words, the headers show "SPF pass" for the test telnet message. – gravyface Jan 11 '19 at 15:28

1 Answers1

0

I notice that you are use Cutover Migration, it will create new mailboxes directly in Exchange Online, so there will be two same mailboxes, one is in Exchange 2010 and the other is in Exchange Online. So the MX record is the key point.

When I send message to user1@example.com , since the MX record for example.com is pointing to cloud-based anti-spam provider, this message will be delivered to this provider. And according to your configuration, this provider delivers this message to Exchange 2010. There is no error.

Reference: Migrate email using the Exchange cutover method https://docs.microsoft.com/en-us/Exchange/mailbox-migration/cutover-migration-to-office-365?redirectSourcePath=%252fen-us%252farticle%252fCutover-migration-to-Office-365-9496e93c-1e59-41a8-9bb3-6e8df0cd81b4

Potential delay in email routing: Email sent to on-premises users whose mailboxes were migrated to Office 365 are routed to their on-premises Exchange mailboxes until the MX record is changed.

After migration, you need to change the MX record. And now you didn’t need to use this cloud-based anti-spam provider, Microsoft Exchange Online Protection (EOP) provides built-in malware and spam filtering capabilities that help protect inbound and outbound messages from malicious software and help protect your network from spam transferred through email. Administrators do not need to set up or maintain the filtering technologies, which are enabled by default. However, administrators can make company-specific filtering customizations in the Exchange admin center (EAC).

Jayce
  • 769
  • 4
  • 5
  • This is nothing more than a "here's how mail works..." which I'm well beyond at this point. – gravyface Jan 11 '19 at 12:54
  • But this is the reason why you had this issue. – Jayce Jan 14 '19 at 01:29
  • No, it is not. By telneting into the Office 365 MX record endpoint (example-com.mail.protection.outlook.com on TCP port 25), and typing in an RFC 5322 Internet Message Format compliant message within the course of a standard SMTP conversation, I am simulating precisely what an MX record change would do for the rest of the world's Mail Transfer Agents. Herein lies the problem: I _can't_ change the MX record as EOP/EO are relaying the messages out on the Internet via the _current_ MX, not actually delivering the mail to the EO mailboxes as they should. – gravyface Jan 14 '19 at 15:28
  • I didn’t understand why you didn’t change the MX record after cutover migration. You think that when you telnet to EOP, the message will be delivery from EOP to Exchange Online mailboxes, but not, it also use current MX record to rout the internet message. – Jayce Jan 16 '19 at 06:13