DMARC Became RFC 7489 in 2015: What the Standard Changed for Senders

Anil Jalela · Published Mar 28, 2015 · 13 min read

Labelled DMARC standards timeline from RFC 7489 in March 2015 to RFCs 9989, 9990 and 9991 in May 2026, with alignment, policy and reporting paths

In March 2015, the IETF published DMARC as RFC 7489. The document gave domain owners and receivers a common method to evaluate whether authenticated SPF or DKIM identities aligned with the domain visible in From, publish requested handling for failures, and exchange aggregate or failure reports. The milestone did not make DMARC an instant inbox credential, and RFC 7489 is no longer the current protocol specification. In May 2026 it was replaced by Standards Track RFC 9989, with reporting separated into RFCs 9990 and 9991.

The dated mailbox-provider change

Event field	Verified value	Why it matters
Historical event date	March 2015	This is the provider-change date, not the NitWings publication date.
Mailbox provider	Industry/IETF	The affected provider estate determines which recipient cohorts require separate evidence.
Change area	Authentication	This identifies whether the change altered authentication, filtering, visibility, measurement or sender operations.
Current status	historical-specification-obsoleted-in-2026	Historical instructions are interpreted against the feature or standard that exists now.

DMARC grew from operational collaboration among mailbox providers, senders and authentication specialists. SPF could authorize a sending host for an envelope domain, and DKIM could authenticate a signing domain, but recipients usually judged identity from RFC5322.From. A phisher could exploit that gap by showing a trusted brand in From while authenticating an unrelated domain elsewhere in the message.

Provider deployments and domain policies existed before March 2015. Yahoo and AOL had already demonstrated the consequences of strict reject policies in 2014. RFC 7489 captured the deployed model as an Informational RFC, documented identifier alignment, described DNS policy discovery and specified aggregate and message-specific failure reporting.

The publication date must not be presented as the date DMARC suddenly began operating everywhere. Adoption, receiver enforcement, report production and domain-owner rollout remained decentralized. A receiver could apply local policy, and a domain owner still needed to inventory legitimate mail before moving from monitoring to quarantine or reject.

The standards status also matters. RFC 7489 was Informational. In May 2026, the IETF published RFC 9989 on the Standards Track and marked RFC 7489 obsolete. Aggregate reporting moved to RFC 9990, and failure reporting moved to RFC 9991. A historical article should preserve the 2015 milestone while directing current engineering work to the current documents.

How the system worked before the change

Before a common DMARC specification, senders and receivers had SPF and DKIM results but lacked one broadly deployed rule for relating those identities to the visible author. A receiver could see SPF pass for a bounce domain and DKIM pass for a service provider while the From field displayed an unrelated brand. Each signal was technically valid, yet neither proved that the visible domain authorized the message.

Domain owners also lacked a consistent cross-provider feedback format for discovering all systems using their identity. Internal MTAs, ESPs, support platforms, billing services, franchises and unauthorized sources could appear across many receiver networks. Without aggregate reports organized by policy domain, migration often depended on incomplete application inventories and sampled headers.

Receiver handling varied. Some systems used authentication and reputation privately; some offered allowlists or feedback loops; some rejected obvious forgeries; others delivered suspicious messages to spam. A domain could not publish one interoperable request describing how receivers should treat aligned-authentication failure for its visible identity.

Strict consumer-domain policies before RFC publication also exposed indirect-mail limitations. Forwarding changed the SPF path, list modification could invalidate DKIM, and a reject request could affect wanted redistributed mail. The standards work documented the deployed protocol but did not remove those architectural tradeoffs.

What changed on the provider side

RFC 7489 defined DMARC evaluation around RFC5322.From. A message passed when at least one authenticated identifier both passed its underlying mechanism and aligned with the From domain. SPF alignment compared the authenticated RFC5321.MailFrom domain with From. DKIM alignment compared a verified signature’s `d=` domain with From. Relaxed alignment allowed the same organizational-domain relationship; strict alignment required an exact domain match.

The DNS record at `_dmarc.` could declare `p=none`, `p=quarantine` or `p=reject`, plus tags controlling alignment, subdomain policy, rollout percentage and report destinations. These values were a published request and information source. Receivers retained responsibility for local policy, security context and final disposition.

