Configure DMARC with SPF and DKIM in Microsoft 365 without blocking legitimate mail

DMARC protects the domain, not just the mailbox

A DMARC policy tells receiving systems what to do when a message using your domain in the visible From address lacks aligned authentication. It makes domain impersonation much less effective, but a strict policy published before discovery can also quarantine or reject legitimate invoices, alerts, web forms and campaigns.

The safe sequence is straightforward: find every source, fix SPF, enable DKIM for each sending domain, publish DMARC in monitoring mode, resolve gaps and then enforce. The end state is p=reject, not p=none forever.

• Microsoft — Configure DMARC in Microsoft 365 ↗
• Related guide — SMTP AUTH Basic retirement →

Understand SPF, DKIM and DMARC alignment

A message does not need both SPF and DKIM to pass DMARC; one passing, aligned mechanism is enough. Relaxed alignment, the default, can align a subdomain sharing the same organizational domain. Strict alignment requires an exact match and should be used only when every flow supports it.

This is why adding a vendor IP to SPF does not always fix DMARC. If its Return-Path uses the vendor domain, SPF can pass without alignment; a DKIM signature using your domain is then the better path.

• RFC 7489 — DMARC ↗

1. Inventory every source before touching p=reject

Do not stop at Exchange Online mailboxes. Find printers, business applications, monitoring systems, websites, CRM, HR, ticketing, marketing, signature vendors, local relays and cloud platforms that use the domain in From.

For each source, record From domain, MAIL FROM, DKIM signature, source IP, owner, volume and test case. An ownerless flow should not delay the project forever: isolate it, confirm its need and decide whether to fix or retire it.

Connect-ExchangeOnline
Get-AcceptedDomain | Select-Object DomainName,DomainType,Default | Sort-Object DomainName
Get-DkimSigningConfig | Select-Object Domain,Enabled,Status,Selector1CNAME,Selector2CNAME
Get-OutboundConnector | Select-Object Name,Enabled,RecipientDomains,SmartHosts,TlsSettings
Get-InboundConnector | Select-Object Name,Enabled,SenderDomains,SenderIPAddresses,ConnectorType

2. Build one readable, complete SPF record

A domain must publish one SPF TXT record. When Exchange Online is the only source, the usual baseline is v=spf1 include:spf.protection.outlook.com -all. Add only authorized sources and merge mechanisms into that record; publishing two SPF records causes a permanent error.

SPF allows at most ten DNS lookups during evaluation. An include can trigger several lookups itself. Do not paste a long list of includes without evaluating the full path, and do not mechanically change ~all to -all before testing every sender.

# Microsoft 365 only
@  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# Domain that must never send mail
@  TXT  "v=spf1 -all"

• Microsoft — Configure SPF for a custom domain ↗

3. Enable DKIM for every Microsoft 365 sending domain

Microsoft 365 signs the initial onmicrosoft.com domain automatically, but custom domains require configuration. Retrieve both CNAME values from the Defender portal or Exchange Online PowerShell. Do not construct targets from an old example because Microsoft also uses a dynamic format for newer domains.

Publish selector1 and selector2 in DNS, wait for resolution, then enable signing. One selector signs while the other supports rotation. Send a message to an external system and confirm that d= matches From and Authentication-Results reports dkim=pass.

$domain = 'contoso.com'
$config = Get-DkimSigningConfig -Identity $domain -ErrorAction SilentlyContinue
if (-not $config) { New-DkimSigningConfig -DomainName $domain -Enabled $false }
Get-DkimSigningConfig -Identity $domain |
  Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
# After both CNAME records resolve
Set-DkimSigningConfig -Identity $domain -Enabled $true
# Planned key rotation
Rotate-DkimSigningConfig -Identity $domain -KeySize 2048

• Microsoft — Configure DKIM in Microsoft 365 ↗

4. Give external senders a subdomain

A marketing platform or SaaS application outside your control should not use the main domain when a subdomain is possible. marketing.contoso.com or notifications.contoso.com separates reputation, simplifies SPF and supports a dedicated DMARC policy.

Ask the provider for a custom Return-Path and a DKIM signature using the subdomain. Publish only keys and mechanisms documented by that provider. Main-domain SPF alone often leaves alignment dependent on something the customer does not control.

• One subdomain and owner per major sending platform.
• DKIM d= aligned with From.
• Custom Return-Path where supported.
• No DNS delegation broader than necessary.
• Retirement procedure when the contract ends.

5. Start DMARC in monitoring mode

Publish a TXT record at _dmarc.contoso.com with p=none and a rua address that can receive aggregate XML reports. Use a dedicated mailbox or service because a personal mailbox quickly becomes unusable. Reports show observed IPs, volumes, SPF and DKIM results, and alignment.

p=none does not prevent a recipient from applying its own filters. It only states the DMARC policy requested by the domain owner. Keep monitoring long enough to cover monthly sends, but assign an owner and an exit date.

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r; fo=1"

6. Read reports and fix gaps

The goal is not a 100 percent pass rate achieved by authorizing everything in a report. Separate legitimate senders, obsolete services and impersonation attempts. Inspect representative message headers because aggregate reports do not explain the complete path.

7. Move gradually to quarantine and reject

When important legitimate sources pass DMARC, apply p=quarantine to a limited percentage, raise pct in stages and then move to p=reject. Start with a lower-risk domain or subdomain. Monitor reports, complaints and test mail at every step.

A common final policy uses p=reject and sp=reject for undefined subdomains. Keep relaxed alignment unless a stricter requirement is proven. pct is a request to the receiving system and implementation can vary; it helps with rollout but does not replace testing.

# Step 1 — monitoring
v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com
# Step 2 — limited quarantine
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@contoso.com
# Step 3 — full protection
v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r

8. Protect domains that do not send mail

Domains registered to protect a brand but never used for email should state that intent. Publish SPF -all and DMARC p=reject, and do not publish DKIM keys. Protect unused subdomains with sp=reject on the parent where the architecture permits.

Include secondary domains accepted in Microsoft 365. A domain without active mailboxes can still be convincing in phishing when it resembles the brand.

@       TXT  "v=spf1 -all"
_dmarc  TXT  "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@contoso.com"

Production checklist

DMARC is not just a DNS record to copy. It is a mail inventory and governance project. When vendors are separated, aligned DKIM is required and reports drive decisions, p=reject becomes predictable protection instead of a bet on delivery.

• Every From domain and sending source has an owner.
• Each domain has one SPF record and stays below ten DNS lookups.
• DKIM is enabled and aligned for Microsoft 365 and external vendors.
• Subdomains separate third-party senders from the main domain.
• rua reports are received, analyzed and retained under a clear policy.
• Known failures have a decision: fix, retire or temporarily accept.
• The none, quarantine and reject stages have exit criteria.
• Non-sending domains publish SPF -all and DMARC reject.
• An external test confirms SPF, DKIM, DMARC and alignment after each change.

• Service — Microsoft 365 and Entra ID security assessment →
• Related guide — Token theft and AiTM attacks →