What does RFC 9990 actually fix in email verification compared to RFC 7489?

You run a bulk verification on 100,000 email addresses. The tool returns a report. But the format isn’t consistent. One row says "valid", another says "delivers", a third says "unknown". How do you know the difference? And how do you build a reliable system when every tool interprets results differently?

RFC 7489 gave us the basics: a way to say if an email is valid or not. But it didn’t define how to report results from massive lists. That left every tool to make up its own format — a mess for automation, a trap for accuracy. RFC 9990 fixes that by standardizing how aggregate validation data is structured.

Now, tools like MailTester’s bulk verification engine can process high-volume results without custom parsing logic. The data flows consistently across systems — one format, one meaning. Accuracy improves because handling errors caused by misinterpretation goes down.

Key takeaways

  • RFC 9990 defines a standardized data model for reporting bulk email verification outcomes, reducing the need for custom parsing.
  • Unlike RFC 7489, which only addressed individual address validation, RFC 9990 enables reliable aggregation of results at scale.
  • This standardization improves downstream data reliability in deliverability tools, analytics platforms, and CRM integrations.

Why should email list hygiene teams care about RFC 9990?

Team leads managing email lists need RFC 9990 because it standardizes how tools report invalid, catch-all, and risky email addresses. Before it, every verification vendor used different definitions and formats, making cross-tool comparisons useless and cleaning pipelines inconsistent. Now, with RFC 9990, a “catch-all” verdict from one system reliably matches the same behavior in another—enabling trust, automation, and compliance across your email operations.

The mess before RFC 9990

Without a common standard, each email verification tool reported results in its own way. One tool might label a domain as “catch-all” if it accepts any address. Another might only flag it if it accepts non-existent users but doesn't bounce. This meant that a “valid” address in Tool A could be “risky” in Tool B, even if they tested the same email.

When you ran multiple tools for verification or reported to regulators, this inconsistency caused confusion. You couldn’t aggregate data or build clean, automated workflows knowing that "catch-all" meant different things across systems. Audit trails became fragile. Compliance reporting failed to align. Teams wasted time reconciling conflicting results.

How RFC 9990 fixes it

RFC 9990 introduces a consistent, machine-readable model for aggregating verification results. It defines clear, shared meanings for verdicts like invalid, catch-all, and risky. This isn’t just a technical formality— it means your team can now trust that a “catch-all” result from one tool will behave identically in another, especially when you’re comparing or combining data.

The standard is already in use by email infrastructure providers and verification services. You can see it in action in IETF’s official documentation, which outlines the data model for future interoperability in email deliverability systems. It’s not about a single tool—it’s about building ecosystems where verification results are consistent, predictable, and reliable across platforms.

For teams using tools like MailTester, this standard is built into our API and bulk verification workflows. You’re not just checking one address—you’re generating clean, standardized data that can be shared, reported, and acted on with confidence. If you’re automating list hygiene or integrating with marketing platforms, RFC 9990 means fewer false positives, fewer manual reviews, and better inbox placement over time.

How does RFC 9990 improve accuracy in bulk email verification?

RFC 9990 improves bulk email verification accuracy by defining standardized fields—like total checks, valid, invalid, catch-all, risky, and transient outcomes—that ensure consistent reporting across systems. This allows you to spot anomalies early, such as a list claiming 95% validity but showing a catch-all rate over 50%, which typically signals misconfigured tests or artificial data. By adopting this standard, tools like MailTester can validate their own processes against a known benchmark, reinforcing trust in results.

Why standardizing outcome fields matters

Before RFC 9990, different vendors reported verification results using their own labels and definitions. One tool might call "catch-all" "accept-all," while another counted temporary failures as "invalid." This made cross-system comparisons nearly impossible. RFC 9990 fixes that by unifying the language of email verification outcomes, so when you see a “risky” or “transient” status, you know exactly what it means—no guesswork.

Let’s say you're processing a 10,000-email list and get back 9,500 valid addresses. That looks good—until you notice the catch-all rate is 61%. That’s impossible in real-world email infrastructure and a clear sign of flawed data collection or API misuse. RFC 9990 makes these red flags visible early because the model forces consistency in how each result is captured and reported. Systems can now automatically flag inconsistencies, reducing false confidence in large-scale lists.

How MailTester uses RFC 9990 to maintain 98.9% accuracy

At MailTester, we use the RFC 9990 aggregate data model not just as a reporting format, but as a validation tool for our own verification engine. Every bulk check we run outputs data in the standard fields—total checks, valid, invalid, catch-all, risky, transient—so we can cross-check our internal logic against a known industry benchmark.