Aggregate reports gave domain owners machine-readable summaries of observed sources, authentication outcomes, alignment and receiver disposition. Failure reporting could provide more specific incident detail subject to receiver support, privacy controls and the requested format. Neither stream was guaranteed from every receiver, and report absence did not prove that no mail existed.

The 2026 standards revision preserved the central identity model while clarifying and updating the protocol. RFC 9989 now defines core DMARC. RFC 9990 defines aggregate reporting. RFC 9991 defines failure reporting. Current systems should cite and implement those documents while retaining RFC 7489 only for historical analysis and compatibility context.

Message path before and after

Before

Visible From: brand.example
        |
        +----> SPF pass for bounce.vendor.example
        +----> DKIM pass for vendor.example
        |
        v
Receiver sees valid authentication
but has no common visible-From alignment policy
        |
        v
Receiver-specific filtering and disposition

After

Visible From policy domain
        |
        v
SPF result + MailFrom alignment
        |
        +---- OR ----+
        |            |
DKIM result + d= alignment
        |
        v
DMARC pass or fail
        |
        +----> Domain policy request: none / quarantine / reject
        +----> Receiver local decision
        +----> Aggregate or failure reporting where supported

Who and what the change affected

Traffic or stakeholder	What changed	Required interpretation
Domain owners	They could publish policy and request reports for visible-author use.	Inventory every legitimate stream before enforcement and protect report data.
Mailbox providers and gateways	They gained a common alignment and policy-discovery model.	Apply local abuse controls and do not interpret DMARC pass as proof that content is wanted.
ESPs and SaaS platforms	Customer From domains needed aligned authentication rather than only vendor authentication.	Support customer DKIM, aligned return paths where useful and verifiable DNS onboarding.
Security and brand teams	Spoofing visibility improved through aggregate source data.	Connect authentication findings with phishing response, domain governance and vendor ownership.
Mailing lists and forwarders	Strict policy exposed failures caused by changed SPF paths and modified content.	Preserve signatures, use appropriate identity handling and retain ARC evidence where deployed.
Email marketers	Authentication became a deployment prerequisite but not a placement guarantee.	Track alignment separately from reputation, complaints, placement and commercial outcomes.

Effect on delivery, placement and recipient visibility

DMARC changed eligibility and abuse handling more directly than it changed positive inbox placement. A failing message from a domain publishing quarantine or reject could be filtered or refused even when the sending IP had acceptable reputation. A passing message remained subject to content, reputation, complaint, malware, volume and recipient-engagement systems.

The protocol made stream ownership critical. A brand could no longer assume that publishing one SPF record or adding one DKIM signature covered every platform. Each message needed an aligned path. Customer support systems, invoices, employee tools, marketing ESPs and transactional APIs often used different selectors, envelope domains and organizational owners.

Policy rollout could cause self-inflicted outages when teams moved to reject before identifying legitimate sources. Aggregate reports helped build an inventory, but a report row did not automatically distinguish an approved vendor from a malicious source. Teams needed business ownership, sample headers, DNS configuration, contract context and sending-route evidence.

Indirect mail remained nuanced. A forwarded message could pass through a surviving aligned DKIM signature even though SPF no longer aligned. A mailing list that changed signed content could cause failure. ARC later provided a standardized chain for communicating prior authentication through intermediaries, but receiver trust and local policy still determined the outcome.

Current sender requirements at major providers frequently include DMARC for bulk traffic, but compliance should not be reduced to publishing `p=none`. The operational program includes domain inventory, aligned authentication, reporting, subdomain governance, change control, abuse response and a controlled path to enforcement where appropriate.

Effect on measurement and diagnosis

Aggregate reports introduced a valuable denominator: messages observed by participating receivers using the policy domain. Operators could group by source IP, authentication result, identifier alignment and disposition. However, the data described receiver observations, not campaign delivery counts, human opens or inbox placement.

Source IP alone was not sufficient attribution. Shared ESP pools, forwarding services and infrastructure changes could combine unrelated traffic. A reliable inventory joined report data with selectors, envelope domains, vendor ranges, application owners and controlled test headers.

DMARC pass rate also required careful interpretation. A high rate could coexist with unauthorized lookalike domains that never used the protected domain. A low rate could be dominated by forwarding copies rather than direct spoofing. Reported receiver disposition could differ from the domain’s requested policy because receivers applied local rules or overrides.

