D
DMARC Creator

How to Set Up DMARC for Office 365: Step-by-Step Configuration Guide

Configure DMARC for Microsoft 365 and Office 365. Step-by-step setup guide covering DNS records, SPF and DKIM alignment, and policy enforcement.

Last updated: 2026-04-15

If your organization uses Microsoft 365 (formerly Office 365) for email, setting up DMARC is one of the most important steps you can take to protect your domain from spoofing and phishing attacks. Microsoft strongly recommends DMARC for all Exchange Online customers, and major mailbox providers like Google and Yahoo now require it for bulk senders. This guide walks you through the complete DMARC setup for Office 365, from prerequisites to full enforcement. For a broader overview of how DMARC fits into the Microsoft 365 ecosystem, see our DMARC for Microsoft 365 landing page.

How Microsoft 365 Handles Email Authentication

Exchange Online, the email service inside Microsoft 365, supports all three email authentication protocols: SPF, DKIM, and DMARC. Understanding how Microsoft handles each one is important before you configure DMARC for Office 365.

SPF is partially configured for you. When you add a custom domain to Microsoft 365 and route your email through Exchange Online, Microsoft asks you to publish an SPF record that includes spf.protection.outlook.com. This tells receiving servers that Microsoft's mail infrastructure is authorized to send on behalf of your domain.

DKIM requires manual activation. Microsoft 365 signs outgoing messages with a default Microsoft DKIM key, but this default signature uses a Microsoft domain, not yours. For DMARC alignment to work with DKIM, you need to enable custom DKIM signing in the Microsoft 365 Defender portal so that messages are signed with your own domain.

DMARC is a DNS record you publish yourself. Microsoft does not create it for you. Once SPF and DKIM are properly configured and aligned with your domain, your DMARC record tells receiving servers what to do with messages that fail authentication.

Prerequisites

Before you configure DMARC for Office 365, make sure the following are in place:

  • Custom domain verified in the Microsoft 365 admin center. Your domain must be added and verified at admin.microsoft.com. DMARC only applies to custom domains, not the default onmicrosoft.com domain.
  • Access to your DNS provider. You will need to add or edit TXT and CNAME records in your domain's DNS.
  • Admin access to Microsoft 365 Defender. DKIM configuration happens in the Defender portal at security.microsoft.com.

If you are still using the default yourcompany.onmicrosoft.com domain for sending email, DMARC setup does not apply. Switch to a custom domain first, then return to this guide.

Step-by-Step: Set Up DMARC for Office 365

1

Enable custom DKIM signing in Microsoft 365 Defender

Go to the Microsoft 365 Defender portal at security.microsoft.com. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Select your custom domain from the list. Microsoft will display two CNAME records you need to publish in your DNS. These records typically follow the pattern selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com, both pointing to Microsoft's DKIM key infrastructure. Add both CNAME records in your DNS provider, wait for propagation (usually a few minutes, up to 48 hours), then return to the Defender portal and toggle DKIM signing to Enabled. Microsoft will verify the CNAME records and begin signing outgoing messages with your domain. If you need to generate DKIM records for other services alongside Microsoft 365, use dkimcreator.com.

2

Verify your SPF record includes Microsoft 365

Check your current SPF record for your domain. It must include include:spf.protection.outlook.com to authorize Exchange Online as a legitimate sender. A basic SPF record for a domain that only sends through Microsoft 365 looks like this:

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

If you also send email through other services such as Mailchimp, Salesforce, or SendGrid, each of those services needs its own include statement in the same SPF record. You can build a complete SPF record at spfcreator.com. Make sure you have only one SPF record for your domain, as multiple SPF records will cause authentication failures.

3

Create your DMARC record

With DKIM and SPF in place, you are ready to publish a DMARC record. For Microsoft 365 users setting up DMARC for the first time, start with a monitoring-only policy:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

Add this as a TXT record in your DNS with the name _dmarc (the full hostname resolves to _dmarc.yourdomain.com). Replace the rua email address with one you control. This policy will not block any email but will start generating aggregate reports so you can see who is sending as your domain and whether authentication is passing.

