Why Microsoft 365 Users Need DMARC

Microsoft 365 (formerly Office 365) is one of the most widely deployed email platforms in the world. When you add a custom domain to M365, Microsoft automatically creates certain DNS entries for autodiscover and mail routing — but SPF and DKIM are not configured for custom domains automatically. You must enable them manually.

More critically, even a perfectly functioning SPF and DKIM setup provides no protection against spoofing without DMARC. SPF and DKIM are authentication mechanisms; DMARC is the policy that tells receiving mail servers what to do when those checks fail. Without DMARC, a bad actor can send email claiming to come from your domain, and most mail servers will accept it.

The stakes have increased significantly in recent years. Google and Yahoo now require DMARC for bulk senders — organizations sending 5,000 or more messages per day to Gmail or Yahoo addresses must have a DMARC record in place, or their email risks being rejected or junked. Even below that threshold, the absence of DMARC leaves your domain open to phishing campaigns that damage your brand reputation and erode recipient trust.

Key point: Microsoft 365 gives you the infrastructure to authenticate email — but publishing the SPF record, enabling DKIM, and adding a DMARC record are steps you need to take yourself. This guide covers all three in order.

Step 1: Verify Your SPF Record for Microsoft 365

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are authorized to send email on behalf of your domain. For Microsoft 365, the SPF record you need to publish is:

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

This record authorizes all IP ranges used by Exchange Online Protection to send on your behalf. The -all qualifier at the end is a hard fail, instructing receiving servers to reject mail from sources not listed in your SPF record.

Important: do not create duplicate SPF records

A DNS zone can only have one SPF TXT record per domain name. If you already have an SPF record — for example from a previous email provider or marketing platform — you must merge the include:spf.protection.outlook.com mechanism into the existing record rather than publishing a second one. Two SPF records on the same name will cause a permanent SPF failure.

For example, if you were also using Mailchimp, the combined record would look like:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
SPF lookup limit: SPF has a limit of 10 DNS lookups per evaluation. Each include: mechanism counts as one lookup, and nested lookups within those mechanisms also count. If you have many sending services, you may need to flatten your SPF record or use a tool to check whether you are approaching the limit.

After publishing your SPF record, use the free SPF Checker to confirm the record resolves correctly and passes a syntax check for your domain.

Step 2: Enable and Configure DKIM in Microsoft 365

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. When a receiving server verifies the signature against the public key published in your DNS, it confirms the message was not altered in transit and genuinely originated from an authorized source.

Microsoft 365 signs outgoing email with DKIM by default using a Microsoft-owned domain (onmicrosoft.com). However, for DMARC alignment, your DKIM signature must match your custom domain — not the Microsoft subdomain. You need to enable custom domain DKIM signing explicitly.

How to enable DKIM for your custom domain in M365

  1. Go to the Microsoft Defender portal at security.microsoft.com.
  2. Navigate to Email & Collaboration → Policies & Rules → Threat Policies → DKIM.
  3. Select your custom domain from the list.
  4. Microsoft will display two CNAME records you need to publish in your DNS. They follow this format: 
    selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.youronmicrosoftdomain.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.youronmicrosoftdomain.onmicrosoft.com
  5. Publish both CNAME records in your DNS provider. DNS propagation can take up to 48 hours, though it is usually much faster.
  6. Return to the Defender portal and toggle DKIM signing to Enabled for your domain.

Microsoft uses two selectors — selector1._domainkey and selector2._domainkey — to support seamless key rotation. When Microsoft rotates your DKIM keys, it switches between selectors automatically without any action required from you.

After enabling DKIM and allowing time for DNS propagation, use the DKIM Checker to verify that both selectors resolve and return valid public keys.

Step 3: Publish Your DMARC Record

With SPF and DKIM in place, you are ready to publish a DMARC record. DMARC ties everything together: it defines the policy for what happens when authentication fails, and it tells receiving servers where to send aggregate and forensic reports about your domain's email traffic.

Start with a monitoring policy. This lets you observe real-world authentication results without affecting mail delivery while you identify all your legitimate sending sources:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com

Publish this as a DNS TXT record with the following settings:

  • Name / Host: _dmarc (your DNS provider may require the full name: _dmarc.yourdomain.com)
  • Type: TXT
  • Value: the DMARC record string above
  • TTL: 3600 (1 hour) is a reasonable starting point

Replace dmarc@yourdomain.com with the actual address where you want to receive DMARC reports. This can be any mailbox you control — or, better, an address that feeds into a DMARC reporting tool.

