Microsoft 365 email authentication, end to end

SPF, DKIM, and DMARC for a Microsoft 365 tenant, in the order that keeps mail flowing at every step. Each step below is the exact record to publish — replace the placeholders with your domain's own values, and don't skip the monitoring period before enforcing anything.

  1. 1Publish (or update) your SPF record

    SPF is a single TXT record at the root of your domain. If Microsoft 365 is your only sender, publish exactly the record below. If you already send mail through other platforms (a CRM, a marketing tool, a helpdesk), add include:spf.protection.outlook.com to your existing record instead of replacing it — SPF allows only one record per domain, and each include counts against the 10-lookup limit, so don't publish a second one.

    Host: yourdomain.com
    Type: TXT
    Value: v=spf1 include:spf.protection.outlook.com -all
  2. 2Enable DKIM signing and publish the two CNAME records

    In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, select your domain, and enable signing. Microsoft will show you two CNAME records to publish — the exact values are unique to your tenant and Microsoft updated the CNAME target format in May 2025, so copy them directly from the portal (or from Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME,Selector2CNAME in Exchange Online PowerShell) rather than reusing an example from elsewhere. The hosts follow this pattern:

    Host: selector1._domainkey.yourdomain.com
    Type: CNAME
    Value: <Selector1CNAME value shown in the Defender portal>
    Host: selector2._domainkey.yourdomain.com
    Type: CNAME
    Value: <Selector2CNAME value shown in the Defender portal>
  3. 3Publish a DMARC record in monitoring mode

    Publish DMARC at p=none first, regardless of how confident you are — this collects aggregate reports without affecting delivery, so you can confirm every legitimate sender (including any tools outside Microsoft 365) is passing before you enforce anything. Replace the rua= address with one you or your MSP actually monitors.

    Host: _dmarc.yourdomain.com
    Type: TXT
    Value: v=DMARC1; p=none; rua=mailto:[email protected]
  4. 4Review aggregate reports, then move to enforcement

    Give it one to two weeks of aggregate reports (most receivers send daily). Look for any sending source that isn't passing SPF or DKIM alignment — that's either a tool you forgot about or a spoofing attempt, and you want to know which before you enforce. Once every legitimate sender aligns, move the policy up one step at a time and re-confirm reports after each change: first replace p=none with p=quarantine and watch for anything legitimate landing in spam, then replace p=quarantine with p=reject once quarantine has run clean.

Verify it worked

Run the free domain checker against the domain you just configured — it reads DMARC, SPF, DKIM, and BIMI back exactly as receivers see them, no email required.

Run a free domain check

Common questions

Do I need to enable DKIM manually, or does Microsoft 365 do it by default?
Microsoft 365 signs mail with a default onmicrosoft.com selector automatically, but that doesn't align with your custom domain for DMARC purposes. You need to add your domain's CNAME records and enable signing in the Defender portal to get DKIM aligned with your actual sending domain.
What if I send mail through other tools besides Microsoft 365?
Add each tool's SPF include to your single existing SPF record (never publish a second SPF TXT record), and confirm each tool separately supports DKIM signing with your domain — some do, some only sign with their own domain, which means you'll rely on SPF alignment for those instead.
How long does DNS propagation take before I can move DMARC to enforcement?
DNS changes typically propagate within a few hours, but the actual gate on moving to enforcement isn't propagation — it's confirming via aggregate reports that every legitimate sender is aligning. That takes the one-to-two-week reporting window, not a technical propagation delay.

Managing this across a portfolio of client domains, not just one? That's what Trustliant is built for — every client's posture, scored and explained, under your brand.

See the MSP platform →