This self-consistency check helps us catch misconfigurations, misclassified responses, or flawed API integrations before they impact users. For instance, if our system starts reporting unusually high catch-all rates across multiple domains, we can investigate whether a particular DNS query is misbehaving. This level of auditability is what underpins our 98.9% verification accuracy claim.

As email verification scales, reliable data reporting isn’t a luxury—it's a necessity. For teams running campaigns at scale, using tools grounded in RFC 9990 means you can trust your metrics, identify problems faster, and avoid wasting resources on invalid addresses. You’re not just validating emails; you’re validating the validation process itself.

Learn how MailTester applies this standard in production: verify large lists with trusted, RFC-compliant accuracy.

What’s the real-world impact of RFC 9990 on email deliverability?

RFC 9990 improves email deliverability by standardizing how tools detect invalid, role-based, and non-existent addresses. This reduces bounces, protects sender reputation, and increases inbox placement—especially when paired with tools that validate at scale, like MailTester’s bulk verification.

Why list hygiene matters for deliverability

You’re not just sending to people who exist—you’re sending to systems that judge your trustworthiness. Invalid or role-based emails like sales@ or info@ generate hard bounces, which signal to inbox providers that your list is unreliable. Each bounce degrades your sender reputation, even if only a small fraction of your list is bad.

Sender reputation isn’t just about spam complaints—it’s about consistency. Bounce rates above 2% often trigger red flags with ISPs. If your list includes many addresses that don’t resolve, even with good content and alignment, your messages risk filtering into folders or getting blocked entirely.

How RFC 9990 improves detection across tools

RFC 9990 refines the validation process by defining clearer, more consistent rules for identifying issues like nonexistent domains, role addresses, and catch-all configurations. This means verification tools can now better distinguish between a real address and a trap, such as [email protected] when that domain doesn’t exist.

Tools that comply with RFC 9990 are more likely to flag role accounts consistently, reducing the chance of sending to support@ or webmaster@ on domains with no corresponding mailbox. This matters because those types of addresses are not only low engagement but can also trigger automated blocklist entries when used frequently.

If you’re sending to a list with high rates of catch-all or role-based addresses, your domain’s reputation pays the price. Tools that use the aggregate data model from RFC 9990 can detect these patterns more reliably than earlier models, especially when fed real-time feedback loops.

When you combine this validation with inbox placement testing, you’re not just cleaning your list—you’re simulating how real recipients will receive your message. Tools like MailTester’s inbox tester check whether your email lands in the primary inbox, not the clutter folder, across major providers like Gmail, Outlook, and Apple.

For teams running high-volume campaigns, validating at scale with a reliable system is essential. MailTester’s bulk verification ensures you’re not sending to dead ends or fake addresses. And because every credit you buy never expires, you can maintain consistency without worrying about renewals.

For the full picture of how email infrastructure evolves to support better deliverability, the technical foundation is laid in the IETF’s RFC 9990. It’s not just theory—its impact is measurable in inbox placement rates, bounce reduction, and long-term sender health.

How does RFC 9990 handle transient and greylisted results?

Unlike RFC 7489, which offered little guidance on transient responses, RFC 9990 explicitly defines how to report temporary errors—like greylisting or timeouts—and includes retry mechanisms with defined timeout contexts. This allows systems like MailTester to distinguish between a temporary block and a permanent failure, enabling smarter handling of addresses that may be valid but temporarily unreachable. You can now act on these results with confidence, knowing whether a bounce is short-lived or a sign of a dead address.

Why RFC 7489’s approach fell short

Under RFC 7489, transient results—such as a 4xx or 5xx SMTP reply due to greylisting—were often treated as hard errors or ignored altogether. Many tools either marked the address as invalid or failed silently, leading to false positives. The lack of standardized handling meant inconsistent behavior across systems, reducing reliability for bulk sending operations where false positives hurt deliverability.

How RFC 9990 fixes this

RFC 9990 introduces structured reporting for transient conditions using specific status codes and a retry-after value. This lets a verification system know not just that a server is rejecting the request, but when to try again. For example, if a server responds with a 4xx error and specifies a 300-second retry delay, a compliant system like MailTester can queue the address for re-checking later. This reduces unnecessary churn and avoids marking deliverable addresses as invalid.

