What this RFC defines
RFC 7489 defines DMARC (Domain-based Message Authentication, Reporting, and Conformance), a policy framework that ties SPF and DKIM together. A domain owner publishes a DMARC record in DNS specifying what receiving servers should do with messages that fail authentication, and where to send aggregate and forensic reports.
Where you see it in practice
The _dmarc.yourdomain.com TXT record (p=reject; rua=mailto:reports@yourdomain.com) is defined by this RFC. When Gmail sends you a daily aggregate report showing which IPs sent email claiming to be from your domain, that report format and delivery mechanism come from RFC 7489. A DMARC policy of p=reject is the strongest protection against domain spoofing.
How it connects to other RFCs
RFC 7489 builds on RFC 7208 (SPF) and RFC 6376 (DKIM) as its two alignment sources. RFC 8601 defines the Authentication-Results header that carries DMARC outcomes. RFC 8617 (ARC) solves the problem of DMARC breaking legitimate forwarding scenarios. Together these four RFCs form the modern email authentication stack.
Current status
RFC 7489 is the current DMARC standard, published March 2015. It has been required for bulk senders to Gmail and Yahoo since February 2024. A successor standard (DMARCbis) has been in IETF development to address known gaps but RFC 7489 remains the deployed reference.
The DMARC framework
RFC 7489 defined DMARC (Domain-based Message Authentication, Reporting, and Conformance) in March 2015. DMARC ties together SPF and DKIM by requiring alignment: for a DMARC pass, either SPF must pass with the MAIL FROM domain aligned to the RFC 5322 From header domain, OR DKIM must pass with the signing domain aligned to the From header domain. A domain publishes a DMARC policy in DNS at _dmarc.example.com specifying what receivers should do with unauthenticated mail: none (monitor only), quarantine (spam folder), or reject.
The aggregate report ecosystem
DMARC introduced aggregate reports (RUA) and forensic reports (RUF). Aggregate reports are XML documents that receivers send to the domain owner daily, summarizing authentication results for messages claiming to be from that domain. This visibility allows domain owners to detect unauthorized senders and configure legitimate ones correctly. Services like dmarcian, Valimail, EasyDMARC, and PowerDMARC parse and visualize aggregate reports because the raw XML is difficult to interpret at scale.
Adoption in 2026
Since Google and Yahoo announced sender requirements in February 2024, DMARC has been mandatory for bulk senders sending 5,000 or more messages per day to Gmail or Yahoo. This drove rapid adoption: DMARC coverage of Alexa top-1M domains jumped from about 33% in late 2023 to over 70% in 2025. Small senders still often lack DMARC, but every professional sender either has DMARC configured or faces significant deliverability disadvantage. RFC 7489 remains the current standard; a DMARCbis update is in development but not yet published.
RFC 7489 (March 2015) defines DMARC (Domain-based Message Authentication, Reporting, and Conformance): a policy layer that requires SPF or DKIM to align with the From header domain per RFC 5322. Publishes policy via DNS TXT at _dmarc.[domain]. Policies: none (monitor), quarantine (mark spam), reject (block). Sends aggregate (rua) and forensic (ruf) reports to specified addresses. Since Gmail-Yahoo bulk sender rules (2024), effectively mandatory for high-volume commercial senders. DMARCbis update in development but not yet published as of 2026.
RFC 7489 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Anti-spoofing policy over SPF and DKIM; require alignment with From domain |
| Storage | DNS TXT at _dmarc.[domain] |
Policies (p) | none, quarantine, reject |
| Alignment modes | relaxed (subdomains OK) or strict (exact match) for SPF and DKIM independently |
| Reporting | Aggregate (rua) and forensic (ruf) XML reports |
| Percentage rollout | pct=N applies policy to N% of failing mail |
| Bulk sender rules impact | Gmail-Yahoo (Feb 2024) require p=none minimum for 5000+ msg/day |
| Published | March 2015 |
DMARC record syntax
The alignment concept (central to DMARC)
DMARC does not add a new authentication mechanism. It requires that SPF or DKIM authenticate an identity that aligns with the visible From header domain. Alignment can be relaxed (organizational domain match) or strict (exact domain match).
| Mechanism | Authenticated identity | Alignment target | Relaxed example (aligned) | Strict example (aligned) |
|---|---|---|---|---|
| SPF | MAIL FROM (envelope sender) | From header domain | MAIL FROM: bounces.example.com, From: example.com | MAIL FROM: example.com, From: example.com |
| DKIM | DKIM d= tag | From header domain | d=mail.example.com, From: example.com | d=example.com, From: example.com |
The three policy values
| Policy | Receiver action on failing mail | When to use |
|---|---|---|
p=none | Take no action; still emit reports | Monitoring phase: gather data before enforcing |
p=quarantine | Deliver to spam folder (or apply spam-like scoring) | Rollout phase: catch spoofing while accepting business risk |
p=reject | Reject at SMTP (5xx) so mail bounces to sender | Steady state: prevent spoofing entirely |
The recommended DMARC rollout
Common DMARC deployment mistakes
mail.example.com aligns with example.com in relaxed mode. Strict alignment requires exact match. Most deployments should use relaxed (the default) because subdomain sending is common; strict is only appropriate for security-critical domains with tightly controlled sending.sp= explicitly. Otherwise, you inherit the parent policy which may be too strict for a subdomain still in monitoring.Aggregate report format
Related standards and further reading
- RFC 7208: SPF (Sender Policy Framework)
- RFC 6376: DKIM (DomainKeys Identified Mail)
- RFC 8601: Authentication-Results header
- RFC 8617: ARC (preserves verdicts across intermediaries)
- RFC 5322: Internet Message Format (the From header DMARC aligns against)
- RFC 5321: SMTP (MAIL FROM identity SPF authenticates)
- DMARC Record Setup Guide: syntax, examples, rollout patterns
- Free DMARC Record Checker: validate your policy publication
- SPF Record Guide: paired authentication
- DKIM Record Guide: paired authentication
- Authentication-Results Header: reading DMARC=pass/fail verdicts
Frequently asked questions
What is the difference between DMARC and DKIM+SPF?
SPF and DKIM are authentication mechanisms: they prove that an email was sent from an authorized IP (SPF) or signed by a legitimate key (DKIM). DMARC is a policy layer on top: it says which identity (MAIL FROM or DKIM d=) must align with the From header the recipient sees, and what the receiver should do when neither aligns. Without DMARC, an attacker can pass SPF and DKIM with their own domain while forging your brand in From; DMARC’s alignment requirement closes this gap.
Should I start with p=reject or p=none?
Always p=none. Deploying p=reject cold blocks legitimate mail streams the domain owner does not know about (invoice systems, HR tools, transactional platforms). p=none gathers aggregate reports without blocking, letting you identify and authenticate all legitimate senders. Once reports show near-100% alignment for legitimate mail, progress to p=quarantine with low pct, then p=quarantine pct=100, then p=reject. Typical enterprise timeline is 6 to 9 months.
What are Gmail and Yahoo’s 2024 bulk sender rules and how does DMARC fit?
Since February 2024, senders shipping 5000 or more messages per day to Gmail or Yahoo must publish a DMARC record with p=none minimum. Higher-reputation senders are effectively required to enforce (p=quarantine or p=reject). Non-compliant senders face rate limiting, mass rejection, and reputation damage. This transformed DMARC from best practice to operational requirement for commercial email.
Do I need both aggregate (rua) and forensic (ruf) reports?
Aggregate reports (rua) are essential; they show which senders are failing, at what volume, from which IPs, with what alignment issues. Forensic reports (ruf) contain the actual failing message headers and are useful for investigating specific incidents, but they include partial user content and many receivers do not send them (privacy concerns). Start with rua only; add ruf later if you need per-message investigation capability.
Why does DMARC fail even though SPF and DKIM pass?
The most common cause: passing SPF or DKIM with an unaligned identity. Example: your marketing platform sends via MAIL FROM: bounces@platform.com which passes SPF for platform.com, and signs with d=platform.com. Both authenticate but neither aligns with your From: @yourbrand.com. Fix: configure the ESP for authenticated sending on your domain (custom Return-Path subdomain for SPF alignment, CNAME-delegated DKIM selector for d= alignment).
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
