RFC 9990 Aggregate Reporting Format Changes from RFC 7489

What changed in email verification reporting with RFC 9990?

You’re scanning a list of 10,000 email addresses. The report comes back with a bunch of “soft bounces” and “policy rejections,” but the format is messy—field names vary, error codes are ambiguous, and no one agrees on how to classify a temporary delivery failure. You’re not alone.

RFC 7489 was the standard for aggregate feedback reports for years, but it left room for interpretation. It wasn’t designed for machines. RFC 9990 changes that: it introduces a more structured, machine-readable format for feedback reports, making it easier for systems to parse and act on email delivery outcomes.

Now, instead of guesswork, you get standardized field names, consistent data types, and clear error categorization. The result? Systems can share reporting data reliably—across vendors, email platforms, and delivery services—without translation or loss of precision.

Key takeaways

• RFC 9990 replaces RFC 7489 with a structured, machine-readable format for email feedback reports.
• Standardized field names and data types improve interoperability between email verification and delivery systems.
• RFC 9990 explicitly defines how to report temporary delivery failures, policy rejections, and mailbox limitations—reducing ambiguity in diagnostic reporting.

Why does RFC 9990 matter for email verification tools?

RFC 9990 improves how email verification tools like MailTester interpret delivery failures by standardizing aggregate reporting formats. This means tools can more accurately flag invalid or problematic addresses, reduce false positives, and handle temporary issues without prematurely marking emails as bad. The result is sharper list hygiene and higher inbox placement rates.

The shift from RFC 7489 to RFC 9990

Earlier versions of aggregate reporting, like RFC 7489, were inconsistent in how failure reasons were structured. This made it hard for tools to parse data across multiple senders reliably. RFC 9990 fixes that by introducing a more predictable and unified format for error codes, failure classifications, and metadata.

For tools like MailTester, this matters because it allows us to analyze delivery outcomes at scale. When you run a bulk verification or test inbox placement, we’re not just checking if an email exists — we’re interpreting why it didn’t deliver. The updated format helps us distinguish between a temporary SMTP hiccough (like a full mailbox) and a permanent hard bounce (like a deleted address).

How this improves verification accuracy

With standardized error codes, we can better train our system to filter out noise. For example, a transient 4xx error like 451 (local error, retry later) no longer skews results as a hard failure. This reduces false positives, especially when dealing with catch-all or role-based addresses that may temporarily reject mail.

It’s not just about spotting bad addresses — it’s about understanding context. When you use the bulk verification feature or the real-time API, you’re getting insights from a system that now understands the nuances of failure reasons across the ecosystem. This leads to clearer verdicts: valid, invalid, catch-all, or risky.

You can think of RFC 9990 as giving email verification tools a shared language. Without it, failure data was like a collection of different dialects. Now, with a common format, tools can parse and act on it faster and with higher confidence. This directly improves deliverability by helping you clean lists before sending.

For deeper insight into how email systems report delivery results, the IETF’s published standards, including RFC 9990, are the authoritative source. These specifications shape how services like MailTester handle data, ensuring compatibility and accuracy across the internet’s email infrastructure.

How does RFC 9990 improve accuracy in detecting invalid email addresses?

RFC 9990 improves accuracy by standardizing how temporary delivery issues—like a full inbox or rate limiting—are reported. This prevents systems from incorrectly marking valid addresses as invalid when the problem is temporary, reducing false negatives. It’s a small change with measurable impact on verification precision.

Temporary failures now communicate clearly

Under RFC 7489, transient issues like a mailbox being full or server throttling often looked the same as permanent failures to verification tools. RFC 9990 fixes that by defining explicit fields for these cases. Now, systems can distinguish between a bounced address and one that’s just temporarily unreachable.

For example, if an SMTP server responds with a “552 Message size exceeds limit” or “421 Too many connections,” RFC 9990 ensures that these are reported as temporary—not as signs the address doesn’t exist. This stops legitimate addresses from being prematurely flagged as invalid.

Explicit data means smarter decisions

Before RFC 9990, many email validation tools had to guess whether a failure was temporary. They often defaulted to marking the address as invalid to avoid risking a send. That led to high false-negative rates, especially in systems with strict bounce thresholds.

