Lab 08: External Mail Flow and DNS Records

Overview

In this lab, I connected the public domain nietz.co.uk to Microsoft 365 Exchange Online by configuring the required DNS records in Cloudflare and confirming Microsoft 365 recognised the records as valid.

I then enabled DKIM, published a DMARC monitoring record, and validated external mail flow by sending and receiving test messages through the Support shared mailbox.

Objective

The objective was to prove that nietz.co.uk was correctly configured for Exchange Online mail routing, Outlook Autodiscover, SPF, DKIM and DMARC, and that the Support shared mailbox could send and receive external mail successfully.

Environment

Configuration

1. Domain Status Before Exchange DNS Connection

I reviewed the Microsoft 365 domain status for nietz.co.uk before connecting Exchange Online DNS services.

Context: This established the starting point before Exchange Online DNS records were connected to the public domain.

2. Required Exchange Online DNS Records

I reviewed the Microsoft 365 DNS requirements for Exchange Online and identified the required MX record, Autodiscover CNAME record and SPF TXT record.

Context: These records control inbound mail routing, Outlook Autodiscover and SPF sender validation for the custom domain.

3. Exchange DNS Records Added in Cloudflare

I added the required Exchange Online MX record, Autodiscover CNAME record and SPF TXT record in Cloudflare and confirmed that the records were set to DNS only where appropriate.

Context: Exchange Online mail flow depends on public DNS. The MX record routes inbound mail to Microsoft 365, the Autodiscover CNAME helps Outlook locate Exchange Online services, and the SPF TXT record authorises Microsoft 365 to send mail for the domain.

4. Microsoft 365 DNS Health Confirmed

I returned to Microsoft 365 and confirmed that the Exchange DNS records were detected successfully.

Context: Microsoft 365 validation confirmed that the public DNS records were visible and matched the expected Exchange Online configuration.

5. DKIM Status Before Configuration

I reviewed the DKIM status in the Exchange admin center and confirmed that nietz.co.uk was not yet signing messages with DKIM because the required selector records were missing.

Context: DKIM adds cryptographic signing to outbound mail so recipients can verify that messages were authorised by the sending domain and not modified in transit.

6. DKIM Selector Records Identified

I opened the DKIM configuration details for nietz.co.uk and recorded the required selector CNAME records.

Context: Microsoft 365 requires two DKIM selector CNAME records so Exchange Online can publish and rotate signing keys for the domain.

7. DKIM CNAME Records Added in Cloudflare

I added the required DKIM selector CNAME records in Cloudflare and confirmed that both records were present.

Context: DKIM selector records allow recipient mail systems to locate the public keys used to validate Microsoft 365 DKIM signatures.

8. DKIM Enabled for the Domain

I enabled DKIM signing for nietz.co.uk after the CNAME records were available in public DNS.

Context: Enabling DKIM improves outbound email trust and works alongside SPF and DMARC to help receiving mail systems verify messages from the domain.

9. DMARC Record Published

I added a DMARC TXT record for nietz.co.uk in Cloudflare using monitoring mode, so DMARC reporting could be introduced without immediately rejecting mail.

Context: DMARC helps domain owners monitor how receiving systems handle mail that fails SPF or DKIM checks. A monitoring policy is a safe first step before moving to stricter enforcement.

10. External Inbound Mail Received

I sent an external test message from Gmail to the Support shared mailbox and confirmed that Exchange Online delivered the message to [email protected].

Context: This validated that the public MX record routed external mail for nietz.co.uk into Exchange Online successfully.

11. External Outbound Mail Sent from Support

I sent an outbound test message from the Support shared mailbox to an external Gmail address.

Context: Outbound testing confirmed that the shared mailbox could send external mail through Exchange Online using the custom domain identity.

12. External Outbound Mail Received in Gmail

I confirmed that the external Gmail mailbox received the message sent from [email protected].

Context: This proved end-to-end outbound delivery from Exchange Online to an external recipient.

13. Message Trace Validation

I used Exchange Online message trace to confirm that the external inbound and outbound test messages were processed successfully.

Context: Message trace provides administrator-level evidence of mail flow status and is a common helpdesk and Microsoft 365 support tool for investigating delivery issues.

Validation

The lab was validated when Microsoft 365 confirmed the Exchange Online DNS records, Cloudflare showed the required MX, Autodiscover CNAME, SPF TXT, DKIM CNAME and DMARC TXT records, DKIM signing was enabled, and external mail successfully flowed into and out of the Support shared mailbox.

External inbound delivery was confirmed when the Support shared mailbox received a Gmail test message. External outbound delivery was confirmed when Gmail received a message sent from the Support shared mailbox. Exchange Online message trace confirmed the mail flow results from an administrator view.

Key Technical Outcomes

This lab demonstrated how public DNS controls Microsoft 365 mail routing and how Exchange Online depends on correctly published MX, CNAME and TXT records.

It also showed the relationship between SPF, DKIM and DMARC in Microsoft 365 mail authentication, and how message trace can validate delivery after DNS and mailbox configuration changes.