What changed in DMARC reporting with RFC 9989?

You’re sifting through DMARC aggregate reports, hunting for alignment between policy enforcement and actual email flow — but every report arrives in a slightly different XML structure. One day it’s policy_published, the next it’s policy-published. The same field, different case. The same timestamp, different format. You’re not alone.

RFC 9989 fixed that. It introduced a single, consistent, machine-readable format for DMARC aggregate reports, replacing the old, inconsistent XML standard. Now all reports use JSON with standardized field names and types — no more guessing what policy-dkim means or why one system expects a Unix timestamp and another a ISO 8601 string.

What you get is faster parsing, fewer errors, and true interoperability across tools. The data is no longer trapped in siloed formats. You can build dashboards, automate compliance checks, and detect misconfigurations — all with confidence in the structure.

Key takeaways

  • DMARC aggregate reports now use a standardized JSON format, improving machine readability and reducing parsing errors.
  • Field names and data types are now consistent across all reporters, eliminating ambiguity caused by XML variability.
  • Report identifiers, timestamps, and policy enforcement details are now uniformly structured, enabling reliable cross-tool analysis.

Why did the IETF update DMARC reporting in RFC 9989?

The IETF updated DMARC reporting in RFC 9989 to fix a long-standing problem: inconsistent, non-standard report formats across email providers. Before this change, DMARC reports from different domains and platforms used wildly different field names, data types, and structures—making it nearly impossible to automate analysis or compare results across systems. The update standardizes the format, reducing parsing errors and enabling real-time security monitoring.

How messy was the old reporting system?

Let’s be honest: prior DMARC reports were chaotic. One provider would list a domain as rua, another as reporting-domain, and a third as org-domain. Field types varied too—some used ISO timestamps, others Unix, and a few omitted date formatting entirely. Tools had to manually map each report structure, increasing processing time and error rates.

As a result, even simple tasks like detecting spoofing patterns or evaluating sender compliance became slow and error-prone. Security teams spent more time wrestling with data than analyzing threats. This inconsistency wasn’t just a minor annoyance—it created blind spots in email security monitoring, especially for large-scale operations.

What does RFC 9989 fix in practice?

RFC 9989 introduces a consistent data model and standardized XML schema. It defines exact field names, required data types, and proper formatting rules—like using UTC timestamps with timezone indicators. This uniformity means tools can parse and process reports without custom logic for each sender.

Now, whether you're using a SIEM, a cloud security platform, or an internal analytics dashboard, the same fields—like policy_published, reason, or source_ip—will appear the same way. That’s a big win for cross-platform interoperability.

This change didn’t happen in a vacuum. The demand came from security teams and vendors alike who needed reliable, automated threat intelligence. The IETF responded by codifying what many organizations were already doing in practice: treat DMARC reports like structured data, not unstructured log files.

For teams using email verification tools, this standardization helps ensure that reported failures (like missing or invalid SPF/DKIM) are correctly interpreted—especially when validating domains at scale. You can test the health of a sender’s DMARC policy, including alignment, with greater confidence.

For real-world testing and monitoring, tools like MailTester’s inbox placement checks validate how well your DMARC-compliant messages land in user inboxes. While not a direct reporting tool, it complements DMARC analysis by showing whether alignment and authentication are working in practice.

How does the new JSON-based format improve DMARC analysis?

The new JSON-based format in RFC 9989 streamlines DMARC reporting by making data faster to parse, easier to standardize, and capable of expressing complex hierarchies—like subdomain policies and individual email events—so tools can analyze large volumes of reports in real time without bottlenecks. You no longer need custom logic for every vendor’s unique XML structure.

Speed and scalability with structured data

Unlike older XML-based formats that require heavy processing and context-aware parsing, JSON is natively supported by modern programming languages and systems. This means tools can read and act on DMARC reports minutes after receipt, even during peak abuse periods when thousands of reports arrive hourly. The change translates to faster detection of spoofing attempts and more timely updates to protection policies.

Standardization and deeper insights

With field names like report_metadata and policy_published now standardized across vendors, you can correlate data from different senders or domains in a single dashboard, even when reports come from multiple email providers. This eliminates the guesswork of mapping proprietary tags.

JSON also supports nesting, which unlocks granular analysis. You can now see how policy enforcement differs between mail.example.com and login.example.com within one report. Each alignment failure or SPF/DKIM check can be broken down individually, helping you identify weak points in your sender infrastructure, like poorly configured subdomains or misaligned DKIM selectors.

