Microsoft 365 DMARC for CMMC Level 2

A spoofed message can undo months of security work in one click. That is why I treat Microsoft 365 DMARC setup as a core security task, not a mail admin extra.

If you handle CUI, vendor approvals, invoices, or support requests in Microsoft 365, your domain is a target. The good news is that SPF, DKIM, and DMARC are practical controls, and they are far easier to manage when I phase them in with clear DNS records and clean evidence.

Why authenticated email matters for CMMC Level 2

Email spoofing is still one of the cheapest attacks to launch. An attacker does not need your mailbox if they can send a message that looks like it came from your domain. When that fake message reaches a supplier, a project lead, or a finance user, trust does the rest.

CMMC Level 2 does not give me a single line that says, “publish DMARC and you are done.” Still, the control family intent is clear. Identity, authentication, system integrity, and audit evidence all matter. I use the CMMC Level 2 assessment guide as the grounding reference, then line up Microsoft 365 controls with Microsoft’s CMMC Level 2 identity guidance and the Azure Government discussion of identification and authentication maturity.

That matters because DMARC is not a paper control. It reduces domain spoofing, raises the cost of phishing, and gives me reporting I can review and retain. For compliance teams, that means stronger proof that approved systems send mail for the domain. For MSPs, it means fewer blind spots in incident review.

I see this gap most often in Small Business IT after an Office 365 Migration. A company upgrades Cloud Infrastructure, refreshes Data Center Technology, and adds SaaS tools, yet the public DNS still reflects an old mail path. For providers selling Cybersecurity Services, Endpoint Security, and Device Hardening, that weak spot is hard to defend.

How SPF, DKIM, and DMARC work together in Microsoft 365

I explain the three controls in plain terms. SPF says which servers may send mail for my domain. DKIM adds a signature that proves the message came through an approved sender and was not altered in transit. DMARC checks whether SPF or DKIM passed and whether that passing result aligns with the visible From domain.

This is where many Microsoft 365 tenants stumble. Exchange Online Protection can filter malicious mail well, but DMARC works at the domain level. If a third-party billing tool, scanner, help desk, or CRM sends as example.com without aligned SPF or DKIM, the receiver may still distrust it. I like the short breakdown in Valimail’s SPF, DKIM, and DMARC explainer because it captures that dependency well.

Forwarding adds another wrinkle. SPF often fails when a message is forwarded, because the forwarding server is not listed in the original sender’s SPF record. DKIM is more durable in that case, so I rarely consider SPF alone enough for Microsoft 365. If DKIM is on and aligned, a forwarded message can still pass DMARC.

Alignment is the part people miss. A message can pass SPF on a technical level, yet fail DMARC because the passing domain is not the same as the domain in the From header. The same rule applies to DKIM signatures. For most organizations, relaxed alignment is a good start. Strict alignment can come later, after I know every sender behaves the way I expect.

SPF record setup for Exchange Online

SPF is usually the first record I publish or clean up. If Exchange Online is the only approved sender for a domain, the record is simple: v=spf1 include:spf.protection.outlook.com -all

That record says Microsoft 365 may send mail for the domain, and everything else should fail. If I still have an on-prem relay, a copier, or a third-party sender, I add only the exact hosts or includes that are needed. One SPF record per domain is the rule. Multiple SPF TXT records create unpredictable results, and too many includes can push me over the 10-lookup limit.

These example records show the usual starting point:

Control	Hostname	Example value	When I use it
SPF	@	v=spf1 include:spf.protection.outlook.com -all	Exchange Online is the only sender
SPF with extras	@	v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 include:mail.example.net -all	Microsoft 365 plus a relay or SaaS sender
DKIM selector1	selector1._domainkey	CNAME selector1-example-com._domainkey.example.onmicrosoft.com	First Microsoft 365 signing key
DKIM selector2	selector2._domainkey	CNAME selector2-example-com._domainkey.example.onmicrosoft.com	Second Microsoft 365 signing key
DMARC	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r	Monitoring phase

The takeaway is simple. Keep SPF short, accurate, and limited to approved senders.

I also document why each sender exists. If a marketing tool no longer sends mail, I remove it. If a copier still needs SMTP, I check whether it should relay through Microsoft 365 instead of sending direct. That cleanup matters because bloated SPF records are common after mergers, Cloud Management changes, or old vendor projects.

DKIM signing in Microsoft 365

SPF validates the path. DKIM validates the message itself. In Microsoft 365, I enable DKIM for every custom domain once the required CNAME records exist in public DNS.

The exact CNAME targets depend on the tenant’s initial onmicrosoft.com domain. For a domain like example.com, Microsoft typically asks for two selectors that look like this: selector1._domainkey.example.com and selector2._domainkey.example.com. Their targets usually follow the pattern selector1-example-com._domainkey.<tenant>.onmicrosoft.com and selector2-example-com._domainkey.<tenant>.onmicrosoft.com.

After DNS propagates, I enable signing in the Microsoft 365 admin experience for that domain. I then send a test message to an external mailbox and inspect the headers. I want to see a DKIM pass result tied to my domain, not a vendor’s shared domain.

