We recently had an enquiry from a dotMailer customer who was concerned that our hard bounce reporting wasn’t accurate. They had been using another ESP and when they sent to the same list with dotMailer, it reported a lot more of their list to be hard bouncers and thus wouldn’t allow them to send to some of the addresses on the list.*
We were pretty confident that our hard bounce reporting was correct, so we started to investigate. We asked the customer to supply a small sample of email addresses that the previous ESP had classed as “delivered” but we classed them as a hard bouncer.
This is what we found (warning, technical jargon approaching!): the other ESP had assumed an email had been delivered as long as the remote email server didn’t report the address to be incorrect. That seems pretty fair you might think, but it’s not that easy because not all ISPs report bouncers in the same way.
What does it mean?
To make this all a bit clearer, let’s go back a few steps and understand the whole process of delivering an email. Note, this is a much simplified model and there are many extra steps in the real world of spam filtering, IP validation and authentication.
When any mail server (company mail server or ESP) wants to send an email to say frank@SomeCompany.com, the first thing it does is to do an MX lookup using DNS to find out which mail server is handling mail for somecompany.com.
So let’s say DNS comes back saying that mail for SomeCompany is handled by a computer with the address: “mail-in.SomeCompany.com”. The next step is to connect to the machine at this address and send our email using a very simple chat process that looks a little something like this.
Here, in a simplified example, we have our friend Frank from SomeCompany.com mailing his client Alice from AnotherBiz.com.
S: 220 smtp.AnotherBiz.com ESMTP Postfix
C: HELO relay.SomeCompany.com
S: 250 Hello relay.SomeCompany.com, I am glad to meet you
C: MAIL FROM:<frank@SomeCompany.com>
S: 250 Ok
C: RCPT TO:<alice@AnotherBiz.com>
S: 250 Ok
S: 354 End data with <CR><LF>.<CR><LF>
C: From: “Frank Boggins” <frank@SomeCompany.com>
C: To: “Alice Example” <alice@AnotherBiz.com>
C: Subject: Test message
S: 250 Ok: queued as 12345
S: 221 Bye
Now if in the above example, Alice did not exist at that address, some mailservers would reply instantly with an error with a specific code (normally starting with a 5) that tells the sending machine she’s a hard bouncer and does not exist. This is what we and most other ESP’s use to then mark that address as a hard bouncer.
However some mailservers don’t reply instantly, and accept *all* mail sent to them. In this case, if it’s subsequently found that the address doesn’t exist, then a bounce email is pinged back to the original sender. Since this could be seconds or even minutes later, this requires the separate sending of an email and at that time, the original connection which sent the email is long gone.
So we make a big point of processing these bounced emails, no matter how long after they arrive, and mark the addresses as hard bouncers. This requires considerable resources to manage and it’s understandable why some ESP’s omit it. But if you want the most precise stats, then there’s really no alternative.
*Why don’t we let people send to addresses that we already know are hard bouncers? Well it’s not good for deliverability! The last thing email providers like Hotmail or Gmail want is ESP’s sending repeated messages to people that don’t exist!
Also, it costs our customers money. If you pay your ESP based on the amount of emails you send, or the amount of emails addresses in your list, then what’s the point of storing them if they will never get through?