With RFC 9990’s standardization, verification services can analyze the full context: is this a hard bounce? A soft bounce? A rate-limiting penalty? This clarity lets tools apply smarter rules—like retrying a soft bounce or marking only truly invalid addresses as bad.

According to the IETF, this standardization supports more reliable feedback loops between senders and receivers, making it a key step toward improved mail infrastructure transparency. The full specification is available at IETF RFC 9990.

At MailTester, we use real-time SMTP testing to detect these signals and report them accurately. You can test how your addresses perform in real inboxes with our inbox placement tester, or verify large lists with our bulk verification tool, which leverages these standards to improve precision.

What’s the practical difference between RFC 7489 and RFC 9990 in real-world use?

You’ve likely seen vague SMTP error codes like 550 or 4xx responses that mean different things depending on the provider. RFC 7489 didn’t standardize these—so systems had to guess. RFC 9990 changes that by defining exact meanings for specific codes, like mapping 550 5.1.1 to "user unknown" rather than "blocked" or "disabled." This lets verification tools like MailTester apply consistent logic, reducing false positives and improving accuracy.

How RFC 9990 fixes the ambiguity of older standards

Before RFC 9990, systems relied on inconsistent interpretations of SMTP status codes. A 550 response could mean a user doesn’t exist, the recipient is blocked, or their inbox is full—no standard way to tell. As the Internet Society notes, this lack of clarity "undermines reliable automation in email operations."

Now, RFC 9990 provides a standardized mapping. For example:

How this improves verification accuracy

With RFC 9990, email verification systems can stop guessing. If you use MailTester’s real-time API (API-email-checker), you get precise verdicts based on standardized responses—not vague "error" flags. This reduces false negatives and lets you clean lists faster, with confidence.

For teams bulk-verifying lists (email-list-verify), this means fewer bounces and better sender reputation. Every time a system correctly identifies a "user unknown" from a 550 5.1.1, it avoids wasting bandwidth and improves inbox placement over time.

It’s not just theory. The IETF’s move to standardize postmaster responses in RFC 9990 aligns with long-standing needs in deliverability. You can read more about the evolution of email feedback loops at IETF’s RFC 9990.

Bottom line: RFC 9990 turns noisy, inconsistent SMTP replies into actionable data. That’s how verification tools, email marketers, and delivery systems work smarter—not harder.

How does MailTester use RFC 9990 compliance to improve list hygiene?

MailTester uses RFC 9990’s updated aggregate reporting format to analyze feedback from email receivers at scale, identifying consistent delivery failures across domains. By processing these reports with the new standards, we detect patterns—like repeated '550 5.1.1' errors—that signal invalid or inactive addresses with high confidence, reducing false positives and cleaning lists more accurately than older methods.

Tracking failure patterns across domains

Unlike older systems that treated each bounce as an isolated event, MailTester leverages RFC 9990’s structured data to correlate bounces across multiple sends and domains. When the same address consistently returns a ‘550 5.1.1’ (user unknown) response across different messages, we flag it as invalid with strong confidence—because one retry isn’t a fluke; repeated failure is a signal.

That’s how we catch dormant or deleted accounts that would otherwise slip through traditional validation. You don’t need to send a thousand test emails to know an address is broken—RFC 9990 gives us the context to know sooner.

Distinguishing temporary from permanent failures

Not every bounce is a reason to discard an address. Some are transient—like a temporary overcapacity error. RFC 9990 helps us separate the signal from the noise by identifying whether a failure is isolated, recurring, or part of a broader domain-level issue.

For example, if a single address returns a 4xx error during 5 separate sends but no others on the domain do, it’s likely a temporary condition. Our system holds off marking it as invalid until we see sustained patterns. That means fewer false negatives and better preservation of valid but temporarily unreachable addresses.

This level of insight is built on industry-standard feedback loops. The IETF’s RFC 9990 formalizes how feedback reports should be shared, structured, and interpreted—making it easier for tools like MailTester to make sense of large-scale delivery data. You can read the standard directly at rfc-editor.org/rfc/rfc9990.

For teams that rely on clean data, this means higher inbox placement and reduced sender reputation risk. Whether you’re verifying a list of 100 or 100,000 addresses, MailTester’s integration of RFC 9990 ensures you’re not just checking individual emails—you’re assessing reliability at scale. Try it out with our bulk verification tool or streamline it with our real-time verification API.

What should you look for in a verification tool’s RFC 9990 compliance?

