SMTP verification is the oldest and most standard way of verifying emails.
In this article, we’re going to cover everything you need to know about SMTP verification — how it works, where it fails and how to get better results.
Let’s go!
What is SMTP?
SMTP stands for Standard Mail Transfer Protocol.
Just like other protocols (eg: HTTP, FTP) it’s a standardized rulebook that all servers use when exchanging emails between them. This includes opening up a connection, identifying each other (domain, ip address, etc), sharing what commands are supported, exchanging emails and posting error messages when something goes wrong.
What is SMTP Based Email Verification?
SMTP Based email verification uses the SMTP protocol to verify whether an email exists on a target server.
It does this by relying on a default behavior of most email servers, which is throwing a premature “error” message when the address that the sender is trying to reach doesn’t exist.
The exchange looks something like this:
- Verification Server: “Hi, I’d like to send you an email”
- Recipient Server: “Great, here’s my information and available commands”
- Verification Server: “Cool, I’d like to send an email to jane@trykitt.ai”
- Recipient Server: “Don’t bother, that email doesn’t exist. Don’t waste your time sending it and mine bouncing it back to you”.
While this seems efficient and logical at first glance, it’s considered a security vulnerability in today’s age. Why? Because it allow malicious actors to launch what is called an “enumeration attack”, where they try lots of variations of email addresses (john.smith@acme.com, jack.smith@acme.com, etc) until they discover corporate email addresses, from which point they can launch phishing attacks.
Enter the “Catchall Email”
Catchall emails aren’t actually a feature of the email address but rather the email server behind it.
These servers tend to have proper IT teams that realize the risks of SMTP verification, so they change the default server behavior to not reject invalid email addresses during the SMTP handshake phase. While this is less efficient, security people prefer it because it will eat up more time/bandwidht for the attacker and lead to more bounced emails, which will hurt its reputation with the attackers email host.
So how do SMTP email verifiers know if the positive result they’re getting from the check is from a “catchall” email server? They usually run two server check tests — one with a made up email address that they KNOW doesn’t exist and then the actual email address they are verifying.
If they get a ‘positive’ reply to the fake address, they know it’s a catchall email and don’t give a positive or negative result.
Here is a real life example of this happening, where you can see the email address being checked is a combination of two made up alphanumeric strings.
How Reliable Is SMTP Verification?
You may notice emails that are SMTP verified bouncing from time to time.
The oversimplified explanation is that bounce behavior isn’t always tied to the email address not existing (even though the bounce message says so). Why? Because from a security perspective, the best way to prevent attacks is to give the attacker misinformation.
It’s not uncommon to have the following scenario in enterprise email:
- Give an “accept all” message saying the email address is valid
- When the email is received, do a spam analysis of the sender/email contents and if flagged, do an automatic bounce so that the attacker thinks that maybe the targeted person no longer works there.
Note: there are infinite permutations of this, we’ll cover how to best deal with these in another post.
Because of this, different email verifiers offer different verification SLAs.
In terms of coverage, they usually claim to be able to validate ~45% of all business email addresses.
In terms of accuracy, they claim that of the ‘valid/invalid’ statuses they provide, you can expect a bounce less than 1% of the time.
Is There A Better Approach To Email Verification?
Yes, there are both other techniques for verifying emails, that yield better coverage and accuracy (especially when combined with SMTP verification). There are also better ways to deploy verification than how it is done today (validating standard lists).
Interested in learning more about these methods? You can subscribe to our blog to get the latest updates on research from The Deliverability Lab.
eroltoker
Author