When most people think about email infrastructure, they usually think about sending emails.

• SMTP servers.
• Email APIs.
• Deliverability.
• Tracking.
• Automations.

At Keplars, we spend a lot of time thinking about those problems too. But while building an email infrastructure platform, I realized that one of the biggest challenges actually happens before an email is ever sent.

The challenge is simple:

How do you know whether an email address is truly valid?

It sounds like a solved problem. In reality, it is much more complicated than most people realize.

The Problem We Kept Running Into

While building Keplars, we tested and integrated multiple email validation providers.

Most of them offered similar capabilities:

• Syntax validation
• Domain validation
• MX record checks
• Disposable email detection

On the surface, the results looked reasonable.

However, when we compared validation results against actual email deliverability and mailbox behavior, we kept seeing inconsistencies.

• Some addresses marked as valid would later bounce.
• Some belonged to temporary providers.
• Some were aliases that represented the same mailbox.
• Others had DNS records configured correctly but still could not reliably receive mail.

For a company building communication infrastructure, this creates a serious problem.

Every invalid email address affects:

• Deliverability rates
• Sender reputation
• Bounce rates
• Campaign performance
• Infrastructure costs
• Customer trust

The more we relied on external validation tools, the more we felt there was still a gap between "technically valid" and "actually deliverable."

Eventually, I decided to stop stacking validation providers on top of each other and build our own system from scratch.

That's how Pluto was born.

Introducing Pluto

Pluto is an internal email validation engine developed for Keplars.

Built entirely in Go, Pluto was designed with a different goal than most validators.

Instead of answering:

"Does this email look valid?"

We wanted to answer:

"How confident are we that this mailbox can actually receive email?"

That small difference completely changed how we approached validation.

Going Beyond Simple Validation

Most email validators stop after a handful of checks.

Pluto combines multiple layers of validation into a single pipeline.

RFC Compliance Validation

Every email address is first validated against RFC standards.

This includes:

• Local-part validation
• Domain validation
• Character restrictions
• Formatting requirements

Many invalid addresses never make it beyond this stage.

Length Limit Validation

Email standards include strict limits around:

Local-part length
Domain length
Total address length

These checks help eliminate malformed addresses that technically appear valid but violate email specifications.

Internationalized Domain Support (IDN)

Email is global.

Many validation systems struggle with internationalized domains.

Pluto supports:

• Unicode domains
• Internationalized Domain Names (IDN)
• Punycode conversion and validation
• This ensures proper validation across multiple languages and regions.
• DNS and MX Verification
• One of the most important steps is verifying that a domain can actually receive mail.

Pluto performs:

• DNS lookups
• MX record validation
• Domain routing verification
• Without valid MX records, email delivery simply isn't possible.
• Disposable Email Detection
• Temporary email services continue to grow rapidly.
• These addresses often introduce low-quality users, spam registrations, and unreliable communication.
• Pluto maintains an internal database of more than 5,000 known disposable email providers.

As part of the Keplars infrastructure (https://keplars.com), these lists are continuously updated and monitored.

Role-Based Email Detection

Certain email addresses are technically valid but may not represent individual users.

Examples include:

admin@
support@
info@
sales@
contact@

Pluto identifies role-based accounts and flags them appropriately.

This becomes especially useful when building B2B communication workflows.

Free Email Provider Classification

Not all email addresses are equal.

Pluto identifies major consumer email providers including:

Gmail
Outlook
Yahoo
iCloud
Proton Mail

And many others.

This allows systems built on Keplars (https://keplars.com) to better understand the composition of their email lists.

Alias Normalization

One of the more interesting challenges was alias handling.

• Take Gmail for example:
• johnsmith@gmail.com
• john.smith@gmail.com
• john.s.m.i.t.h@gmail.com

All of these can point to the same mailbox.

Most validators treat them as completely different addresses.

Pluto performs provider-specific normalization for:

Gmail dot aliases
Gmail plus tags
Yahoo aliases
iCloud aliases

This helps eliminate duplicate records and improves data quality significantly.

Detecting Common Typos

A surprisingly large percentage of invalid email addresses are simply typing mistakes.

Examples:

gmial.com
gmai.com
outlok.com
yahho.com

Pluto automatically detects common mistakes and suggests corrections.

This simple feature alone helps improve signup quality and reduces unnecessary bounce rates.

Reputation Analysis

Validation isn't only about the recipient.

• Domain reputation matters too.
• Pluto evaluates:
• SPF records
• DMARC records
• DNS reputation
• DNSBL checks
• DBL checks
• These signals provide additional insight into the trustworthiness of email domains.

SMTP Mailbox Verification

This is where things become much more interesting.

A domain may exist.

MX records may exist.

DNS may be configured correctly.

But none of those guarantee that a mailbox actually exists.

Whenever supported, Pluto performs SMTP-level mailbox verification.

While no system can achieve 100% certainty due to anti-abuse protections used by major providers, SMTP verification provides a significantly stronger signal than syntax checks alone.

Building Pluto in Go

Performance was a major priority from day one.

Email validation can quickly become expensive when processing large datasets.

Go was chosen because it offered:

Excellent concurrency
Fast network operations
Efficient memory usage
Scalability

This allowed Pluto to process validations quickly while performing multiple checks simultaneously.

The Results

After integrating Pluto into our internal workflows at Keplars (https://keplars.com), we saw substantial improvements.

Most importantly:

We became significantly more confident in the quality of data entering our communication infrastructure.

Today Pluto helps us achieve over 90% validation accuracy internally.

The benefits include:

• Lower bounce rates
• Better deliverability
• Cleaner datasets
• Improved sender reputation
• More reliable automation workflows
• Better overall communication performance

For an email infrastructure platform, those improvements compound quickly.

Why the Name Pluto?

At Keplars, many of our systems follow a space-themed naming convention.

Since Pluto operates quietly behind the scenes, validating and filtering communication data before it enters the ecosystem, the name felt appropriate.

It isn't the largest component in our infrastructure.

But it's one of the most important.

What's Next?

Today, Pluto remains an internal tool used throughout the Keplars ecosystem.

We continue improving:

• Validation accuracy
• Disposable provider detection
• Alias normalization
• Reputation analysis
• SMTP verification techniques

And while Pluto was originally built to solve our own challenges, we've received growing interest from developers who face similar problems.

If enough people find Pluto valuable and would genuinely use it, I'd be happy to explore making it open source for the broader community.

Because one thing became very clear while building Keplars:

The quality of your email infrastructure isn't determined when an email is sent.

It's determined long before you ever press Send.

Learn more about Keplars.