2

We had first.com emails hosted on Office 365. We then added a new domain second.com on Office 365 Admin. The domain was setup up and the DNS and verified.

After I added an alias john@second.com for an existing user john@first.com, other users in first.com Outlook clients can send emails to john@second.com.

However, external mailboxes, e.g. Gmail or Yahoo, cannot send email to john@second.com.

When I traced using: https://testconnectivity.microsoft.com/ In bound SMTP email, it reports:

  • The host name resolved successfully.
  • The port was opened successfully.
  • SMTP Capabilities were analyzed successfuly.

but

  • Delivery of the test email message failed.

The server returned status code 550 - Mailbox unavailable. The server response was: 5.4.1 [john@second.com]: Recipient address rejected: Access denied [....prod.protection.outlook.com] Exception details: Message: Mailbox unavailable. The server response was: 5.4.1 [john@second.com]: Recipient address rejected: Access denied [....eop-APC01.prod.protection.outlook.com] Type: System.Net.Mail.SmtpFailedRecipientException Stack trace: at System.Net.Mail.SmtpTransport.SendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, Boolean allowUnicode, SmtpFailedRecipientException& exception) at System.Net.Mail.SmtpClient.Send(MailMessage message) at Microsoft.Exchange.Tools.ExRca.Tests.SmtpMessageTest.PerformTestReally() Elapsed Time: 5552 ms.

How can I fix the problem?

ohho
  • 1,005
  • 8
  • 19
  • 34

2 Answers2

2

As you already have the domain verified, the problem is most likely a wrong MX record. It's important to notice that every domain, even within the same tenant, has its own MX settings that can point to different server in *.inbound.protection.outlook.com server pool. The correct MX is usually example-com.mail.protection.outlook.com.

  • Ensure you don't have the first domains MX as the MX for the second i.e. you should not have

    example.org. MX example-com.mail.protection.outlook.com

    but both sides should have org:

    example.org. MX example-org.mail.protection.outlook.com

  • Check the correct MX record from Admin center > Domains > choose the correct domain > Required DNS settings > Exchange Online > Type = MX.

About your testing:

Outlook clients on the same tenant being able to use the alias is a bad test for two reasons.

  1. Mail is delivered internally within the Exchange server.
  2. Outlook has Resolve Method that resolves addresses against the Address Book, sending to the Recipient Object, i.e. SMTP: instead of the original smtp: alias.

The Inbound SMTP Email Connectivity Test on https://testconnectivity.microsoft.com just test that you have an MX record, the server is responding and then tries to send an email. It doesn't know what the correct MX should be and is therefore unable to tell you the correct reason.

Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • Domain is verified. I called Microsoft support, and changed the Accepted Domain from "Authoritative" to "Internal Relay". Mails are delivered OK. However, I have another domain alias set as "Authoritative" and works OK. So I am not sure what is the 'real' fix. – ohho May 10 '17 at 09:17
  • Why would Microsoft Support misdirect you? See the difference between _Authoritative_ and _Internal relay_ on article [Manage accepted domains in Exchange Online](https://technet.microsoft.com/fi-fi/library/jj945194(v=exchg.150).aspx): "You should not select [Internal relay] if all of the recipients for this domain are in Office 365." – Esa Jokinen May 10 '17 at 09:25
2

It's due to faulty DBEB configuration on Microsoft's side. Changing Domain from Authoritative to Internal does disable DBEB See here an article relative to public folders

Issue Description:

When external mailboxes send emails to an Exchange Online public folder, an NDR bounced with the error: 550 5.4.1 Recipient address rejected: Access denied.

Root Cause/Analysis:

When the domain type is set to Authoritative, Directory Based Edge Blocking (DBEB) allows any SMTP address that has been added to the service, except for mail-enabled public folders.

Resolution:

Keep the domain type as Internal Relay.

Reference

Googleing for the NDR text shows the same issue is shared by normal users too in which I add myself both for public folders and for native domain (xxx.onmicrosoft.com)

EDIT: changing domain type did not solve the issue in my case. Ticket was opened and, following internal escalation on Microsoft part, DBEB was disabled. If anyone is following the same route make sure to refer to the first link above when contacting support.

Mike L'Angelo
  • 296
  • 1
  • 8