Easy DMARC Guide for Microsoft 365 Tenant

Why DMARC Matters for Your Microsoft 365 Tenant

Think of email authentication like a security guard at the front desk of a corporate building. SPF checks “Did this person come in on a company‑issued badge?” DKIM verifies “Is the envelope sealed with the company’s unique stamp?” DMARC is the manager who says, “If the badge is fake or the seal is broken, either reject the visitor, quarantine them, or let them in but report the incident.”

For a Microsoft 365 tenant, a solid DMARC policy protects:

• Brand reputation – prevents phishing emails that appear to come from your domain.
• Inbox deliverability – ISPs trust domains that publish DMARC, reducing spam folder placement.
• Visibility – DMARC reports give you a daily snapshot of who’s sending mail on your behalf.

Prerequisites Before You Start

Requirement	What to Do
Domain ownership	Verify the domain in the Microsoft 365 admin center (if not already done).
Access to DNS	You’ll need to edit TXT records at your DNS provider (or Azure DNS).
Basic SPF & DKIM	DMARC builds on these; make sure they’re already published and passing.
Reporting address	Create a dedicated mailbox (e.g., [email protected]) to receive aggregate reports.

Step‑by‑Step: Deploying DMARC on a Microsoft 365 Tenant

1. Confirm SPF Is Correct

1. Log into The Network Tools → DNS Lookup → SPF Checker.

2. Look for a record that resembles:

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

3. If you see extra IPs or third‑party services, add them using include: or ip4: mechanisms.

2. Enable DKIM for All Custom Domains

1. In the Microsoft 365 admin center, go to Settings > Domains and select your domain.

2. Click DNS records → locate the two CNAME records for DKIM (selector1._domainkey and selector2._domainkey).

3. If they’re missing, create them:

   selector1._domainkey   CNAME   selector1‑yourdomain‑domainkey.microsoft.com
   selector2._domainkey   CNAME   selector2‑yourdomain‑domainkey.microsoft.com
   

4. Back in Exchange admin center, enable DKIM for the domain.

3. Publish the DMARC TXT Record

a. Choose a Policy

Policy	Effect
p=none	Collect data, no enforcement (good for the first 30 days).
p=quarantine	Mark non‑compliant mail as spam.
p=reject	Block non‑compliant mail outright.

b. Build the Record

A starter record for monitoring only:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=none; fo=1

• rua = aggregate reports (XML, sent daily).
• ruf = forensic reports (optional, may contain original message).
• sp = sub‑domain policy (inherit parent).
• fo=1 = generate a report if either SPF or DKIM fails.

c. Add the TXT Record

1. Open your DNS zone editor.
2. Create a TXT record with the name _dmarc.
3. Paste the string from step b.

4. Verify the Record

Use The Network Tools → DMARC Lookup to confirm:

• The record is visible.
• Syntax is correct (no stray spaces).

5. Monitor and Tweak

1. Wait 24‑48 hours for the first aggregate report.

2. Review the report in a DMARC analyzer (many free online tools exist).

3. Look for:

   • Legitimate sources not covered by SPF/DKIM (e.g., a marketing platform).
   • Spoofing attempts from unknown IPs.

4. Add missing sources to SPF or configure DKIM for them.

5. After 2‑3 weeks of clean data, move from p=none to p=quarantine.

6. When you’re confident, switch to p=reject.

Real‑World Example: From “None” to “Reject”

Company: Contoso Ltd.
Domain: contoso.com

Day	DMARC Policy	Action
1	p=none	Collected 1,200 legitimate messages, 15 spoof attempts.
10	p=quarantine	Quarantined 12 spoofed messages; no impact on legitimate mail.
25	p=reject	Rejected 9 remaining spoofed messages; inbox placement improved 4 %.

During the transition, Contoso used The Network Tools to run daily DKIM and SPF checks, ensuring no accidental breakage when new services (e.g., a new CRM) were added.

Common Pitfalls & How to Avoid Them

Pitfall	Symptom	Fix
Missing sub‑domain record	Spoofed mail from mail.sales.contoso.com still lands in inbox.	Add sp=reject or create a separate DMARC record for the sub‑domain.
Too strict SPF	Legitimate third‑party service gets rejected.	Use include: for the service’s SPF or switch to ~all (soft fail) during testing.
Forensic reports flooding inbox	Hundreds of ruf emails per day.	Remove ruf or set fo=0 until you need detailed debugging.
Incorrect DNS TTL	Changes take days to propagate.	Set TTL to 300 seconds while testing, then raise to 1 hour for production.

Automating Ongoing Checks with The Network Tools

• Scheduled DNS health checks: Set up a daily job that pings your SPF, DKIM, and DMARC records.
• Alerting: Receive an email if any record disappears or deviates from the expected pattern.
• API integration: Pull DMARC aggregate data into your SIEM for correlation with other security events.

These features let you treat email authentication like a living system—regularly inspected, patched, and tuned.

Quick Reference Cheat Sheet

# SPF (Microsoft 365)
v=spf1 include:spf.protection.outlook.com -all

# DKIM (CNAME)
selector1._domainkey   CNAME   selector1-yourdomain-domainkey.microsoft.com
selector2._domainkey   CNAME   selector2-yourdomain-domainkey.microsoft.com

# DMARC (TXT)
_dmarc   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=none; fo=1"

Tip: Keep the p=none policy for at least 14 days before moving to quarantine.

Final Thoughts

Implementing DMARC on a Microsoft 365 tenant isn’t a one‑time checkbox; it’s a continuous cycle of measure → adjust → enforce. By starting with a monitoring policy, using reliable tools like The Network Tools for validation, and gradually tightening enforcement, you protect your brand, improve deliverability, and gain actionable insight into who’s trying to speak on your behalf.

Ready to lock down your email? Grab your DNS console, follow the steps above, and let the data guide you to a p=reject policy that works for real‑world traffic. Your inbox (and your customers) will thank you.