For teams managing large-scale email programs, this level of detail is essential. It moves you from reactive alerts to proactive hardening. Tools that use this format can build rich visualizations of trust paths or track sender reputation shifts across domains.

For a real-world test of how well your domain's signals are being validated, you can simulate inbox placement and assess how DMARC compliance affects deliverability—try our inbox placement testing tool to see how your emails land in real user inboxes: inbox placement tester.

The full specification is available at the IETF’s official site: RFC 9989, which details the structural changes and adoption guidelines. As email systems evolve, this format ensures DMARC remains a practical, scalable standard—no longer a manual log review, but a machine-readable foundation for automated security.

What are the key fields now required in RFC 9989 DMARC reports?

RFC 9989 updates DMARC reporting to standardize the structure of aggregate reports, requiring four core sections: report_metadata (basic report details), policy_published (the domain’s DMARC policy), record (individual message data), and identifiers (From, Return-Path, and envelope sender info). These fields ensure clearer traceability and automation in email authentication monitoring. You can use this structure to verify sender compliance and catch spoofing attempts more reliably.

Structure and Purpose of the Core Fields

The report_metadata section is your first point of reference. It contains the reporting domain, a unique report ID, and timestamps for the report’s start and end period. The version field indicates compliance with the latest standard—this helps tools like MailTester parse reports correctly without ambiguity. You’ll see this section consistently across all reports from compliant receivers.

Next, policy_published records the DMARC policy the domain has set: none, quarantine, or reject. It also includes alignment requirements for SPF and DKIM checks (relaxed or strict). This tells you what the domain intended for authentication—whether a failed SPF check should block the message or just mark it as suspicious.

The record section is where the action happens. For each message, it logs the sender’s IP address, SPF and DKIM results (pass/fail), and whether alignment passed. This granular data allows you to evaluate whether a sender is authentic or impersonating your domain. Tools like MailTester’s bulk verification use similar logic to test sender reputation and detect anomalies.

Finally, identifiers ties the technical result back to the actual message context: the From address, Return-Path, and envelope sender. This is critical for diagnosing spoofing attempts—e.g., when a message claims to be from your domain but the envelope sender points to a different domain. With this data, you can trace malicious actors or misconfigured senders more easily.

While RFC 9989 doesn’t specify storage or retention, consistent use of these fields makes it easier to build automated systems for monitoring DMARC compliance. You can see real-world examples of how these fields are used in practice through reports shared by major ISPs and security providers like IETF and Spamhaus. Understanding these components is the first step toward building stronger email security across your sender ecosystem.

Can old DMARC parsing tools still work with RFC 9989?

Most legacy DMARC parsing tools will struggle or fail with RFC 9989 reports because they rely on outdated XML structures that no longer apply. RFC 9989 introduces a mandatory JSON format with strict schema requirements, rendering tools that assume fixed XML fields or order largely incompatible without updates. You can’t safely parse modern reports with systems built for the older, more lenient XML standard.

Why XML-based parsers break with RFC 9989

Older DMARC tools were built around an XML schema that allowed flexible field order and optional elements. RFC 9989 removes that flexibility. Now, every report must be a valid JSON object with a defined structure—fields like report_id, date_range, and policy_published are required and must appear in a specific order. Parsers that expect XML or loose JSON will either reject the report or misinterpret data.

For example, a tool assuming a single <record> element will fail when it encounters a JSON array of records. Tools that didn’t validate schema structure may silently process invalid or malformed data, leading to inaccurate or incomplete insights. This isn't a minor bug—it's a fundamental shift in how reports must be processed.

What you need to fix it

You must update your parsing stack to handle structured JSON with strict schema validation. Use a schema-aware parser that checks every field, type, and nesting requirement. Tools like IETF RFC 9989 define this precisely. Without it, you risk missing critical data—such as alignment failures or policy changes—leading to poor security decisions.

Even systems that claim to support DMARC might not properly handle the new format. If you’re not validating against the official IETF specification, you’re operating blind. Let’s be clear: if your tool isn’t parsing JSON with a strict schema, it’s not fully compliant with current standards.

For teams managing email security or sending compliance, accurate parsing isn't optional. Misreading a DMARC report can leave your domain exposed to spoofing. Tools built around real-time detection—like MailTester’s inbox placement tests—already handle evolving standards. For bulk list validation and sender reputation checks, ensure your verification stack runs on updated, spec-compliant infrastructure. Use MailTester’s API to validate addresses against current delivery and security standards with 98.9% accuracy.