This step is where third-party platforms often break the model. Microsoft 365 can sign the mail it sends, but it cannot sign messages sent from another service unless that service supports DKIM for my domain. So I turn on DKIM in every major sender, including ticketing tools, billing systems, security alerts, and transactional apps. When a service cannot sign with my main domain, I prefer a subdomain like alerts.example.com or billing.example.com and give that subdomain its own policy path.

Rolling out DMARC without breaking mail flow

DMARC is where policy and visibility come together. I never jump straight to reject unless I already know every sender is aligned. Instead, I phase the rollout and use the reports to close gaps before I tighten enforcement.

A practical starter record looks like this: v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r

That record does three useful things. It tells receivers the domain uses DMARC. It asks for aggregate reports at the rua address. It keeps enforcement off while I gather data.

I usually roll it out in this order:

1. Inventory every approved sender for the domain, including Microsoft 365, SaaS apps, appliances, and relays.
2. Publish a correct SPF record and enable DKIM in Exchange Online and each third-party sender.
3. Start DMARC with p=none and review aggregate reports for at least two to four weeks.
4. Move to p=quarantine with a partial percentage if needed, then to full enforcement.
5. Finish with p=reject when unknown or misaligned mail has stopped showing up.

For quarantine, I often use a record such as v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; adkim=r; aspf=r. That lets me test impact without blocking every failing message at once. After the reports look clean, I move to pct=100. Then I change the policy to reject.

If one approved sender is missing from your inventory, DMARC will expose it fast. I keep policy at p=none until every legitimate source is aligned.

Aggregate reports are XML, and raw XML is not pleasant to read at scale. I either route them to a parser or dedicate a monitored mailbox to review them. The point is not to collect reports and forget them. The point is to spot unknown sources, vendor mistakes, and domains that still send without DKIM.

I also decide early whether relaxed alignment is enough. In many Microsoft 365 environments, it is. If I manage a high-risk domain, I may tighten to adkim=s and aspf=s later. I do that only after I know the sender ecosystem is stable.

Third-party services, subdomains, and deliverability risks

Most DMARC projects fail because the tenant is not the whole mail system. The domain is. A scanner, payroll tool, support platform, or ERP alert can all send mail that users believe came from you. If those systems are not part of the plan, the record looks clean while mail flow stays messy.

I see this often in firms with Managed IT for Small Business contracts and broad Technology Consulting work. A provider may own Microsoft 365, but another vendor owns CRM mail, website forms, or reservation notices. In restaurants, Restaurant POS Support and Kitchen Technology Solutions sometimes add receipt mail, order alerts, or vendor updates that use the same root domain. That is why I inventory business systems, not only mailboxes.

Subdomains help a lot. I prefer marketing.example.com, support.example.com, or notifications.example.com for services that send on behalf of a department or platform. Then I can give each sender a controlled SPF scope, a separate DKIM setup, and a DMARC policy that fits its use. That also protects the root domain’s reputation.

Deliverability problems usually come from four mistakes. The SPF record is incomplete. DKIM is off in a third-party app. The From domain does not align with the signing domain. Or a retired service still sends mail after I thought it was gone. When I fix those four, DMARC rollout is usually calm.

In my work as a Business Technology Partner, I treat mail authentication as part of Secure Cloud Architecture, Infrastructure Optimization, and IT Strategy for SMBs. It supports Digital Transformation because every cloud app depends on trusted identity. It also fits the kind of Tailored Technology Services and Innovative IT Solutions that small teams need, because spoofed mail can disrupt Business Continuity & Security in one afternoon.

Audit evidence that stands up in a CMMC review

Auditors and assessors want more than a live record in DNS. They want evidence that the control is managed, reviewed, and tied to your security process. I document email authentication like any other security change.

I keep a small evidence set that is easy to maintain:

• A sender inventory that lists Microsoft 365, each third-party mail source, and the business owner.
• Screenshots or exports that show DKIM is enabled for each Microsoft 365 custom domain.
• DNS records for SPF, DKIM, and DMARC, with change dates and approver notes.
• A summary of DMARC aggregate reports and the actions I took after reviewing them.
• Exceptions, retired senders, and tickets that show cleanup over time.

That record set helps me map operational work back to CMMC practices. It also helps during incident review, because I can prove which systems were allowed to send on a given date. I like the perspective in dmarcian’s CMMC overview because it treats DMARC as part of a real control program, not a badge.

For MSPs, this is where good service design shows up. Cloud Infrastructure, Cybersecurity Services, and Office 365 Migration work are stronger when the mail domain is documented like any other asset. If I am responsible for Cloud Management and ongoing support, I schedule a report review, a quarterly sender review, and a quick check after any new SaaS deployment.

Conclusion

A spoofed message is still one of the easiest ways to get around technical defenses. That is why I treat DMARC in Microsoft 365 as an operating control, not a one-time DNS task.

The strongest path is also the simplest. Inventory every sender, publish a clean SPF record, enable DKIM everywhere, then phase DMARC from monitoring to enforcement. When I document each step and review the reports, I reduce spoofing risk and build evidence that supports CMMC Level 2 expectations.

If your domain still sits at p=none months after rollout, the issue is rarely technology. It is ownership, and fixing ownership is what turns a mail setting into a security control.