Obsoleted
What this RFC defined
RFC 7489 defined 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. It was published in March 2015 as an Informational document through the Independent Submission stream, not as an IETF standard. In May 2026 the IETF replaced it with three Standards Track documents: RFC 9989 for the protocol, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting.
Where you see it in practice
The _dmarc.yourdomain.com TXT record (p=reject; rua=mailto:reports@yourdomain.com) was defined by this RFC, and its syntax carries over unchanged to RFC 9989. 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.
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.
What changed in DMARCbis (RFC 9989, 9990, 9991)
The update is backward compatible: records still start with v=DMARC1, and p, sp, rua, ruf, adkim, aspf and fo keep their meaning. The differences are in status, policy discovery and a handful of tags. Full detail in our RFC 9989 guide.
| Topic | RFC 7489 (2015) | RFC 9989 (2026) |
|---|---|---|
| Status | Informational, Independent Submission | Proposed Standard, IETF Standards Track |
| Finding the organizational domain | Public Suffix List (an external list maintained outside the IETF) | DNS tree walk, capped at eight DNS queries |
pct (percentage rollout) | Applies the policy to N% of failing mail | Removed; replaced by t=y (test mode) |
rf, ri | Failure report format and reporting interval | Removed from the record |
np | Not defined | Policy for non-existent subdomains |
psd | Only in the experimental RFC 9091 | Marks a public suffix domain (y, n or u) |
| Reporting | Inside the same document | Split into RFC 9990 (aggregate) and RFC 9991 (failure) |
Mailbox providers move their parsers to the new specification at their own pace, so a record that works for both is the safe choice in 2026: keep pct only if you still need it for older receivers, and add t=y or np= where they help. Sources: RFC 9989, RFC 7489 status page.
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 the Gmail and Yahoo bulk sender rules (February 2024), a DMARC record is required for senders of 5,000+ messages a day. Obsoleted in May 2026 by RFC 9989, 9990 and 9991, which keep v=DMARC1 and remain backward compatible.
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 (removed in RFC 9989, which uses t=y) |
| Bulk sender rules impact | Gmail-Yahoo (Feb 2024) require p=none minimum for 5000+ msg/day |
| Published | March 2015, Informational |
| Status | Obsoleted May 2026 by RFC 9989, 9990, 9991 |
DMARC record syntax
_dmarc.example.com. IN TXT “v=DMARC1; p=reject;
rua=mailto:dmarc-agg@example.com;
ruf=mailto:dmarc-fo@example.com;
adkim=r; aspf=r; fo=1; pct=100; sp=reject”
Tag reference:
v Version (always DMARC1); MUST be first
p Policy: none, quarantine, reject
sp Subdomain policy (defaults to p if omitted)
rua Aggregate report destination (mailto: URI list)
ruf Forensic report destination (mailto: URI list)
adkim DKIM alignment: r (relaxed, default) or s (strict)
aspf SPF alignment: r (relaxed, default) or s (strict)
pct Percentage of failing mail to apply policy to (0-100)
fo Forensic report options: 0/1/d/s combinations
ri Reporting interval in seconds (default 86400 = 24h)
RFC 9989 removes pct, rf and ri, and adds np, psd and t.
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
t=y, which asks receivers to apply one level lower while you read the reports, then drop t=y. Total timeline for a typical enterprise: 6 to 9 months from p=none to p=reject.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
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>12345678901234567890</report_id>
<date_range>
<begin>1721606400</begin>
<end>1721692799</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.0.2.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
<selector>mail-2026</selector>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
Related standards and further reading
- RFC 9989: DMARC (current standard, May 2026)
- RFC 9990: DMARC aggregate reporting
- RFC 9991: DMARC failure reporting
- 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 5,000 or more messages per day to Gmail or Yahoo must publish a DMARC record; p=none is enough to meet the rule, and the From domain must align with SPF or DKIM. Enforcement (p=quarantine or p=reject) is recommended but not required. Non-compliant mail can be rate limited or rejected. See the sender requirements guide.
Is RFC 7489 still valid after DMARCbis?
RFC 7489 is obsolete since May 2026, replaced by RFC 9989 (protocol), RFC 9990 (aggregate reports) and RFC 9991 (failure reports). Your existing record does not break: the version tag stays v=DMARC1 and the main tags keep their meaning. What changes is that pct, rf and ri are no longer part of the record, three tags are added (np, psd, t), and receivers find the organizational domain with a DNS tree walk instead of the Public Suffix List.
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).
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout 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.