Failure reports contained potentially sensitive message or header detail and were not universally generated. Access needed privacy review, retention limits and role-based controls. Teams should not design an incident process that depends on receiving a forensic sample for every failure.

Under the current standards split, analytics pipelines should identify the report format and governing specification explicitly. Parsing, authentication of report transport, compression limits, duplicate handling, date windows and malformed-input controls are security and data-quality concerns, not clerical details.

Advantages for email marketers

Potential advantage	When the advantage is real	Evidence to verify
Visible-author anti-spoofing policy	Legitimate sources align and receivers honor the domain request.	Fewer unauthorized aligned failures and controlled policy disposition.
Cross-provider source visibility	Participating receivers send valid aggregate reports.	Source inventory linked to domain owners, vendors and approved applications.
Clear ESP onboarding requirements	Customers can publish aligned DKIM or return-path configuration.	Delivered headers show aligned pass for each production route.
Controlled path to enforcement	Monitoring data is interpreted with application ownership and tests.	Declining legitimate failure before staged quarantine or reject.
Common incident vocabulary	Teams distinguish authentication, alignment, policy and disposition.	Tickets contain exact domains, results, records and receiver evidence.

Disadvantages and operational risks

Cost or risk	How it appears	Control
Premature reject policy	Valid business mail fails because an unrecorded source is not aligned.	Inventory, assign owners, test and stage enforcement with rollback criteria.
Report data misinterpretation	Forwarders or shared IPs are labelled malicious without route evidence.	Correlate source, selector, headers, vendor ownership and timing.
DNS-record fragility	Invalid syntax, lookup problems or unintended organizational-domain policy causes failure.	Validate records, control changes and monitor authoritative DNS.
Pass treated as trust or inbox status	Authenticated unwanted mail is assumed safe or deliverable.	Continue reputation, content, consent and placement controls.
Sensitive failure-report handling	Reports expose address or message details beyond operational need.	Minimize collection, restrict access, set retention and follow current reporting rules.
Outdated implementation references	New systems treat RFC 7489 as current normative guidance.	Use RFCs 9989, 9990 and 9991 for current protocol and reporting work.

What email teams needed to do at the time

Build a From-domain inventory. Identify every organizational domain and subdomain used by marketing, transactional, support and employee systems.
Publish monitoring policy carefully. Begin with valid reporting destinations and verify that reports are actually received and parsed.
Map every observed source. Join IPs, DKIM selectors, envelope domains, applications, vendors and business owners.
Configure aligned authentication. Give each approved stream at least one reliable aligned SPF or DKIM path.
Investigate indirect mail. Separate direct unauthorized sources from forwarders and mailing-list transformation.
Stage enforcement. Define acceptable legitimate failure, rollback conditions and incident ownership before quarantine or reject.
Protect report data. Apply access, privacy and retention controls to aggregate and failure reports.
Train operations teams. Ensure bounce classification and header review distinguish pass, alignment, policy and receiver disposition.

What email teams should do now

Use RFC 9989 for core DMARC. Treat RFC 7489 as historical and compatibility context because it is formally obsolete.
Use RFC 9990 for aggregate reporting. Validate current format, transport, security and processing requirements.
Use RFC 9991 for failure reporting. Account for receiver support, privacy and data minimization.
Maintain domain governance. Require an owner, purpose, authenticated route and change record for every visible From domain.
Prefer aligned DKIM resilience. Configure customer-controlled signatures and rotate selectors safely; use aligned SPF where the route supports it.
Monitor authoritative DNS. Detect accidental record removal, syntax defects and subdomain-policy impact.
Preserve message-level evidence. Retain representative delivered and rejected headers for route validation.
Integrate ARC cautiously. Use authenticated intermediary history as evidence, never as an unconditional acceptance instruction.
Separate identity from placement. Correlate DMARC with SMTP, complaints, provider reputation, spam placement and business outcomes.
Review enforcement after infrastructure changes. ESP migrations, acquisitions and new SaaS systems can reopen legitimate failure paths.

Worked deliverability scenario

A company publishes `p=none` and receives aggregate reports showing mail from its main ESP, a billing platform, a support system, corporate gateways, several forwarders and unknown cloud IPs. Management asks the team to move directly to reject because the main marketing campaign passes DMARC.

