Email Authentication Setup for Microsoft 365: SPF, DKIM, and DMARC

Microsoft 365 handles some email authentication automatically. But not all of it — and the parts it leaves for you to configure are precisely the ones that matter most for security.

This guide covers the exact steps to set up SPF, DKIM, and DMARC for a Microsoft 365 domain. It focuses on what Microsoft 365 does and doesn't do automatically, so you don't spend time reconfiguring things that are already handled.

What Microsoft 365 Handles Automatically

When you verify your domain in Microsoft 365 and configure your MX records, Microsoft automatically creates a basic SPF record for your domain. You'll see something like this in your DNS:

v=spf1 include:spf.protection.outlook.com -all

This covers email sent directly through Microsoft 365. It does not cover third-party tools that send email on your domain's behalf — marketing platforms, CRMs, billing systems, and so on. Those need to be added manually.

DKIM is not enabled automatically. Microsoft generates the DKIM signing keys for your domain, but you have to activate signing yourself in the Admin Center. This is the most commonly missed step in Microsoft 365 authentication setup.

DMARC is not created automatically. You add it yourself as a DNS TXT record.

Step 1: Set Up SPF for Microsoft 365

Check Your Current SPF Record

Before making changes, check whether an SPF record already exists for your domain. Having two SPF records causes both to become invalid — SPF only supports one TXT record per domain.

Use a free SPF checker to look up your current record. If one already exists, you'll edit it rather than create a new one.

The Base Microsoft 365 SPF Record

v=spf1 include:spf.protection.outlook.com -all

If you only send email through Microsoft 365, this is sufficient. Add it as a TXT record at your root domain (@ or your domain name, depending on your DNS provider).

Adding Third-Party Senders

If you send email from tools like Mailchimp, HubSpot, Salesforce, or SendGrid, each needs its own include: statement in the SPF record. For example:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.hubspot.com -all

SPF has a hard limit of 10 DNS lookups. Each include: statement uses lookups. If you add many tools, you may approach this limit. See the guide on adding third-party senders to your SPF record for how to manage this.

SPF Record Endings

• -all (hard fail) — recommended; servers not in the list fail SPF definitively
• ~all (soft fail) — servers not in the list fail softly; mail is typically delivered but marked
• ?all (neutral) — not recommended; provides no enforcement signal

Step 2: Enable DKIM for Microsoft 365

This step catches many Microsoft 365 administrators off guard. DKIM keys are created automatically, but signing is not activated. You must turn it on.

Enable DKIM Signing in the Admin Center

1. Go to the Microsoft 365 Defender portal at security.microsoft.com
2. Navigate to Email & Collaboration → Policies & Rules → Threat Policies
3. Under Rules, select Email Authentication Settings
4. Click on DKIM
5. Select your domain from the list
6. Toggle Sign messages for this domain with DKIM signatures to Enabled

If DKIM is not yet configured, you'll see a message that CNAME records need to be published to DNS first.

Publish the DKIM CNAME Records

Microsoft provides two CNAME records to add to your DNS. They look like this:

The exact values are shown in the Defender portal. Copy them from there — don't try to construct them manually.

After adding the CNAME records, wait 24–48 hours for DNS propagation, then return to the Defender portal and enable signing.

Verify DKIM Is Working

Send a test email to a Gmail address and view the full message headers (in Gmail: three-dot menu → Show original). Look for:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; ...

If you see this, DKIM is signing outbound mail correctly.

Step 3: Set Up DMARC for Microsoft 365

DMARC is a DNS TXT record you add to your domain — it's not configured inside Microsoft 365 at all.

Create the DMARC TXT Record

Replace dmarc@yourdomain.com with a real inbox you monitor. This is where aggregate reports will be delivered.

Start with p=none

Always start at p=none. This is monitor mode — email delivery is unaffected, and you receive daily reports on who is sending email from your domain.

After reviewing reports for 2–4 weeks and confirming all legitimate senders pass authentication, progress to p=quarantine, then p=reject.

For the full explanation of DMARC policy progression and when to move to enforcement, see DMARC policy: none vs quarantine vs reject.

Verification: Confirm All Three Are Working

After setup, run a full authentication check to confirm each record is correctly configured. A free Full Audit at EmailAudit.io checks SPF, DKIM, and DMARC simultaneously and shows the results with business-context explanations.

You can also check manually:

• SPF: DNS TXT lookup at your root domain — confirm the record includes spf.protection.outlook.com
• DKIM: Send a test email and inspect headers for DKIM-Signature
• DMARC: DNS TXT lookup at _dmarc.yourdomain.com — confirm the record exists and shows p=none (or your current policy)

Common Microsoft 365 Mistakes

Not activating DKIM signing. The most frequently missed step. Keys exist but signing is off by default. Check the Defender portal.

Creating a second SPF record. If an SPF record already exists (from a previous configuration), adding a new one invalidates both. Edit the existing record.

Adding too many include: statements. Each one costs DNS lookups. Cross the 10-lookup limit and your entire SPF record becomes invalid. Monitor your lookup count when adding new tools.

Setting DMARC to p=reject immediately. Without the monitoring phase, you're enforcing blind. Use the phased approach.

Using the wrong host for the DMARC record. It must go at _dmarc.yourdomain.com, not at the root domain.

Comparison: Microsoft 365 vs Google Workspace Setup

The DMARC record format is identical between platforms. The differences are in SPF include strings and where to enable DKIM:

• SPF: Microsoft 365 uses include:spf.protection.outlook.com; Google Workspace uses include:_spf.google.com
• DKIM: Microsoft 365 activates in the Defender portal using CNAME records; Google Workspace activates in the Google Admin Console using a TXT record

See the Google Workspace DMARC setup guide if you're setting up or comparing the two platforms.

For a complete pre- and post-migration checklist, see the email migration checklist.

Get a free Full Audit PDF — verify your Microsoft 365 authentication is configured correctly at EmailAudit.io

Checks SPF, DKIM, and DMARC simultaneously. Results in seconds. No account required.