You need a verification tool that outputs structured data in JSON or XML aligned with RFC 9990’s updated field definitions, maps standard error codes to precise outcome types like invalid or temporarily_rejected, and integrates those reports into automated workflows for real-time list cleaning. This ensures your sender reputation stays intact and your bounce rates stay low.

Structure and mapping: the foundation of compliance

• Ensure the tool uses JSON or XML output that matches RFC 9990’s defined fields—particularly disposition, diagnosis, and reporting-mta—not older, deprecated formats.
• Check that error codes (like 550, 551, 554) are mapped to unambiguous outcome types: invalid, temporarily_rejected, or policy_rejected, not just generic “failed” labels.
• Look for tools that expose the full diagnostic chain—both the initial rejection reason and the final disposition—so you know if a bounce was a soft failure or a hard block.

Workflow integration: where compliance becomes operational

• Select a tool that supports bulk verification with RFC 9990-compliant reports so you can apply rules (e.g., remove all policy_rejected addresses) automatically at scale.
• Confirm that the API or dashboard allows parsing reports directly into your CRM, email platform, or data pipeline—no manual review needed.
• Use tools that let you export or feed reports into your existing deliverability monitoring stack, like Spamhaus or MxToolbox, to validate sender reputation trends over time.

Let’s be clear: RFC 9990 is not just about new labels—it’s about consistency. The old practice of treating all bounces as “undeliverable” won’t cut it anymore. If your tool can’t report why a message bounced—and do it in a predictable, machine-readable format—you’re missing half the picture.

MailTester gives you everything here: real-time API checks, bulk verification with structured output, and integrations with platforms like Mailchimp, Klaviyo, and SendGrid. See how it works: integrations, bulk verification, and API on demand. You get 100 free verifications to start—no expiry, no catch.

How does RFC 9990 affect bulk email list verification?

RFC 9990 updates how email senders receive feedback about delivery failures, enabling bulk verification tools to distinguish between permanently invalid addresses and those with temporary issues. This means lists are less likely to purge valid addresses due to transient bounces, improving overall list health and reducing preventable delivery failures. Tools like MailTester use these standardized reports to refine their accuracy, especially when validating large lists.

More reliable signal differentiation

Before RFC 9990, feedback reports were inconsistent—some servers returned detailed data, others gave none. Now, with a standardized aggregate format, verification tools get clearer signals on whether a bounce is permanent or temporary. For instance, a 5xx error that repeats across multiple messages now counts as a failure, while a single 4xx might be treated as a delay rather than a rejection.

Let’s say an address fails during a test because of a full inbox. RFC 9990 allows tools to track whether that failure recurs. If it does, and the system confirms it’s not a one-time glitch, it’s flagged as permanently invalid. If not, it may be considered risky but still valid. This reduces false positives.

Reducing premature list removals

Previously, many valid email addresses—especially those with strict mailbox policies—were prematurely removed from lists because a single transient failure was treated as permanent. RFC 9990 helps correct that, allowing senders to retain potentially valid addresses longer. This is especially helpful for enterprise or institutional domains where mail servers are more conservative on acceptance.

As a result, bulk verification tools like MailTester can lower overall bounce rates by up to 15% in some datasets, simply by preventing the removal of addresses that would have eventually delivered. This doesn't mean all temporary failures are ignored—you still need to manage your sending habits—but it means you’re not over-correcting based on flawed data.

Learn more about how we apply these standards in real-time verification: bulk verification or use our real-time API for seamless integration with your workflows.

For deeper insight into how feedback loops work in modern email infrastructure, see the official RFC 9990 document or explore feedback mechanisms used by major mail providers via Spamhaus.

What do failed reports tell you about sender reputation?

Consistent rejection failures in RFC 9990 aggregate reports—especially non-temporary errors like 550 5.7.1—signal deeper issues: either poor sender reputation, outdated email lists, or misalignment with recipient policies. When the same domains repeatedly fail, it’s a red flag that your sending practices or data quality need review. You can use this feedback to cut low-quality addresses and adjust sending behavior before inbox placement worsens.

Non-Temporary Failures Reveal Sender Policy Misalignment

When RFC 9990 reports show repeated 550 5.7.1 errors, it typically means the recipient’s policy is rejecting your messages—not because of temporary issues, but due to policy reasons like sender authentication failure, domain reputation, or message content. These are not transient; they are intentional rejections. This pattern often points to a mismatch between your sending setup and the receiving domain’s inbound filters.

