DEV Community: Deb Singha

Why We Chose a .com Domain (And Why It Still Matters)

Deb Singha — Wed, 05 Aug 2026 07:28:56 +0000

A few months ago, we moved Keplars to Keplars.com from Keplers.email.

Not because a .com magically makes a company successful.

And not because alternative domain extensions don’t work.

Plenty of great companies have been built on .io, .ai, .app, .dev, and many others.

But after talking to customers, founders, investors, and partners, we realized something simple:

People remember products. They don’t always remember domain extensions.

Your Users Are Already Doing Enough Work

When someone discovers your product for the first time, they’re trying to answer a lot of questions:

What does this product do?
Is it trustworthy?
Do I need it?
How is it different?
At the same time, they’re also trying to remember your brand.

Adding another thing to remember -whether you’re .io, .ai, .app, or .email -creates additional friction.

It’s a small amount of friction.

But small friction compounds.

A user may remember:

“I used a product called Keplars.”

But later wonder:

Was it Keplars.io?

Keplars.email?

Keplars.app?

Keplars.co?

Every extra second spent figuring that out is unnecessary cognitive load.

Don’t Make Users Think
One of the most important principles in product design is:

Don’t make users think.

The same principle applies to branding.

Most internet users have spent decades typing .com.

When they hear a company name, their default assumption is often:

companyname.com

It’s not because they’re consciously choosing .com.

It’s because they don’t have to think about it.

Good products remove friction.

Good branding should too.

Trust Signals Matter

A .com domain isn’t a guarantee of trust.

But trust is rarely built through a single thing.

It’s built through many small signals.

For better or worse, .com is still the most familiar and universally recognized domain extension on the internet.

Customers recognize it.

Partners recognize it.

Investors recognize it.

That familiarity reduces uncertainty.

And reducing uncertainty is often enough to improve conversion, recall, and confidence.

We Didn’t Want To Be Defined By One Category

Another factor was our long-term vision.

Many startups choose domain extensions that describe what they do today.

But products evolve. Companies evolve. Markets evolve.

What feels descriptive today can feel restrictive tomorrow.

At Keplars, we’re currently focused on email infrastructure.

But we don’t see the future as email-only.

Communication is expanding across channels, workflows, APIs, automations, AI agents, and platforms.

We wanted a brand that could grow alongside that vision instead of being tied to a single category forever.

Is .com Required?

No.

Many successful companies prove that every day.

If the perfect .com isn’t available, don’t let that stop you from building.

Product quality matters more than domain names.

Distribution matters more than domain names.

Execution matters more than domain names.

But if you have the opportunity to own a strong .com that matches your brand, it’s worth considering.

Not because .com is special.

But because reducing friction is.

The Bigger Lesson

This isn’t really a story about domains.

It’s a story about user experience.

Every decision should answer one question:

Does this make things easier for users?

If the answer is yes, it compounds.

Sometimes the best product decisions aren’t adding something.

They’re removing something users no longer need to think about.

Why We Became Keplars

When we first launched, our name was Keplers with a .email domain. Naturally, we wanted the matching .com.

Unfortunately, Keplers.com wasn’t available.

We could have stayed on an alternative extension, but the more we thought about it, the more we realized we wanted a brand that people could find, remember, and type instinctively.

That’s when we landed on Keplars.

The pronunciation remained virtually identical.

The brand felt familiar.

The identity stayed intact.

But now we could own the exact .com that matched our company. Looking back, it turned out to be the right decision. Not because Keplars is objectively a better name than Keplers.

But because having the exact brand match on a .com domain removed friction for customers, partners, and investors.

Sometimes branding isn’t about finding the perfect name. It’s about finding the name that people can actually remember and reach.

Why I Built Pluto: The Internal Email Validation Engine Behind Keplars

Deb Singha — Wed, 05 Aug 2026 07:16:52 +0000

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, 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 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, 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 .

Why I Built Pluto: The Internal Email Validation Engine Behind Keplars

Deb Singha — Sat, 30 May 2026 11:51:13 +0000

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

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

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.

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.