DMARC—Domain-Based Message Authentication, Reporting, and Conformance—lets a domain owner publish how receivers should evaluate mail that uses the domain in the visible From: header, with validation based on aligned SPF or DKIM authentication. In May 2026 the IETF replaced the original RFC 7489 with a new standards-track DMARC set: RFC 9989 defines the protocol, RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting. Security teams should update old runbooks that still treat RFC 7489 as the current specification.
Within Security Engineering, DMARC is best understood as a domain-spoofing control and telemetry system. SPF and DKIM prove things about sending infrastructure and signatures; DMARC connects those results to the domain users actually see in the author address.
The existing MX records article covers mail routing. Authentication is a separate layer: valid routing does not prove the sender is authorized to use the visible domain.
DMARC passes when an aligned SPF or DKIM result passes
DMARC does not require both SPF and DKIM to pass. A message can pass DMARC when at least one authentication mechanism passes and the authenticated domain is aligned with the author domain in the RFC5322.From header.
That distinction matters operationally because forwarding can break SPF while preserving DKIM, and some legitimate sending platforms sign with a DKIM domain that differs from the visible sender.
Design for both mechanisms where possible so one failure path does not collapse DMARC.
Alignment is the security property, not just authentication
SPF authenticates the MAIL FROM or related domain used in SMTP; DKIM authenticates the signing domain in the d= tag. DMARC asks whether that authenticated domain aligns with the visible From domain according to relaxed or strict alignment rules.
An attacker can pass SPF for a domain they control while spoofing another brand in the visible From field; DMARC blocks that shortcut because the domains do not align.
Monitor alignment failures separately from raw SPF/DKIM failures when troubleshooting.
The policy record lives under _dmarc
The domain publishes a TXT record at _dmarc.example.com with v=DMARC1 plus policy and optional reporting tags.
Typical organizational policies are p=none, p=quarantine, and p=reject.
Start with policy and reporting that lets the organization understand legitimate senders, then move toward enforcement after sources are aligned rather than jumping to reject before inventory is complete.
p=none is observation, not protection
A none policy asks receivers to evaluate/report DMARC without requesting quarantine or rejection.
It is valuable during discovery because aggregate reports reveal senders using the domain, authentication results, and alignment failures.
But spoofed mail can still be delivered. Treat p=none as a migration state unless the risk decision explicitly accepts monitoring-only behavior.
Aggregate reporting is now defined separately in RFC 9990
DMARC aggregate reports provide summarized authentication/disposition information for a policy domain, including SPF/DKIM results and alignment.
Centralize report processing because raw XML volumes can be large for high-volume domains.
Use reports to identify forgotten SaaS senders, marketing platforms, ticket systems, subdomains, and infrastructure that would fail under quarantine/reject.
Failure reports are more sensitive and less universal
RFC 9991 defines message-specific DMARC failure reporting. These reports can expose message-related information and receivers are not required to generate every requested report.
Use ruf/failure-reporting only after privacy and operational review; aggregate reporting is the more common control-plane signal.
Protect reporting mailboxes and processors because authentication reports reveal sending infrastructure and can contain sensitive metadata.
Bulk sender rules make DMARC operationally mandatory
Google currently requires domains sending more than about 5,000 messages per day to personal Gmail accounts to configure SPF, DKIM, and DMARC, with the From domain aligned to either SPF or DKIM for direct mail.
Gmail has increased enforcement against noncompliant bulk traffic since November 2025.
Deliverability requirements should reinforce, not replace, the anti-spoofing goal: authenticate every legitimate source, not only high-volume marketing infrastructure.
Forwarding and mailing lists need careful testing
Forwarders can break SPF because the forwarding server is not in the original domain’s SPF record. Mailing lists can modify subject/body and break DKIM signatures.
ARC and list-aware handling can help receivers preserve authentication context, but domain owners should test important forwarding/list workflows before strong enforcement.
Do not weaken DMARC globally to accommodate one broken intermediary if that path can be fixed or isolated.
Subdomains need an intentional policy
DMARC policy applies through organizational-domain discovery and can include subdomain-specific behavior.
Inventory mail-capable and non-mail subdomains. For subdomains that should never send mail, strong authentication policy plus absent/locked-down SPF/DKIM reduces spoofing opportunities.
Shadow marketing or SaaS subdomains are common reasons organizations delay enforcement; treat them as governance debt with owners and deadlines.
Incident response should use authentication evidence
When phishing impersonates the organization, collect the full message headers and Authentication-Results, DKIM signature, SPF result, DMARC result, source IP, and envelope/from domains.
Correlate with web and email inspection telemetry and user reports.
A DMARC pass does not prove the message is benign—it proves domain authentication/alignment. Compromised legitimate senders can still send malicious content.
DMARC succeeds when every legitimate sender is known and aligned
The mature program inventories sending sources, deploys SPF and DKIM correctly, uses current RFC 9989 behavior, processes aggregate reports, moves from observation toward enforcement, tests forwarding/list paths, and monitors policy drift.
Email authentication should make spoofing the organization’s visible domain materially harder while preserving legitimate mail—not become a DNS record nobody reviews after rollout.
Domain inventory should include third-party senders before enforcement. Marketing automation, CRM, ticketing, HR platforms, cloud billing, survey tools, security appliances, and outsourced services frequently send on behalf of the organization. Build one owner-and-provider inventory with SPF include chains, DKIM selectors, From domains, return-path domains, and expected message categories so DMARC failures can be assigned rather than merely observed.
SPF has architectural limits that make DKIM especially important. SPF validates the envelope sender against the sending IP and can break through forwarding; it also has DNS lookup constraints that become fragile when organizations chain many SaaS includes. Consolidate senders, remove obsolete includes, and prefer provider-managed DKIM so DMARC can survive forwarding and infrastructure changes.
DKIM key lifecycle belongs in normal security operations. Use sufficiently strong keys supported by the provider, rotate selectors according to policy, remove abandoned selectors, and monitor signatures from unexpected selectors or domains. A DMARC pass based on DKIM is only as trustworthy as the domain’s control over the signing key and the provider authorized to use it.
Roll enforcement gradually by domain and traffic segment. A practical sequence is to process aggregate reports under p=none, remediate legitimate failures, move selected domains or percentages to quarantine, observe help-desk/delivery impact, then advance to reject. Large organizations should not assume one primary-domain change will behave identically for every subdomain, vendor, and mailing-list workflow.
Authentication should be tested against message forwarding, auto-forwarding rules, listservs, aliases, and security gateways that rewrite headers or bodies. Some intermediaries preserve DKIM while others break it. Maintain a small test matrix so email-security changes can be validated before new gateway rules or marketing tools reach production.
DMARC reports themselves need retention and analytics. Store normalized report records long enough to identify trend changes, new senders, large failure spikes, or policy drift after vendor migrations. Alert on unexpected volume from unknown IP ranges or a sudden drop in alignment for a major provider because those changes can indicate misconfiguration or abuse.
Executive domains and non-sending domains deserve strong protection first. Domains used only for corporate identity, investor relations, or executive communication may have few legitimate senders and can often move to reject faster than complex marketing domains. For domains that should never send email, publish restrictive SPF/DKIM/DMARC patterns and monitor attempted use so spoofing attempts remain visible.
DMARC is only one layer of business-email-compromise defense. Attackers can register lookalike domains, compromise real mailboxes, or abuse legitimate SaaS senders while passing authentication. Combine DMARC with display-name/lookalike detection, secure account recovery, conditional access, user reporting, URL/attachment controls, and incident investigation so authenticated phishing does not inherit undeserved trust.
DMARC change management should include DNS TTLs and rollback. A malformed TXT record or premature enforcement can affect delivery quickly and broadly. Validate syntax through multiple resolvers, lower TTL before planned changes where appropriate, keep the previous record documented, and stage changes during periods when mail operations can monitor bounces and support tickets.
Authentication should be enforced consistently across acquisition and divestiture domains. New brands, parked domains, merger domains, campaign domains, and old product names are frequent spoofing targets because they receive less operational attention. Add DMARC/SPF/DKIM posture checks to domain registration, migration, and retirement workflows so unused domains do not remain easy impersonation surfaces.
Security teams should correlate DMARC failures with threat intelligence and user-reported phishing. A surge from one infrastructure provider, lookalike campaign, or compromised SaaS tenant can inform blocking, takedown, and incident response. Aggregate reports are primarily domain telemetry, but they become more valuable when connected to the broader email-security picture.
Document provider responsibilities. Some SaaS vendors require customers to add SPF includes, some supply DKIM selectors, and some use custom return-path domains. Record who owns key rotation, DNS changes, bounce handling, and authentication troubleshooting for every sender so a vendor outage or migration does not leave the domain in a partially aligned state.
