Microsoft 365 Mail Deliverability

Why it matters: Many small businesses run on Microsoft 365. Setting its DNS and authentication up correctly, then troubleshooting with evidence instead of guesses, saves hours of "why did my email go to spam?"

By the end you can:

• Plan the core DNS setup for a custom domain
• Merge Microsoft's SPF into a single policy
• Enable DKIM using tenant-generated values
• Investigate delivery problems systematically

Learn (15 min)

1. Domain and mail flow (5 min)

Verify the domain in the tenant, confirm accepted-domain settings, and publish the MX value the admin center shows for your domain. Always use the records the Microsoft 365 admin center generates for your tenant and domain. Don't copy sample values.

2. Authentication records (5 min)

• SPF: merge Microsoft's include into your single SPF record (typically include:spf.protection.outlook.com), preserving other senders.
• DKIM: in the Defender email-authentication settings (or Exchange Online PowerShell), publish the two CNAMEs Microsoft provides, then enable signing.
• DMARC: add after SPF/DKIM are in place for every sending source (Lesson 44). Validate with real test messages and read Authentication-Results.

3. Monitor deliverability (5 min)

Separate the possibilities: authentication failure, policy block, bounce/NDR, transport rule, reputation, recipient-side filtering. Evidence sources: message trace, NDR codes, spam/quarantine, headers, and recipient feedback. Change one thing at a time, record the previous value, allow for TTL, and retest. Authentication builds trust; it can't guarantee inbox placement. Large providers also publish bulk-sender expectations (authentication, low complaint rates, easy unsubscribe), so check their current requirements if you send volume.

Apply (15 min)

Worked example (3 min). Staff mail works, but a CRM campaign fails SPF and DMARC. Steps: inventory senders; check the one SPF record (is the CRM's include present?); check the CRM's DKIM d=; follow the CRM's custom-domain authentication guide (CNAMEs) and Microsoft's DKIM guide; send to a small internal list; read headers; only then widen sending.

Lab (7 min): Troubleshoot a bounce.

1. Take a (sanitized) NDR or "message trace" description: "550 5.7.x … sender not authenticated."
2. List three hypotheses and the evidence that confirms or eliminates each.
3. Choose the first change, its rollback, and what you'd retest.

Deliverable: A hypothesis table and a one-change plan. You're done when: Each hypothesis has a specific check.

Check yourself (5 min)

1. Where do you get the DKIM CNAME values?
2. Can Microsoft's SPF be added as a second SPF record?
3. What must be in place before DMARC enforcement?
4. Scenario: Email authenticates but lands in spam. What do you examine next?
5. Do SPF/DKIM/DMARC guarantee inbox delivery?

Reference

Common mistakes

Cheat sheet: Verify domain → inbound DNS → inventory senders → SPF merged → DKIM enabled → DMARC monitored → trace and headers.

Key terms: accepted domain, message trace, NDR, Authentication-Results, TTL.

Interview prompts: How do you isolate whether a delivery problem is authentication or reputation?

Go deeper: Microsoft 365 DNS records · SPF setup · DKIM setup · DMARC setup

Next: Lesson 46 — permission-based campaigns.