Use the free DMARC Generator to build your record with the correct syntax without manual editing. Once published, verify it with the DMARC Checker to confirm the record is resolving as expected.

Step 4: Monitor Your DMARC Reports

Once your DMARC record is live with a rua address, receiving mail servers will begin sending aggregate reports (XML files) to that address. These reports are your window into how your domain is being used — and abused.

What aggregate reports (rua) show you

Aggregate reports contain per-IP, per-sending-source breakdowns of authentication results. For each source, you will see how many messages were sent, whether SPF passed or failed, whether DKIM passed or failed, and whether DMARC alignment was achieved. Reports are typically sent once every 24 hours per receiving domain.

What forensic reports (ruf) show you

Forensic reports (also called failure reports) are generated per-message when authentication fails. They contain redacted copies of the failing messages, including headers. Not all providers send forensic reports, and some only send them under specific conditions.

Common Microsoft 365 sources you will see in reports

When you first start receiving DMARC reports for an M365-hosted domain, expect to see traffic from:

  • Exchange Online Protection (EOP) — Microsoft's own sending infrastructure. These should pass SPF and DKIM once configured correctly.
  • Third-party connectors — any external service integrated into your M365 environment via smart host or connector configuration.
  • Marketing platforms — tools like HubSpot, Mailchimp, or Salesforce that send on your domain's behalf and may need their own SPF includes or DKIM keys added.
  • Automated forwarding — forwarded messages often break SPF alignment and may appear as failures even when they originate from legitimate sources.

Parse your DMARC reports automatically

DMARC aggregate reports arrive as raw XML attachments — not exactly easy reading. DMARCFlow automatically collects, parses, and visualizes your reports so you can see exactly which sources are passing or failing authentication, without opening a single XML file.

Start reading your DMARC reports free

No credit card required. Full reporting dashboard from day one.

Step 5: Move to Enforcement

Starting with p=none is the right approach — it lets you collect data without risk. But the goal is always enforcement: a policy of p=quarantine or p=reject that actively protects your domain from spoofing.

When to move from p=none to p=quarantine

You are ready to move to p=quarantine when your DMARC reports consistently show that the vast majority of legitimate mail is passing authentication. Look for:

  • A high pass rate (ideally 95%+) across all your known sending sources
  • All major sending services — Exchange Online, marketing tools, transactional email — appearing in reports with passing results
  • No legitimate sending sources that are still failing authentication

With p=quarantine, failing messages are delivered to the spam/junk folder rather than the inbox. This is a meaningful enforcement step that protects recipients while giving you a safety net in case a legitimate sender is still misconfigured.

When to move from p=quarantine to p=reject

Once you have been at p=quarantine for several weeks and your reports show no legitimate senders failing, you can move to p=reject. At this level, mail that fails DMARC is rejected outright at the receiving server — it never reaches the inbox or spam folder.

Watch for forwarding issues: Email forwarding is the most common source of false DMARC failures at enforcement. When a message is forwarded, the original SPF record no longer matches the forwarding server's IP, and DKIM may be broken if the forwarder modifies the message. Check your reports carefully for forwarding traffic before moving to p=reject.

Update your DMARC record progressively. You can also use the pct tag to apply the policy to a percentage of failing messages — for example, pct=25 applies the quarantine or reject action to only 25% of failing messages, letting you ramp up gradually:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com

Microsoft 365 DMARC Checklist

Use this checklist to confirm your M365 DMARC setup is complete:

  1. SPF record published — contains include:spf.protection.outlook.com and no duplicate TXT records on the same name
  2. SPF verified — confirmed passing via the SPF Checker
  3. DKIM enabled in Microsoft Defender portal — toggle is set to Enabled for your custom domain
  4. Both DKIM CNAME records published — selector1._domainkey and selector2._domainkey resolving correctly
  5. DKIM verified — both selectors confirmed via the DKIM Checker
  6. DMARC record published — TXT record at _dmarc.yourdomain.com with p=none and a valid rua address
  7. DMARC verified — confirmed via the DMARC Checker
  8. Reports flowing — aggregate reports arriving at your designated reporting address or DMARC tool
  9. All sending sources identified — Exchange Online, marketing tools, connectors all visible in reports with passing results
  10. Policy moved to enforcement — p=quarantine or p=reject once reports confirm clean pass rates

Getting DMARC right in Microsoft 365 is a methodical process, but each step builds on the last. Once you reach enforcement, your domain is protected against spoofing, you meet the requirements set by Google and Yahoo for bulk sending, and you have laid the groundwork for further email security improvements — including BIMI logo display in Gmail and Yahoo Mail.