All email validation services fundamentally do the same thing:
- look up the domain to see if it has an MX record
- if it has one, connect to the MX and pretend they’re about to send an email
- quit after sending
RCPT TO, before sending a message body - report whether
RCPT TOreturned250 OKor not[1]
They can — okay, since I’ve built such services myself, we can — dress ’em up with “heuristic analysis” and “suspicious domain databases,” but the foundation is the same.
Here’s the log of a service hitting our corporate server to validate sandy+test-ssloptional@figureone.com:
94.46.244.65 [1DB4] 20:44:55 Connected, local IP=66.165.231.34:25
94.46.244.65 [1DB4] 20:44:55 >>> 220 icewarp.figureone.com ESMTP IceWarp Epos Update 1 build 17; Sun, 13 Apr 2025 20:44:55 -0400
94.46.244.65 [1DB4] 20:44:55 <<< EHLO douglas.email-validator.com
94.46.244.65 [1DB4] 20:44:55 >>> 250-icewarp.figureone.com Hello douglas.email-validator.com [94.46.244.65], pleased to meet you.
250-ENHANCEDSTATUSCODES
250-SIZE
250-EXPN
250-ETRN
250-ATRN
250-CHECKPOINT
250-8BITMIME
250-SMTPUTF8
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-VRFY
250 HELP
94.46.244.65 [1DB4] 20:44:55 <<< MAIL FROM:<pvchk@email-validator.com>
94.46.244.65 [1DB4] 20:44:55 >>> 250 2.1.0 <pvchk@email-validator.com>... Sender ok
94.46.244.65 [1DB4] 20:44:55 <<< RCPT TO:<sandy+test-ssloptionalfigureone.com>
94.46.244.65 [1DB4] 20:44:56 >>> 250 2.1.5 <sandy+test-ssloptional@figureone.com>... Recipient ok
94.46.244.65 [1DB4] 20:44:56 <<< QUIT
94.46.244.65 [1DB4] 20:44:56 >>> 221 2.0.0 icewarp.figureone.com closing connection
94.46.244.65 [1DB4] 20:44:56 *** <pvchk@email-validator.com> <sandy+test-ssloptional@figureone.com> 1 0 00:00:00 INCOMPLETE-SESSION
94.46.244.65 [1DB4] 20:44:56 DisconnectedQUIT without DATA logs an INCOMPLETE-SESSION, but no harm, no foul.
The validator is speaking for itself
Technically, the validator is checking whether it could send mail, not whether any other server could send mail.
There’s still a ton of value to 3rd-party validation, don’t get me wrong! But inevitably you get false positives: the validator says “valid,” while a real send from Marketo or another MAP fails. (The bounce message might even be “Recipient email does not exist.” That’s because mailservers are under no obligation to tell presumptive spammers the truth.)
False positives are typically because (a) the recipient’s mailserver doesn’t accept marketing emails, period, or (b) your IP or domain was blocked due to prior offenses.
Far rarer are false negatives, where the validator says “invalid” but if you try sending anyway, the email goes through. But a client recently validated their whole db and noticed some people had Email Delivered that very same day, so they couldn’t be invalid. Right?
Well, depends on your point of view. Not even sure which side I’m on yet, but felt like pubbing this post and getting people thinking.😛
It’s about STARTTLS, a form of secure SMTP
SMTP is, or was, a notoriously insecure protocol. If you can tap the network between 2 SMTP servers, or between an SMTP client and server, you can eavesdrop on every message passed between them.
That servers reside in secure datacenters, and the pipes between them are run by (umm, generally) good actors, mitigates the risk somewhat. But if you’re on a coffee shop LAN and the shop owner is in the mood, they can read all submissions from a traditional email client using ol’ school SMTP.[2]
Enter secure SMTP, which comes in 2 flavors:
- SMTPS, also known as implicit TLS, which is always encrypted and as secure as HTTPS
- SMTP with STARTTLS, also known as opportunistic TLS, which is now actively discouraged because encryption isn’t guaranteed
STARTTLS offers questionable security, since it’s typically offered but not required: both sides of the SMTP transaction, sender and receiver, need to agree to use it.[3] If the receiver says “Hey, I support STARTTLS,” the sender can still say “Nah, I’m good with plaintext.” And the transaction will still continue.
In contrast, SMTPS won’t allow downgrading to unencrypted traffic.[4] That’s why that RFC linked above is like a cease and desist against STARTTLS.
Nevertheless, STARTTLS is still offered by almost all receivers. But here’s the thing: it’s not 100% supported by senders.
Requiring STARTTLS isn’t whole-internet-safe
Google publishes a Transparency Report measuring the adoption of STARTTLS across the world, as measured on the Gmail platform. While adoption is highest in the Americas, it’s still hovering at 99%+, not quite reaching 100% for consecutive months. In other areas it’s high-90s: highly successful yet not universal. Here’s a worldwide chart since 2020 showing we’re still not quite there:
So what happens if one of the 1-10% of senders that don’t support STARTTLS connects to a receiver that requires STARTTLS? (We’re not including hackers in this situation, by the way.)
Simple: the connection will end with a permanent failure. The sender will issue an opening EHLO, then the receiver says “OK, you can use STARTTLS.” If the sender doesn’t use STARTLS immediately after that, the receiver says “To be clear, I meant you must use STARTTLS” and sends back a hard 530 error.
And that’s what happened with those leads that came up invalid, even though Marketo could send to them. The validation log looked like this:
94.46.244.65 [2A9C] 20:52:02 Connected, local IP=66.165.231.34:25
94.46.244.65 [2A9C] 20:52:02 >>> 220 icewarp.figureone.com ESMTP IceWarp Epos Update 1 build 17; Sun, 13 Apr 2025 20:52:02 -0400
94.46.244.65 [2A9C] 20:52:02 <<< EHLO douglas.email-validator.com
94.46.244.65 [2A9C] 20:52:02 >>> 250-icewarp.figureone.com Hello email.phone-validator.com [94.46.244.65], pleased to meet you.
250-ENHANCEDSTATUSCODES
250-SIZE
250-EXPN
250-ETRN
250-ATRN
250-CHECKPOINT
250-8BITMIME
250-SMTPUTF8
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-VRFY
250 HELP
94.46.244.65 [2A9C] 20:52:02 <<< MAIL FROM:<pvchk@email-validator.com>
94.46.244.65 [2A9C] 20:52:02 >>> 530 5.7.0 Must issue a STARTTLS command first
94.46.244.65 [2A9C] 20:52:02 <<< QUIT
94.46.244.65 [2A9C] 20:52:03 >>> 221 2.0.0 icewarp.figureone.com closing connection
94.46.244.65 [2A9C] 20:52:03 *** <pvchk@email-validator.com> <sandy+test-sslrequired@figureone.com> 1 0 00:00:00 INCOMPLETE-SESSION
94.46.244.65 [2A9C] 20:52:03 DisconnectedSo the validation service is in the 10% of senders that can’t use STARTTLS. Since it can’t send, it calls the address invalid. Indeed, for any other sender in the 10%, it is invalid — there’s no practical difference between a 530 Missing STARTTLS and a 550 User unknown, they’re both permanent rejections.[5]
Is the validator wrong or right?
Depends. If an email is valid only if every well-behaved/non-blocklisted mailserver in the world can send to it, then the validator is right. If an email is valid if the overwhelming majority of mailservers can send to it — even if your mailserver can’t — then it’s wrong.
This also serves as a reminder: the only way to truly know if your Marketo instance can email someone is by emailing them. Generate enough content and you won’t have uncertainty!
Notes
[1] That’s the extent of what you can check in real time. Validators also have a batch mode which allows them to retry if the initial connection is greylisted.
[2] Note a webmail client, mobile app, or proprietary connection like Outlook ⮕ Exchange is not traditional. I’m talking pure IMAP/SMTP without SSL.
[3] And that’s not all: that initial discussion takes place over plaintext! Which means a hacker in the middle can simply remove the receiver’s original offer, so the sender never knows it could’ve used encryption — and in turn the unencrypted data can be read by the hacker.
[4] SMTPS has its own barriers to global adoption that I won’t get into here, but it can always be used in the coffee shop scenario.
[5] Suppose one difference is the 530 might change over time if the receiver gets the hint that requiring STARTTLS was a bad idea. But as long as the policy is in place, the email address is useless if you don’t support outbound STARTTLS.