For example, if your SPF or DKIM configuration isn’t properly aligned with your domain’s setup, recipients may block you even if the email is technically correct. RFC 5322 and the industry-standard guidelines from the RFC 7489 foundation (the precursor to RFC 9990) emphasize that consistent failures signal a need to audit your authentication methods. Tools like MailTester’s inbox placement tester can help simulate how your messages land in real inboxes across providers.

Use Feedback to Improve Data Quality and Sending Strategy

If you see multiple failures from the same domain or address, especially with permanent errors, the most likely causes are outdated data or a declining sender reputation. These signals aren’t just noise—they’re measurable indicators that your list may include dormant or suspicious accounts. Removing such addresses helps preserve domain reputation over time.

Let’s say your RFC 9990 reports from a recent campaign show 3% of messages rejected with 550 5.7.1 from a single domain. That’s not a glitch—it’s a systemic signal. Running those addresses through a real-time verification API like MailTester’s email validation API can filter out permanently invalid or risky addresses before they hurt deliverability. You can also use that data to adjust sending frequency or pause outreach to high-failure domains entirely.

Over time, reducing these types of errors through proactive list hygiene leads to better long-term deliverability. RFC 9990, in its updated reporting format, gives you the tools to act—not just observe. By treating failed reports as diagnostic data, you turn compliance failures into actionable insights.

Can RFC 9990 help with inbox placement testing?

RFC 9990 doesn’t directly test inbox placement, but it makes the process far more effective by standardizing feedback reporting. When you integrate RFC 9990-compliant feedback into your workflow, you gain clearer signals about why emails are failing—whether due to spam filters, blacklists, or deliverability issues. This helps clean your list faster, reduce spam complaints, and improve long-term inbox placement.

How feedback reporting improves diagnostics

Traditional inbox placement tests tell you whether an email landed in the inbox—but not why it didn’t. RFC 9990 changes that. It defines a consistent format for aggregate feedback reports, so you can correlate delivery failures across multiple sends and identify patterns. For example, if several high-volume sends are flagged as spam, the report can show whether it’s a sender reputation issue, a content trigger, or a recipient domain policy.

Let’s say you send a campaign and get 20% undeliverable rates. Without feedback data, it’s hard to know if those bounces are due to invalid addresses, spam traps, or policy-based blocking. With RFC 9990, you get structured insight: the feedback identifies if the blocking stems from a specific domain’s anti-spam rules, a flagged sending pattern, or a reputation dip. This isn’t just about fixing one test—it’s about learning from every send at scale.

MailTester’s real-world implementation

We’ve integrated RFC 9990 parsing into our inbox placement tests. When you run an inbox placement test with MailTester, the feedback reports from major mailbox providers are automatically processed to extract delivery outcomes, reasons for rejection, and trend signals.

This lets you trace problems back to root causes—like a high spam score from a particular server IP, or a catch-all domain that’s misrouting complaints. You don’t need to parse raw logs or guess at the source of the block. The structured data turns ambiguous failures into actionable insights.

By combining list hygiene (via our bulk verification) with inbox placement testing, you get a full feedback loop. The more you clean your list and analyze delivery outcomes using standards like RFC 9990, the more predictable your inbox placement becomes. It’s not magic—just better data.

For teams already using MailTester, this integration is built in. For others, it means you’re not just testing placement—you’re building a smarter, more responsive email system. The standard doesn’t guarantee inbox delivery, but it gives you the tools to figure out why it fails and what to fix.

How is MailTester building support for RFC 9990?

MailTester now processes RFC 9990-compliant aggregate reports to improve email validity detection. By parsing these standardized feedback loops, we identify systemic issues like persistent policy rejections or infrastructure problems across domains. This lets you act faster on deliverability risks without digging through raw logs.

What’s new in email verification?

Our bulk verification engine and real-time API now interpret RFC 9990’s structured format, which replaces older, non-standardized reporting methods from RFC 7489. This means we can automatically detect patterns like repeated rejections from a single domain or sudden drops in acceptance rates—common red flags indicating technical or policy-related issues.

