Which Exchange Online incoming mail endpoints are there?

Mail is still an important communications protocol to provide and manage. One of the fundamental questions is how other organizations get their mail in your inbox. You would advertise the correct server via an MX-Record, or if you have partner connectors you give the FQDN to the other administrator. But which SMTP endpoint value do you need to use if you are on Exchange Online?

You have multiple ingress points for mail when working with Exchange Online and it’s important to know them to communicate the correct value, protect it and change it when relevant. That might not have as important in the past, but with the advent of Inbound DANE and the use of MTA-STS, knowing the correct SMTP endpoint is now more relevant than ever. There are several distinct kinds per tenant, which I will explain below.

1. The smtp.office365.com and smtp-legacy.office365.com endpoints for SMTP AUTH client submission. In addition, smtp-hve.office365.com is a specific endpoint for High Volume Email currently in public preview.
2. Tenant specific SMTP ingress FQDN: tenant.mail.protection.outlook.com.
3. Per domain you have specific SMTP ingress FQDNs: i.e contoso-com.mail.protection.outlook.com for contoso.com.
4. As an initial domain you have tenant.onmicrosoft.com which has an MX record for tenant.mail.protection.outlook.com. Note that you can have up to 5 onmicrosoft.com domains.
5. The tenant.mail.onmicrosoft.com normally has a MX record to tenant-mail-protection-outlook-com.mail.protection.outlook.com.
6. Last but not least: If you have enabled Inbound DANE, you will have contoso-com.<random>.mx.microsoft ingress point.

Client submission SMTP AUTH Endpoint

The smtp.office365.com endpoint is intended for software/appliances that support authenticated SMTP with TLS1.2 and to send directly to Exchange Online. This is one option if you do not have on-premises mail relay capabilities (such as on-premises Exchange Server). If you cannot use TLS1.2, use smtp-legacy.office365.com or find another solution because Basic Authentication will be removed in September 2025.

Tenant Specific SMTP Endpoint

The tenant specific SMTP or ingress endpoint will never change and is therefore an ideal candidate to use when you have a lot of domains and/or changing them regularly. However, the tenant name can be something very distinct or no longer representative of the organization. In other words, this value is not predictable or easily obtained by others. Note that the endpart is still *.mail.protection.outlook.com and not to be confused with *.onmicrosoft.com.

Domain Specific SMTP Endpoint

The domain specific ingress FQDN are most used. These are the values are predictable and therefor you can use them in automation processes. We expect this value if the mail for this domain is directly ingested by Exchange Online. There are as many ingress points as you have configured accepted domains in Exchange Online.

Initial Domain and MOERA SMTP Endpoint

You can also use Tenant specific OnMicrosoft.com domain as an SMTP endpoint: tenant.onmicrosoft.com. It is the initial domain and mail addresses derived from this domain are Microsoft Online Email Routing Address (MOERA). It will have an MX-record towards the tenant specific ingress point discussed in bullet 1, which will not change.

Mail.onmicrosoft.com SMTP Endpoint

The fourth type is only present in organizations that have configured Hybrid Mailflow. If you configure hybrid mailflow, the tenant.mail.onmicrosoft.com accepted domain is created. Your tenant is using this domain to correctly route mail from on-premises to cloud mailboxes and vice versa. And because it is an accepted domain, it will get an ingress point on <domain>.mail.protection.outlook.com. I never see anyone using this FQDN.

Inbound DANE SMTP Endpoint

And this is the reason this blogpost exists. While I was working with the Public Preview of Inbound DANE your SMTP ingress point had to change. This is because the old mail.protection.outlook.com infrastructure did not support DNSSEC, which is an important requirement for DANE. The *.mx.microsoft record (yes, the top level domain is .microsoft!) is created, when you enable Inbound DANE on a domain. And eventually Microsoft will remove the *.mail.protection.outlook.com FQDN.

Summary

To summarize your tenant with the name tenant and with accepted domain contoso.com has these possible ingress points although eventually not all of them at the same time:

• smtp.office365.com, smtp-legacy.office365.com and smtp-hve.office365.com
• tenant.mail.protection.outlook.com.
• contoso-com.mail.protection.outlook.com.
• tenant.onmicrosoft.com.
• tenant.mail.onmicrosoft.com.
• contoso-com.<random>.mx.microsoft.

Note the exact distinction between *.protection.outlook.com, *.onmicrosoft.com and *.mx.microsoft domains and the addition or lack of .mail. subdomain, it’s easy to misread them.

Which SMTP endpoint do you use with Exchange Online? Devices that can, should use the client submission FQDN smtp.office365.com unless you reach values that would require HVE then use smtp-hve.office365.com. Even if you have on-premises Exchange to relay mail, there might come a time you want to remove your on-premises Exchange Server dependencies.

For accepted domains use the appointed MX record ingress that is provided by Microsoft. This is especially relevant when you require Inbound DANE as it will not work with any other *.protection.outlook.com or *.onmicrosoft.com mail. The latter might get DANE support, but it is still being investigated.

If you need partner connections without a DNS lookup, you can consider the MX values, but you could also consider the tenant specific ingress points. The benefit is that this will never change, despite using different mail domains. You could use the DANE ingress FQDN but do note that the DANE protocol is not used, it’s domain specific and is dependent on the use of those specific Accepted Domains. However, if both organizations support DANE, you might want to consider to forgo on partner connections when Inbound DANE is General Available and supports forced DANE.

In conclusion

That’s it for this blog site first content post! Did I miss any endpoints? Even while writing this post I found new ones I hadn’t considerd. Which SMTP endpoint do you use with partner connections? Did you know about the tenant specific SMTP endpoint? And if you are moving to Inbound DANE, are you aware that you might have to change your partner connections? Let me know!