The team assigns ownership instead of classifying by IP alone. The billing platform signs with its own domain and fails alignment. The support system uses an aligned DKIM selector but only in one region. Corporate mail passes through preserved DKIM. Several unknown sources are forwarded copies, while one is an unauthorized form-mail application.

Operators add aligned customer DKIM to billing, correct the support-region configuration, retire the unauthorized application and document the forwarder pattern. They test direct and redistributed samples, monitor report windows and define a rollback threshold. Only then do they stage enforcement while watching SMTP policy failures and critical message streams.

The result is a security improvement without turning aggregate reports into an automated blocklist. DMARC establishes identity authorization, but the company still measures complaints, deferrals, spam placement and customer outcomes separately. In 2026, its documentation and parser are updated to reference RFCs 9989, 9990 and 9991.

Evidence and diagnostics

Policy DNS: exact `_dmarc` TXT response, organizational domain, tags, resolver and timestamp.
Visible identity: RFC5322.From domain actually evaluated by the receiver.
SPF evidence: connecting IP, RFC5321.MailFrom result and relaxed or strict alignment outcome.
DKIM evidence: every verified signature, selector, `d=` domain and alignment outcome.
Receiver result: Authentication-Results, local disposition, SMTP response and any documented override.
Aggregate evidence: report organization, date range, policy, source rows, counts and duplicate handling.
Failure evidence: receiver support, report privacy, redaction, transport and retention.
Route ownership: application, vendor, region, stream, contract owner and approved DNS configuration.
Intermediary evidence: Received chain, content modification, surviving signatures and ARC validation.

Failure modes and incorrect conclusions

Calling any SPF or DKIM pass a DMARC pass. At least one passing authenticated domain must align with From.
Moving to reject from an incomplete inventory. A clean marketing stream does not prove billing, support and employee tools are ready.
Treating aggregate reports as delivery receipts. Their counts and dispositions are receiver observations, not inbox or engagement telemetry.
Automatically blocking every unknown source. Forwarders, shared infrastructure and ownership gaps require investigation.
Assuming report absence means no traffic. Receiver participation, thresholds, errors and transport gaps can hide observations.
Using DMARC to excuse unwanted mail. Authentication does not create consent or positive reputation.
Citing RFC 7489 as the current standard. It was obsoleted in May 2026 by the current specification set.

Current status and superseding changes

RFC 7489 remains an important historical record of the deployed DMARC model in March 2015, but it is no longer the current normative protocol document. RFC 9989, published in May 2026 on the Standards Track, formally obsoletes it.

Reporting is now separated. RFC 9990 specifies aggregate reporting, while RFC 9991 specifies failure reporting. That separation makes current implementation references clearer and allows protocol, aggregate processing and failure-detail handling to evolve under distinct documents.

The central operating principle remains recognizable: evaluate aligned SPF or DKIM against the visible From policy domain, discover the domain’s requested policy, let the receiver apply its final decision, and provide reporting where supported. Current engineering must follow the updated details rather than assuming that every 2015 requirement is unchanged.

For marketers, DMARC is now part of baseline identity governance and major-provider compliance. Its value is anti-spoofing control and operational visibility. It still does not certify content, authorize a list purchase, repair complaints or guarantee the inbox. Those layers require their own evidence and controls.

Operator checklist

Record March 2015 as the RFC 7489 publication milestone.
Label RFC 7489 Informational and obsolete, not the current standard.
Use RFC 9989 for current core DMARC implementation.
Use RFC 9990 and RFC 9991 for current reporting work.
Inventory all visible From domains, subdomains and production routes.
Verify identifier alignment in real delivered headers.
Map aggregate sources to applications and accountable owners.
Protect report transport, access and retention.
Test forwarding and mailing-list transformations separately.
Stage enforcement with thresholds, rollback and incident ownership.
Measure authentication separately from acceptance and inbox placement.

Primary and contemporaneous references

RFC Editor: RFC 7489: March 2015 Informational DMARC specification, now obsolete.
RFC Editor: RFC 9989: May 2026 Standards Track core DMARC specification.
RFC Editor: RFC 9990: Current DMARC aggregate reporting specification.
RFC Editor: RFC 9991: Current DMARC failure reporting specification.
RFC Editor: RFC 8617: ARC protocol for authenticated intermediary evidence.