How should email senders prepare for RFC 9989 updates?

You should audit your DMARC report parsers, validate monitoring tools for JSON schema compliance, and test your processing pipeline with sample RFC 9989-compliant reports to ensure data integrity. The shift from XML to JSON is not optional—tools that can’t parse the new format will fail silently. Let’s walk through it.

Check your parsing infrastructure

  • Confirm your DMARC report parser supports JSON—RFC 9989 deprecates XML entirely. If you’re still relying on XML, you’ll miss incoming reports.
  • Validate schema compliance: the new format includes strict field definitions and optional elements like policy_published and auth_results. Tools that expect outdated field names or nesting will fail.
  • Use official test data from the IETF’s RFC 9989 spec—or real-world examples published by major providers—to verify your parser handles edge cases like missing record_id or non-standard policy_scope values.

Validate monitoring and alerting systems

  • Test whether your dashboards (via Grafana, Datadog, etc.) can ingest and display the structure of a compliant JSON report. The nested structure is more complex than XML—misaligned data can cause false negatives.
  • Ensure alerting rules don’t depend on deprecated fields or assume a fixed number of auth_result entries. The number of alignment checks can vary by domain and policy.
  • Run a smoke test using a sample report generated by RFC 9989—this is the official reference. Don’t assume your tooling works until you’ve tested with real input.
  • Monitor for missing disposition fields or unexpected failure_reason codes—these indicate alignment failures, which may signal spoofing attempts or configuration drift in your infrastructure.

The transition isn’t about feature updates—it’s about structural compliance. Tools that haven’t moved to JSON will stop receiving data entirely after adoption peaks. If you’re unsure how your stack handles reports, simulate real-world conditions with the test data from the IETF.

“The move to JSON isn’t just a format change—it’s a signal that DMARC is evolving into a more scalable, machine-readable system.”

Let’s say you’re managing hundreds of domains with varying policies. Running a few test reports isn’t enough—you need validation across all your senders. You can test DMARC report processing using a real email domain setup, or use an inbox placement tool to see how your outbound messages are treated: MailTester’s inbox tester shows how your messages land across major providers with full visibility into alignment and authentication status.

What happens if your domain sends RFC 9989 reports but you don't parse them?

If your domain sends DMARC reports in the new RFC 9989 format but you don’t parse them, you’re blind to authentication failures—especially from spoofing attempts or misconfigured third-party senders. Without processing these reports, you won’t detect when attackers impersonate your domain, nor will you catch legitimate senders sending emails that fail SPF or DKIM. This delay undermines your ability to enforce DMARC policies like quarantine or reject, leaving your domain vulnerable to abuse.

Missed signals mean delayed defense

DMARC reports in RFC 9989 are designed to help you detect policy violations in near real-time. If you ignore them, you lose this visibility. For example, a third-party vendor might start sending unauthenticated emails under your domain, and without parsing reports, you won’t know for days or weeks. By then, attackers may have already sent phishing messages to your customers.

This delay reduces your ability to enforce DMARC enforcement policies—especially when you’re relying on automated responses to report data. You’re essentially locking the barn door after the horse has left, if you don’t use the report feed as a real-time alert system.

Reputation damage follows

When malicious actors send emails using your domain name—even without your knowledge—it harms your sender reputation. ISPs and email providers track patterns of abuse. If your domain is associated with spoofed or unauthorized traffic, even if you didn’t send it, your reputation can degrade.

According to the Spamhaus Project, domains linked to unauthorized sending are more likely to be flagged by filtering systems. Without parsing RFC 9989 reports, you miss the signal to act. This means your clean domain may eventually face increased filtering or outright blocking.

Let’s be clear: sending reports doesn’t help if you don’t read them. RFC 9989 standardizes the format for a reason—to make it easier for domain owners to detect abuse. But the standard only works if you process the data. Tools like inbox placement testing and real-time verification can help you validate whether a domain is actively used for sending, which complements DMARC reporting.

If you’re sending RFC 9989 reports, ensure your team or system is set up to parse them. Otherwise, you're leaving your domain exposed. The data is there—it’s just doing nothing until you act.

How does MailTester help with RFC 9989 readiness?