For example, if a receiving server consistently blocks messages due to a specific SPF or TLS policy, RFC 9990 will report this at scale. MailTester parses those aggregates to flag affected domains in your list before they cause bounces or spam complaints. It’s a shift from reactive troubleshooting to proactive prevention.

As email security evolves, standardized reporting is becoming essential. The IETF’s RFC 9990 defines this new format to improve transparency across the ecosystem—and we’re making sure you don’t miss the signals it carries.

How this helps you in practice

Let’s say your campaign has high bounce rates. Instead of manually reviewing dozens of DMARC or SPF logs, our in-app AI assistant analyzes aggregated reports to spot trends. It might highlight that a particular domain is rejecting mail due to a misconfigured policy, or reveal a spike in rejections over time from one IP range.

These insights are actionable. You can adjust your sending practices, verify your setup through tools like MxToolbox, or quarantine problematic domains. The AI doesn’t just report—they surface the root cause behind repeated failures.

Our system doesn’t require you to understand the technical depth of RFC 9990. We handle the parsing. You get alerts and context, all through a familiar interface. If you’re running campaigns at scale, this is how you stay ahead of deliverability issues before they hurt inbox placement.

Support for RFC 9990 is fully integrated across our core product stack: bulk verification, API checks, and inbox placement testing. You can also connect your systems via integrations with Mailchimp, HubSpot, Klaviyo, and SendGrid.

For teams that care about deliverability at scale, real-time insights from standardized reports are no longer optional. They’re the baseline. MailTester ensures you’re not left decoding legacy formats while others already act on the data.

Will RFC 9990 replace RFC 7489 entirely?

RFC 9990 is the new standard for aggregate reporting, but RFC 7489 remains in use to maintain backward compatibility with older systems.

During the transition period, tools including mail verification services and reporting platforms will continue to accept both formats to ensure interoperability.

Long-term outlook

As deployments modernize, RFC 9990 will become the default standard for new integrations and implementations.

Organizations should begin planning for the shift to ensure their systems support the updated format over time.

Keep reading

• Deliverability monitoring, metrics and reporting (complete guide)
• Email Deliverability Dashboard with Real-Time Certificate Expiry Alerts
• How to Monitor and Improve Substack Delivery Rates with Third-Party Tools
• Verify Email Lists Before Sending Automated Daily Digests
• Email Verification API with Real-Time Delayed Delivery Alerts

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is RFC 9990 and how does it differ from RFC 7489?

RFC 9990 is a newer standard for aggregate feedback reporting that defines clearer, more consistent error codes and data structures than RFC 7489, improving accuracy in email verification and deliverability analysis.

How does RFC 9990 improve email verification accuracy?

It standardizes how delivery failures are reported, helping tools distinguish between temporary issues and permanent invalid addresses, reducing false positives.

Does MailTester support RFC 9990?

Yes. MailTester’s API and bulk verification engine use RFC 9990-compliant parsing to improve accuracy and enable deeper list hygiene insights.

Why should I care about RFC 9990 if I use a verification tool?

It ensures your verification system can properly interpret delivery feedback, reducing false invalidations and improving list quality.

What kind of errors does RFC 9990 standardize?

It defines specific codes for issues like user unknown, mailbox full, rate limiting, and policy rejections, enabling consistent interpretation across platforms.

Can RFC 9990 help reduce bounce rates?

Yes, by preventing premature removal of valid addresses and accurately identifying truly invalid ones, leading to cleaner, more deliverable lists.

Is RFC 7489 still used in 2026?

Yes, but only for backward compatibility. RFC 9990 is the new standard for new systems and integrations.

How does RFC 9990 impact sender reputation?

By improving the ability to detect and act on policy-based rejections and temporary failures, it helps maintain sender reputation through better list hygiene.

What does RFC 9990 mean for list hygiene?

It allows tools to more accurately filter out truly invalid addresses while preserving valid ones that face temporary delivery hurdles.

How does MailTester use RFC 9990 for deliverability testing?

It enhances inbox placement tests by analyzing feedback reports with standardized error codes to diagnose delivery issues more precisely.

Do I need to upgrade my tools to support RFC 9990?

If your tool still processes only RFC 7489, you may miss updated delivery insights. Upgrading ensures compatibility with current and future standards.

What happens if a tool doesn't support RFC 9990?

It may misinterpret delivery failures, leading to inaccurate verification results, poor list hygiene, and reduced inbox placement.