4

Verify your DMARC record is live

After saving the DNS record, wait a few minutes for propagation and then verify it using dmarcrecordchecker.com. You should see your exact record returned with no errors. If the lookup does not return your record, double-check the record name and value in your DNS provider.

5

Monitor reports, then move to enforcement

Collect DMARC aggregate reports for at least two weeks at p=none. Review the reports to confirm that all legitimate email from Exchange Online and any third-party services is passing both SPF and DKIM. Once you are confident, move to p=quarantine (failing messages go to spam), and eventually to p=reject (failing messages are dropped entirely). A gradual rollout using the pct tag is recommended — start with pct=25, increase to pct=50, then pct=100 before switching to reject.

Create your DMARC record

Use our free DMARC generator to build a valid record for your domain.

Generate DMARC Record

SPF Alignment for Microsoft 365

SPF alignment means the domain in the Return-Path header matches the domain in the From header. When you send email directly through Exchange Online, Microsoft uses your custom domain in the Return-Path, so SPF alignment happens automatically as long as include:spf.protection.outlook.com is in your SPF record.

Where SPF alignment breaks down is when third-party services send email on your behalf. Marketing platforms, CRM tools, and transactional email providers often use their own Return-Path domain, which means SPF alone will not align with your From domain. This is why DKIM alignment is essential as a backup. For a deeper explanation, see DMARC alignment explained.

DKIM Alignment for Microsoft 365

DKIM alignment means the domain in the DKIM signature (d= tag) matches the From domain. By default, Microsoft 365 signs messages with a Microsoft-owned domain, which will not align with your custom domain. This is why Step 1 above — enabling custom DKIM signing in the Defender portal — is critical.

Once custom DKIM signing is enabled, Exchange Online signs every outgoing message with your domain in the d= tag. This gives you DKIM alignment even when SPF alignment fails, such as when an email is forwarded. To understand how SPF, DKIM, and DMARC work together, read SPF vs DKIM vs DMARC.

Do not skip enabling custom DKIM signing. The default Microsoft DKIM signature uses a Microsoft domain, not yours. Without custom DKIM, your DMARC alignment depends entirely on SPF, which breaks when emails are forwarded or sent through third-party services.

Common Issues With DMARC in Microsoft 365

Shared and multi-tenant environments. Organizations on shared Microsoft 365 tenants sometimes encounter DKIM issues because the default DKIM signing uses the tenant's domain rather than the custom domain. Always enable custom DKIM signing for each domain in your tenant.

Third-party senders alongside Exchange Online. If you use services like HubSpot, Mailchimp, or Salesforce to send email as your domain, each service needs its own SPF include and its own DKIM configuration. Missing even one service will produce DMARC failures in your reports. Audit every service that sends email on your behalf before moving to enforcement.

Hybrid Exchange setups. Organizations running a hybrid configuration with on-premises Exchange servers and Exchange Online need to make sure both environments are covered by SPF and DKIM. On-premises servers must be included in your SPF record, and their outgoing mail should route through Exchange Online or be signed with DKIM independently.

Forwarding and mailing lists. Email forwarding often breaks SPF because the forwarding server's IP is not in your SPF record. DKIM survives forwarding as long as the message body is not modified. This is another reason why enabling custom DKIM signing for your Microsoft 365 domain is essential.

If you are seeing unexpected DMARC failures in your reports, check whether the failing messages come from a legitimate service you forgot to authenticate. The most common fix is adding the missing SPF include or enabling DKIM for that service.

Recommended DMARC Record for Microsoft 365

For most Microsoft 365 organizations, the target DMARC record should be:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

A p=reject policy provides the strongest protection against domain spoofing. It tells receiving mail servers to drop any message from your domain that fails both SPF and DKIM alignment. Get there gradually — start at p=none, move to p=quarantine, and only switch to p=reject once your reports confirm that all legitimate email is passing. For more detail on each policy level, see DMARC policy levels.

Related Articles

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.

Never miss a DMARC issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring