Microsoft 365 protects mailboxes from many inbound threats, but it does not automatically stop criminals from impersonating your custom domain elsewhere on the internet.

To protect your domain properly, you need three technologies working together:

The difficult part is not publishing a DMARC record. The difficult part is identifying every legitimate sender first, correcting alignment problems, and moving safely to enforcement without blocking invoices, support tickets, marketing campaigns, or other valid mail.

This guide explains how to do that for a custom domain using Microsoft 365.

Before You Start: Inventory Every Service That Sends Email

Microsoft 365 may be your main email platform, but it is rarely your only sender. Your domain might also appear in messages sent by:

If you enable p=reject before accounting for these services, legitimate messages can fail DMARC and be rejected.

Create a sender inventory containing the service name, sending domain, sending IP addresses, Return-Path domain, DKIM signing domain, owner, and business purpose. DMARC aggregate reports will help you find sources you missed.

Step 1: Verify Your Microsoft 365 SPF Record

SPF is published as a TXT record at the root of your domain. For a domain that sends only through Microsoft 365, the standard record is usually:

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

Do not copy this record blindly if other platforms send email for your domain. Those services may also need authorization.

Important SPF rules

  1. Publish only one SPF record per hostname. If two SPF TXT records exist, SPF can return a permanent error. Combine authorized sources into one record.

  2. Stay within the ten DNS-lookup limit. Too many nested include, a, mx, redirect, and exists mechanisms can cause SPF to fail.

  3. Do not authorize more senders than necessary. Broad IP ranges and obsolete services increase exposure.

  4. Remember that SPF alone is not enough. Forwarding commonly breaks SPF, and an SPF pass only helps DMARC when the authenticated MAIL FROM domain aligns with the visible From domain.

Use SpoofWard's SPF Checker to inspect your current record, then remove stale sources only after confirming they are no longer used.

Step 2: Enable DKIM for Your Custom Domain

Microsoft 365 initially signs outgoing mail using the tenant's onmicrosoft.com domain. That signature can be valid while still failing DMARC alignment for messages sent from your custom domain. Enable DKIM signing for every custom domain that sends mail.

In the Microsoft Defender portal, open the DKIM settings for your domain. Microsoft provides two CNAME records, normally using these hostnames:

selector1._domainkey.example.com
selector2._domainkey.example.com

The exact target values are unique to your Microsoft 365 tenant. Copy the values Microsoft provides; do not construct or guess them.

Add both CNAME records through your DNS provider, allow time for DNS propagation, and then enable DKIM signing in Microsoft 365. Send a test message to an external mailbox and inspect its headers. Confirm that:

Having two selectors allows Microsoft to rotate keys without interrupting signing.

Step 3: Create a DMARC Monitoring Record

DMARC is a TXT record published at:

_dmarc.example.com

Begin with monitoring mode:

v=DMARC1; p=none; rua=mailto:YOUR-SPOOFWARD-REPORT-ADDRESS; adkim=r; aspf=r

Replace the report address with the unique aggregate-reporting address assigned to your domain in SpoofWard.

What the tags mean:

Tag Purpose
v=DMARC1 Declares the DMARC protocol version
p=none Monitors failures without requesting quarantine or rejection
rua= Sends aggregate reports to the specified destination
adkim=r Uses relaxed DKIM alignment
aspf=r Uses relaxed SPF alignment

Relaxed alignment is appropriate for most organizations because it permits aligned subdomains. Strict alignment should be used only when your sending architecture requires it and has been tested carefully.

Microsoft notes that DMARC records for custom domains are managed at your DNS host or registrar, not through a Microsoft 365 portal or PowerShell command.

After publishing the record, verify it with SpoofWard's DMARC Checker. DNS changes may require time to propagate.

Step 4: Read the Reports Before Changing the Policy

A mailbox full of compressed XML files is not a practical monitoring system. DMARC aggregate reports contain useful evidence, but they must be normalized and grouped to answer questions such as:

SpoofWard converts those reports into understandable sending sources, authentication results, trends, and alerts.

Do not judge a source only by its IP address. Cloud services use large and changing address ranges. Identify the service, confirm its business owner, and examine its SPF and DKIM alignment.

Step 5: Fix Legitimate DMARC Failures

A message passes DMARC when at least one of these paths succeeds:

  1. SPF passes and its MAIL FROM domain aligns with the visible From domain.

  2. DKIM passes and its signing domain aligns with the visible From domain.

DMARC fails only when neither path succeeds and aligns.

Common failure: a third-party sender uses its own Return-Path

A platform may pass SPF using its own bounce domain, but that domain does not align with yours. The preferred fixes are to configure a custom Return-Path using your domain or enable custom DKIM signing with your domain.

Common failure: DKIM passes for the wrong domain

The vendor signs the message, but its d= value belongs to the vendor. Configure the service to sign with your domain or a dedicated subdomain.

Common failure: forwarding breaks SPF

Forwarding changes the delivery path and often invalidates SPF. DKIM can preserve DMARC authentication if the forwarded message is not modified. ARC can also preserve authentication context through trusted intermediaries.

Common failure: website or device sends directly

A website, printer, or application may send without aligned authentication. Route it through an approved relay, configure authenticated submission, or give it a properly secured subdomain rather than weakening your main domain's policy.

Common failure: an old service is still active

Do not immediately authorize it. Confirm whether the source is legitimate and still required. An unknown sender may be unauthorized infrastructure or active abuse.

Step 6: Move Gradually to Quarantine

Once all known legitimate sources authenticate correctly, change the policy in stages. For example:

v=DMARC1; p=quarantine; pct=10; rua=mailto:YOUR-SPOOFWARD-REPORT-ADDRESS; adkim=r; aspf=r

The pct=10 tag requests that receivers apply quarantine to 10% of messages that fail DMARC. Continue reviewing reports, then increase the percentage gradually:

10% → 25% → 50% → 75% → 100%

There is no universal number of days to remain at each stage. Advance when your reports show that legitimate streams pass DMARC consistently and failures are understood. High-volume or complex domains usually need a longer observation period.

At full quarantine, the record could be:

v=DMARC1; p=quarantine; pct=100; rua=mailto:YOUR-SPOOFWARD-REPORT-ADDRESS; adkim=r; aspf=r

Step 7: Reach p=reject

The final objective for an active domain is normally:

v=DMARC1; p=reject; pct=100; rua=mailto:YOUR-SPOOFWARD-REPORT-ADDRESS; adkim=r; aspf=r

This asks receiving systems to reject messages that use your domain but fail DMARC. It provides the strongest protection against direct domain spoofing.

Reaching p=reject does not mean the work is finished. New vendors, configuration changes, expired services, broken DKIM keys, and unauthorized senders can appear later. Continue monitoring reports and investigate changes promptly.

Protect Subdomains and Parked Domains

A parent DMARC policy generally applies to subdomains that do not publish their own DMARC record. You can also specify a separate subdomain policy with sp=.

For example:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:YOUR-SPOOFWARD-REPORT-ADDRESS

Third-party services should preferably send from dedicated subdomains such as news.example.com or billing.example.com. This isolates their authentication and reputation from employee mail on the main domain.

For a parked domain that must never send email, use restrictive records such as:

v=spf1 -all

and:

v=DMARC1; p=reject

Do not configure DKIM for a domain that never sends mail.

Microsoft 365 DMARC Checklist

Frequently Asked Questions

Does Microsoft 365 automatically configure DMARC?

No. Microsoft provides email-authentication capabilities, but you must publish the DMARC TXT record for each custom domain through your DNS provider. You must also enable DKIM signing for custom domains and ensure that every legitimate sender aligns.

Can DMARC block legitimate Microsoft 365 email?

Yes, if SPF and DKIM are missing, broken, or not aligned—or if a third-party service has not been configured correctly. This is why a monitored, gradual rollout is safer than moving directly to p=reject.

Is p=none enough to stop spoofing?

No. It collects visibility but does not ask receivers to quarantine or reject failing mail. Treat it as a discovery stage, not the final security posture.

Do I need both SPF and DKIM for DMARC?

DMARC technically passes when either an aligned SPF result or an aligned DKIM result succeeds. In practice, configure both. DKIM is especially important when forwarding breaks SPF.

Should I add ruf forensic reporting?

Forensic reporting has limited and inconsistent support, and reports can contain sensitive message information. Aggregate rua reporting is the essential starting point. Microsoft 365 itself does not send DMARC forensic reports even when an ruf address is present.

How long does DMARC setup take?

Publishing records can take minutes, but safe enforcement takes longer. The timeline depends on your mail volume, number of third-party services, reporting coverage, and how quickly authentication failures can be corrected.

Make Microsoft 365 DMARC Manageable

DMARC should not be a one-time DNS change. It is a controlled process: discover senders, fix authentication, enforce policy, and watch for changes.

SpoofWard turns complex DMARC XML into clear sender intelligence, highlights authentication failures, and helps you move toward enforcement without guessing.

Start your 14-day SpoofWard trial and see who is sending email using your domain.