You can validate your DMARC policy reporting format compliance using MailTester’s real-time API and inbox-placement tools, which automatically parse and validate RFC 9989-compliant reports. The in-app AI assistant helps diagnose parsing issues by identifying malformed fields or missing required entries, and bulk list verification detects addresses tied to domains with non-compliant policies—helping you act before enforcement begins.

Real-time parsing and validation for compliance

As email authentication evolves, RFC 9989 introduces stricter formatting requirements for DMARC aggregate reports. MailTester’s inbox-placement tester and real-time verification API are built to read and validate these new formats immediately—no manual parsing required. This means you can check if your domain’s DMARC alignment with reporting is accurate, even as standards shift.

When you send a test, MailTester checks your report’s structure against the RFC 9989 specification, flagging issues like missingsections, incorrectformats, or missing signature validation. You can see exactly where your reports fail, so you’re not guessing whether your DMARC setup is compliant.

In-app AI for troubleshooting and diagnostics

Some DMARC reports fail not because of policy misalignment, but due to malformed XML or missing required fields. Let’s say your report has an improperblock or a missingattribute—these are common in legacy or poorly configured systems. MailTester’s in-app AI assistant analyzes the full report and surfaces the exact field that’s causing issues, often within seconds.

It doesn’t just flag errors—it explains them in plain terms. For example, “Missingvalue” or “Invalid date format in” helps you fix the issue without digging through RFC 9989’s detailed specs.

The same AI can cross-reference report data with domain reputation systems and flag domains whose DMARC policies could harm deliverability—even if the policy is technically compliant.

Bulk verification for proactive risk mitigation

When you’re cleaning a list of 50,000 email addresses, you don’t want to find out later that some are from domains with non-compliant or overly restrictive DMARC policies. MailTester’s bulk verification checks each address against DNS records, including DMARC policies, to surface risks before sending.

Domains with no DMARC policy or overly strict policies (likereject) can result in hard bounces or inbox placement drops. Our system flags addresses tied to such domains, so you can clean your list early—improving send rates and protecting your sender reputation.

Start verifying with 100 free credits at MailTester's bulk verification tool. The integration with platforms like Mailchimp, HubSpot, and SendGrid makes it easy to automate checks for every campaign, ensuring your email program stays compliant as standards evolve.

What should you check in your DMARC report parser today?

Start with validating your parser’s support for the JSON format defined in RFC 9989. Ensure it checks for required top-level keys like report_metadata, policy_published, and record. Time fields must follow ISO 8601 with UTC offset (e.g., 2024-06-15T10:30:00Z). Verify that domains are strings, counts are integers, and alignment flags are booleans—this prevents parsing errors and ensures actionable data.

Top-level structure and required keys

  • Confirm the parser accepts JSON input and parses the root-level structure correctly.
  • Check that all required top-level keys are present: report_metadata, policy_published, and record.
  • Reject reports missing any of these keys—this indicates a malformed or incomplete DMARC report.
  • Use RFC 9989 as your authority for the expected schema.

Data type and format validation

  • Validate that the report_metadata.org_name field is a string, not a number or null.
  • Ensure report_metadata.date_range.begin and end use valid ISO 8601 timestamps with UTC offset (e.g., 2024-06-15T10:30:00Z).
  • Confirm record._policy_evaluated.pass is a boolean—false positives are a common parsing error.
  • Check that counts like record._policy_evaluated.disposition are integers, not strings or floats.
  • Use a tool like the official RFC 9989 specification to verify your parser adheres to the format.
Even small deviations in timestamp format or field type can break downstream analytics—consistency matters.

Let’s not underestimate the impact: unverified parsing leads to blind spots in your email security posture. If your parser can’t handle the updated format, you may miss unauthorized senders or fail to detect misconfigurations.

For teams managing bulk email sends, integrating DMARC validation with a trusted verification system helps uncover issues early. Try MailTester’s bulk verification to validate that domains in your list are not only valid but also compliant with current reporting standards. Use the real-time verification API to check individual addresses as they’re added. For advanced testing, inbox placement tests can reveal how your messages behave in real user inboxes—where DMARC alignment ultimately matters.

These checks aren’t just about parsing—it’s about ensuring that your security posture remains active, visible, and accurate in a changing email ecosystem.

How does RFC 9989 support better DMARC policy enforcement?