Greylisting, a common practice where servers temporarily reject emails to filter spam, is now explicitly supported in the model. Instead of treating a temporary rejection as a failure, systems can now understand it as a signal to wait. This is especially useful in high-volume verification workflows, where a 1–10% failure rate from greylisting under RFC 7489 would’ve been misclassified as invalid.

MailTester leverages this by integrating retry logic into its bulk verification and real-time API. You can see in the verification results when an address is flagged as "potentially valid—retry later" rather than "invalid." This improves the accuracy of your list cleanup and reduces the risk of prematurely dropping valid users.

For more on how this translates into better deliverability, explore how our [real-time verification API](https://mailtester.com/api-email-checker/) handles these cases at scale. You’re not just checking if an email exists—you’re learning how likely it is to receive your message, even if it’s behind a temporary gate.

For deeper context, refer to the official RFCs: [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990) and [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489).

What does RFC 9990 mean for integrations with Mailchimp, Klaviyo, and SendGrid?

RFC 9990 standardizes how email verification tools report results, so when you verify a list with MailTester and export it to Mailchimp, Klaviyo, or SendGrid, the meaning of “valid” or “risky” stays consistent across platforms. No more surprises from mismatched definitions, which means cleaner imports, fewer bounces, and more reliable deliverability.

Consistency starts with shared definitions

Before RFC 9990, each email verification service used its own logic for labeling addresses—some counted catch-alls as valid, others didn’t. That meant a list flagged as “clean” by one tool might still contain hard bounces when imported into Mailchimp or SendGrid. Now, with RFC 9990, MailTester uses a standardized model to report exactly what the data means, reducing ambiguity.

Let’s say you verify 10,000 addresses using MailTester’s bulk verification. Under RFC 9990, the results include clear, machine-readable labels like “valid,” “invalid,” “catch-all,” or “risky”—with consistent definitions that align with how major ESPs interpret them. This means when you push that list to Klaviyo, you’re not guessing whether the “valid” entries will actually deliver. You’re confident they will.

Seamless syncs, fewer manual fixes

Without standardized reporting, teams spend hours reviewing and cleaning lists after export. Now, with RFC 9990, verified lists flow directly into Mailchimp, SendGrid, or Klaviyo with predictable outcomes. You’re not just avoiding bounces—you’re avoiding the wasted effort of rebuilding campaigns because a segment got flagged as invalid during import.

For instance, if a mailing list contains a high number of role accounts (like support@ or info@), RFC 9990 allows MailTester to flag them as “risky” rather than “valid”—and that status carries through to your ESP. That keeps your sender reputation intact, since those addresses often don’t engage but still count as open rates.

The standard also supports better analytics. When you test inbox placement with MailTester’s inbox tester, you're not just seeing if an email arrived—it’s tied to a consistent data model that helps you interpret why it did or didn’t. This is especially helpful when diagnosing deliverability issues across platforms.

RFC 9990 is not a magic fix, but it removes one layer of friction from integrations. As email ecosystems grow more complex, having a shared language for verification is no longer optional—it’s essential. You can see the model in action at the official IETF specification.

What are the technical changes in RFC 9990 compared to RFC 7489?

RFC 9990 improves upon RFC 7489 by introducing a structured JSON schema for aggregate results, standardizing status codes for invalid, catch-all, risky, and unknown addresses, enabling optional metadata like verification timestamp and error hierarchy, and supporting machine-readable audit trails for debugging and compliance. These updates make email validation data more consistent, reliable, and interoperable across systems.

How these changes improve email validation workflows

  1. Adopt a structured JSON schema for aggregate results. Instead of relying on unstructured or inconsistent formats, RFC 9990 specifies a clear JSON structure for batch validation responses. This means tools like MailTester’s bulk verification can process results predictably, reducing parsing errors and integration complexity.
  2. Standardize status codes across the industry. RFC 9990 defines precise, consistent codes for invalid, catch-all, risky, and unknown. This removes ambiguity—where one system says “invalid,” another calls it “risky”—and allows tools to act on results with confidence, not guesswork.
  3. Include optional metadata for traceability and debugging. You can now embed timestamps, source system identifiers, and detailed error hierarchies in responses. This is critical when auditing deliverability failures or validating compliance with internal policies. The added context makes troubleshooting much faster and more reproducible.
  4. Enable machine-readable audit trails. With standardized data and embedded metadata, systems can automatically log and analyze validation outcomes. This supports compliance with regulations like GDPR or CCPA, where you may need to prove data accuracy or provide logs of prior verification attempts.

Why this matters for real-world email operations

Let’s say you're cleaning a list before a campaign. With RFC 7489, you might get a mix of vague status responses. With RFC 9990, every email returns a consistent code, timestamp, and error type—making it easy to filter out invalid addresses or track why certain domains are flagged as risky. This consistency reduces bounce rates and protects sender reputation.

These improvements aren’t just theoretical. The IETF, which maintains these standards, emphasizes interoperability as a core principle. Tools that follow RFC 9990 can exchange data seamlessly—no custom parsing required. For businesses using email verification at scale, this means fewer failed campaigns and smoother integration with systems like Mailchimp, HubSpot, or SendGrid via a reliable real-time API. You’re not just checking an address—you’re collecting actionable, standardized intelligence.

Why hasn’t RFC 9990 been widely adopted yet?

RFC 9990 hasn't seen broad adoption because it requires updates to verification tools and APIs across the ecosystem—many legacy systems still output data in proprietary formats, and without standardization, results from different tools aren’t comparable or auditable. Until vendors invest in compatibility, progress remains slow.

API and tool vendors are the bottleneck

Even though RFC 9990 defines a clean, machine-readable data model, adoption hinges on API providers updating their infrastructure. If your verification tool doesn’t natively support the standard, you’re stuck with opaque output that’s hard to parse or integrate into downstream systems. This creates friction, especially when teams need to validate or audit list hygiene across multiple vendors.

Legacy systems lock in incompatible formats

Many older verification engines were built before standardized output became a priority. They return results in custom schemas—sometimes just “valid” or “invalid”—with little context on why an address failed. Without a common structure, it’s nearly impossible to analyze aggregate data or troubleshoot delivery issues consistently. Tools that haven’t adopted RFC 9990 produce reports that are effectively siloed.

Let’s be clear: without universal support, RFC 9990 remains a specification without widespread influence. Industry players like IETF’s DMARC working group and email deliverability experts consider standardized output essential for transparency, but change moves at the pace of engineering priorities, not standards.

MailTester supports RFC 9990 natively in all our services, including our real-time verification API and bulk verification. This means you get consistent, audit-ready data that aligns with emerging best practices. It’s not just a future-proof move—it’s a practical one, especially if you’re integrating verification into automated workflows or reporting pipelines.

As more platforms adopt the standard, teams that stick with proprietary formats risk being left behind when compliance, auditing, or vendor integration becomes a necessity. RFC 9990 isn’t just an improvement over RFC 7489—it’s a step toward interoperability. The sooner you build with it, the less rewiring you’ll need later.

How to verify if your email verification tool supports RFC 9990?

Check if the tool outputs verification results in a structured JSON format with standardized fields like valid, invalid, catch_all, and metadata. If it includes total_checks, transient, and timestamps, it likely conforms to or is evolving toward the RFC 9990 aggregate data model. Look for consistency in field names and predictable response shapes—this is the practical signal.

Look for these specific structural indicators

  • Does the API response include a total_checks field that sums up all individual verifications in the batch? This is a core part of RFC 9990's aggregation design.
  • Are the result categories clearly defined in the output with standard keys: valid, invalid, catch_all, risky, transient, and metadata? Non-standard names (like "undeliverable" instead of "invalid") suggest deviation.
  • Is there a timestamp field at the top level, or within each result, indicating when the check was performed? This helps track freshness and reliability.
  • Are the result counts and status codes presented in a consistent, machine-readable way—no embedded text like “Email is valid” but rather a true/false or code-based status?
  • Does the API response include a metadata object that holds information about the verification process, such as the check source, protocol used (e.g., SMTP), and time elapsed? This enables auditability and deeper analysis.

Test it yourself with a real request

Run a small batch of 5–10 test emails through the API and examine the raw JSON output. If it matches the RFC 9990 structure—especially total_checks, standardized status keys, and metadata—it’s either compliant or actively aligning with the standard. The absence of any of these fields signals a legacy, non-standard format.

For example, RFC 9990 explicitly defines how verification results should be aggregated and transmitted—this isn't just about labels, but about interoperability. As email deliverability systems grow more complex, having a consistent, shared data model helps tools like MailTester ensure accuracy and reduce false positives, especially in high-volume campaigns.

Use the MailTester API to test a real list and inspect the response structure. It returns results with full field alignment, including timestamps and aggregated counts, reflecting practical adoption of these standards.

While RFC 9990 is still emerging in real-world implementation, tools that structure responses around its principles are better positioned for long-term accuracy and integration with broader email ecosystems.

How does MailTester use RFC 9990 to improve list hygiene?

We use the RFC 9990 aggregate data model to structure bulk verification results, ensuring consistent filtering, reporting, and analysis across large email lists. This standard enables us to deliver clear, actionable insights—like identifying clusters of catch-all addresses or unusually high risky email rates—so you can clean your list faster and prevent delivery issues before they impact sender reputation. For teams managing high-volume campaigns, this means fewer bounces, lower blacklisting risk, and better inbox placement.

Structured reporting for real-world decisions

When you run a bulk verification, we don’t just return “valid” or “invalid.” Instead, we apply the RFC 9990 framework to group results by type—such as catch-all, role-based, disposable, or invalid addresses—so you see patterns at scale. This structure lets you filter and drill down quickly, even with 100k+ addresses, without getting lost in noise. The model is designed to be interoperable, so the data you get back is not only accurate but also aligns with broader industry standards.

For example, if you notice a 15% catch-all rate in a region-specific segment of your list, RFC 9990 helps isolate that trend. Catch-alls often mask poor data hygiene and can trigger reputation problems, especially if they’re not managed correctly. By using the standard’s defined verdicts, you can spot such anomalies earlier and act before sending, whether it’s removing suspect domains, revalidating opt-ins, or refining segmentation logic.

AI-assisted interpretation and faster action

Our in-app AI assistant parses the RFC 9990-compliant results and surfaces trends you might otherwise overlook—like a sudden spike in disposable email domains, a pattern of role-based addresses (sales@, info@), or unexpected geographic concentrations of risky addresses. Because these verdicts follow a known standard, the AI learns from actual patterns, not just heuristics.

This isn't just about filtering: it’s about context. If your list has low deliverability, you want to know *why*. RFC 9990 gives us the language to say, “These 2,000 addresses are catch-alls,” not just “Some are invalid.” This accuracy helps you decide whether to remove them, retry them, or investigate the source.

For a deeper look, you can test delivery in real inboxes using our inbox placement tester to validate how clean your list actually performs in real mail servers. The combination of RFC 9990 structure and AI interpretation ensures you’re not just removing bad addresses—you’re understanding *why* they’re bad and fixing the root cause.

Standards matter. The RFC 9990 standard defines how to express verification outcomes clearly, which helps prevent misinterpretation and improves automation between systems. It’s not just our choice—it’s the industry’s. By adopting it, we keep results predictable, repeatable, and actionable. That’s how you build better list hygiene over time.

Conclusion: RFC 9990 is not just a standard — it’s a foundation for clean email lists.

RFC 9990’s enhancements over RFC 7489 are foundational, not incremental. They enable systems to share and interpret email validation data consistently across platforms, reducing ambiguity in routing, delivery, and reporting.

For teams managing email lists, this means fewer false positives, less need for manual oversight, and greater confidence in delivery performance. Reliable data exchange directly improves inbox placement and sender reputation.

Tools like MailTester that support RFC 9990 today are already aligned with the next phase of email infrastructure. Adoption now ensures readiness for broader industry integration without disruption.

Keep reading

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?

RFC 9990 is an Internet standard that defines an aggregate data model for email verification results, improving consistency and interoperability across tools.

How is RFC 9990 different from RFC 7489?

RFC 7489 defined basic email verification syntax; RFC 9990 adds standardized aggregation, metadata, and status codes for bulk verification.

Does RFC 9990 improve email deliverability?

Yes — by enabling more accurate list hygiene, it reduces bounces, prevents spam traps, and helps maintain sender reputation.

Can I use MailTester with RFC 9990?

Yes — MailTester supports the RFC 9990 data model natively in its bulk verification and API outputs.

Why should I care about this if I use Mailchimp?

RFC 9990 ensures clean data from MailTester can be reliably imported into Mailchimp, Klaviyo, or SendGrid without manual scrubbing.

What happens if my tool doesn’t support RFC 9990?

You may face inconsistent results, manual reconciliation, or difficulty automating list cleanup across platforms.

No — accuracy is based on our verification engine. RFC 9990 improves how results are structured, not how they're computed.

How do I know if my email verifier uses RFC 9990?

Check if it returns structured JSON with standardized fields like 'valid', 'invalid', 'catch_all', and 'transient' in the aggregate output.

When will RFC 9990 be mandatory?

It is expected to become a de facto standard in email infrastructure over the next 3–5 years, but adoption is still early.

Does RFC 9990 replace SPF, DKIM, or DMARC?

No — it complements these protocols by standardizing how verification results are reported, not how email is authenticated.