Skip to main content
Version: 3.0.0-preview

CISA.MS.EXO.4.1 - A DMARC policy SHALL be published for every second-level domain.

Overviewโ€‹

A DMARC policy SHALL be published for every second-level domain.

Rationale: Without a DMARC policy available for each domain, recipients may improperly handle SPF and DKIM failures, possibly enabling spoofed emails to reach end users' mailboxes. Publishing DMARC records at the second-level domain protects the second-level domains and all subdomains.

How this test worksโ€‹

This test applies the same rule as CISA ScubaGear:

  • It checks every accepted domain in Exchange Online, including the initial *.onmicrosoft.com domain and subdomains. Only the coexistence domain (*.mail.onmicrosoft.com) is left out, because Microsoft manages it.
  • For each domain it queries _dmarc.<domain> and keeps the TXT records that start with v=DMARC1. If there is exactly one, that is the domain's record. If there are none, or more than one, it walks up the parent domains as described in RFC 9989 (at most eight DNS queries per domain) and uses the record it finds there. A record published for example.com therefore also covers mail.example.com.
  • A domain passes when its record starts with exactly v=DMARC1;. The policy (p=) and the report addresses (rua=) are not checked here: CISA.MS.EXO.4.2 and CISA.MS.EXO.4.3 check them.
  • A domain fails when no record is found. A DNS lookup that fails counts as no record at that name, as in ScubaGear: the walk goes on, and a record found at a parent domain still applies. When no record is found, the result names the lookup that failed.

On macOS and Linux the test needs the DnsClient-PS module (Install-Module DnsClient-PS -Scope CurrentUser); without it the test is skipped.

The Strict parameter is no longer used and has no effect.

Remediation actionโ€‹

DMARC is not configured through the Exchange admin center, but rather via DNS records hosted by the agency's domain. As such, implementation varies depending on how an agency manages its DNS records. See Form the DMARC TXT record for your domain | Microsoft Learn for Microsoft guidance.

A DMARC record published at the second-level domain will protect all subdomains. In other words, a DMARC record published for example.com will protect both a.example.com and b.example.com, but a separate record would need to be published for c.example.gov.

For the initial *.onmicrosoft.com domain, add the record in the Microsoft 365 admin center: see Use the Microsoft 365 admin center to add DMARC TXT records for *.onmicrosoft.com domains.

To test your DMARC configuration, consider using one of many publicly available web-based tools. Additionally, DMARC records can be requested using the PowerShell tool Resolve-DnsName. For example:

Resolve-DnsName _dmarc.example.com txt

If DMARC is configured, a response resembling v=DMARC1; p=reject; pct=100; rua=mailto:reports@dmarc.cyber.dhs.gov, mailto:reports@example.com; ruf=mailto:reports@example.com will be returned, though by necessity, the contents of the record will vary by agency. In this example, the policy indicates all emails failing the SPF/DKIM checks are to be rejected and aggregate reports sent to reports@dmarc.cyber.dhs.gov and reports@example.com. Failure reports will be sent to reports@example.com.

Test Metadataโ€‹

FieldValue
Test IDCISA.MS.EXO.4.1
SeverityMedium
SuiteCISA
ProductExchange Online
FeatureEmail authentication
AreaEmail and collaboration protection
Resource typeDomain
User impactLow
Implementation costLow
MITRE ATT&CKT1566 Phishing, T1598 Phishing for Information, T1684.002 Email Spoofing
Supports benchmarkCISA SCuBA Secure Configuration Baselines for Microsoft 365 (version ScubaGear main, 2026-10-11), requirement MS.EXO.4.1
CriticalitySHALL
Upstream requirementMS.EXO.4.1v1
Supports controlscisa-scuba:MS.EXO.4.1, nist-800-53-r5:SI-8
PowerShell testTest-MtCisaDmarcRecordExist
ServicesExchangeOnline

Sourceโ€‹