RFC 9989 standardizes DMARC policy reporting format, making it easier to parse and analyze authentication failures consistently across all sources. This uniformity allows domain owners to detect alignment issues with SPF and DKIM faster and more accurately, especially when multiple reports come from different mail providers. You can now act on violations in real time, improving inbox placement and reducing spoofing risks.

Consistent reporting improves failure detection

Before RFC 9989, DMARC reports varied widely in structure. Some included detailed alignment results, others didn’t. Now, with consistent formatting, tools can reliably extract and compare data across reports—whether from Google, Yahoo, or smaller providers. Let’s say you see multiple reports flagging a misaligned DKIM signature from a third-party service. With uniform data fields, you can correlate those findings quickly instead of manually hunting through inconsistent formats.

This consistency enables automation. You can set up alerts in your monitoring system that trigger only when violations appear in more than one report, reducing false positives. A single report might be noisy or flawed, but multiple aligned detections mean a real issue is likely present.

Clearer visibility into third-party email activity

One of the biggest challenges in DMARC is discovering which external services are sending email on your domain—especially when they fail authentication. RFC 9989 helps here by standardizing how sender IPs, domains, and authentication results are reported. That means you can more clearly trace which vendor or platform (like a CRM, marketing tool, or support system) is misusing your domain.

For example, if you see repeated reports where a service sends mail from your domain but lacks proper SPF or DKIM, you can now investigate those sources faster. This visibility doesn’t just stop attacks—it helps you clean up your own email ecosystem.

Even if you’re not using a DMARC analyzer, these reports are more actionable. Tools like MailTester’s inbox placement tester can surface alignment issues during delivery campaigns by simulating real-world sending environments, complementing DMARC data with deliverability insights.

The change isn’t about changing your policies—it’s about making your current policy enforcement smarter. Standards like RFC 9989 are what make automated, reliable email security possible at scale.

In summary: RFC 9989 is a step toward reliable email security

DMARC policy reporting format changes in RFC 9989 standardize feedback into a machine-readable JSON structure. This reduces ambiguity, speeds up analysis, and makes automated processing of alignment and authentication results far more reliable.

Senders who adopt the new format early gain clearer visibility into email delivery issues, reduce blind spots in reputation monitoring, and align with evolving security expectations across providers.

Robust verification and testing tools like MailTester ensure your email ecosystem remains compliant. With 98.9% accuracy and real-time validation, you can test and verify emails at scale — start with 100 free verifications.

Frequently asked questions

What is RFC 9989?

RFC 9989 is the latest internet standard that updates the format of DMARC aggregate reports to use structured JSON instead of variable XML, improving machine parsing and interoperability.

Does RFC 9989 affect all DMARC reports?

Yes, all domains sending DMARC aggregate reports must now follow the new format if they use the standard, though adoption may vary across senders and email providers.

Can I still use XML-based DMARC parsers?

Possibly, but only if the tool explicitly supports both XML and JSON. Many old systems will fail on new reports without upgrades.

What does RFC 9989 mean for sender reputation?

It improves the accuracy of detection for spoofing and authentication failures, allowing faster response and helping maintain sender reputation.

How do I test if my DMARC parser supports RFC 9989?

Use a sample JSON report from the IETF RFC 9989 appendix and feed it through your parser to verify field recognition and data extraction.

Is there a deadline for adopting RFC 9989?

No formal deadline exists, but early adoption ensures compliance as email providers increasingly expect structured reporting.

Are there risks in ignoring RFC 9989 changes?

Yes: undetected authentication issues, poor inbox placement, and reduced ability to enforce DMARC policy can hurt deliverability and security.

How does MailTester help with DMARC compliance?

MailTester provides inbox-placement testing, real-time email verification, and AI-driven analysis that helps identify domains behind misconfigured or non-compliant DMARC policies.

Do I need to change my DNS to adopt RFC 9989?

No. RFC 9989 modifies report format only. Your DMARC DNS record remains unchanged unless you’re adjusting policy.

Can old email providers still send RFC 9989 reports?

Adoption is growing, but not all providers have updated their reporting. Monitoring systems must handle both XML and JSON until full transition.

Does RFC 9989 affect individual email deliverability?

Not directly. It affects domain-level reporting and monitoring, which indirectly supports better delivery by ensuring authentication is properly enforced.

What is a DMARC aggregate report?

It’s a daily summary of email traffic claiming to come from your domain, including SPF and DKIM results, alignment, and message counts.

Sources

Keep reading