When many people think of Microsoft’s services and software, they frequently gravitate toward email and collaboration. Microsoft originally entered the email arena in 1988 with Microsoft Mail; 8 years later, it revolutionized the corporate landscape with the release of Exchange Server 4.0. The rest, as they say, is history.
Over the years, Microsoft has continued to refine and develop Exchange, eventually making it available online as a service as part of the Business Productivity Online Suite—the forerunner to Office 365 and the Microsoft 365 offering. Microsoft’s latest editions allow organizations to send email and host mailboxes seamlessly between cloud and on-premises environments. Exchange hybrid solutions use a combination of on-premises Exchange servers in conjunction with Exchange Online—most often, as part of a migration strategy, but sometimes in long-term coexistence scenarios as well.
In this chapter, we’ll focus on the following areas of Exchange Online deployments:
- Planning for DNS records
- Planning and implementing mail routing
- Planning and implementing organizational settings
- Planning and implementing an Exchange hybrid organization
By the end of this chapter, you should be able to describe the components of an Exchange Online deployment, as well as the concepts of hybrid connectivity and mail routing.
Let’s go!
Planning for DNS records
If you’re reading this book in chronological order, you’re already familiar with the importance of DNS records from the perspective of enabling a Microsoft 365 tenant. In Chapter 1, you learned how Microsoft 365 uses TXT DNS records to show proof of ownership for domains. Exchange Online is no different; in fact, every domain you add as part of the domain verification process is automatically added as an accepted domain and made available to use in Exchange Online.
In addition to the TXT records used to verify domain ownership, Exchange Online also employs several other DNS records:
Record type | Hostname | Target or value | Purpose or Description |
CNAME | autodiscover | autodiscover.outlook.com | Helps messaging clients locate a mailbox |
MX | @ | domain.mail.protection.outlook.com | Indicates what service is responsible for accepting mail on behalf of a domain |
TXT (SPF) | @ | include:spf.protection.outlook.com | Helps prevent unauthorized senders from spoofing or masquerading as your domain |
TXT (DKIM) | Selector1._domainkey Selector2._domainkey | selector1-domain._domainkey.initialdomain selector2-domain._domainkey.initialdomain | Helps prevent unauthorized senders from spoofing or masquerading as your domain |
TXT ( Domain-based Message Authentication, Reporting, and Conformance ( DMARC )) | _dmarc | V=”DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1″ | Instructs recipient servers on how to handle mail based on Sender Policy Framework ( SPF ) and DomainKeys Identified Mail ( DKIM ) values |
TXT (Fed) | @ | A value provided by the Exchange Hybrid Configuration Wizard ( HCW ) | Exchange 2010-based hybrid deployments require an additional DNS record to establish a relationship with the Microsoft Federation Gateway |
Table 11.1 – DNS records
Let’s look at what some of the records are used for in the next few sections.
MX
Most administrators, especially if they have been working with email, are familiar with mail exchanger (MX) records. Depending on your deployment or migration strategy, you may wish to update your MX record to point to Exchange Online (as opposed to an on-premises mail gateway or other mail service provider). Strategies for when to update the MX record can vary greatly—some organizations may wish to update it right away, while some wait until after a migration is complete. Still others maintain separate mail hygiene infrastructure and never update their records to point to Exchange Online.
As long as there is a clear path to deliver mail to mailboxes, the target address for a domain’s MX record doesn’t matter from an overall functional perspective.
Further reading
The foundations for mail routing records were laid in very early Request For Comments (RFC) documents such as 821, 897, and 992. The MX record itself was first defined in RFC 974 in 1986. You can learn more about historical and current RFCs at https://www.rfc-editor.org/.