Many customers are surprised when they have deliverability problems in B2C after being very careful to comply with data protection legislation: they have collected their subscribers unambiguously, those subscribers want to receive the newsletters, and unsubscribes are processed promptly.
Unfortunately, sometimes they have overlooked a very important detail: removing from their database the ISP accounts that have returned a bounce indicating that the account no longer exists or is not operational (usually because they send with homemade in-house systems that don’t handle bounces).
For example, when a send returns any of these SMTP response codes:
- 5.0.0 Address does not exist.
- 5.1.1 Bad destination mailbox address.
- 5.1.2 Bad destination system address.
- 5.1.3 Bad destination mailbox address syntax.
- 5.1.4 Destination mailbox address ambiguous.
- 5.1.6 Mailbox has moved.
- 5.1.7 Bad sender’s mailbox address syntax.
- 5.1.8 Bad sender’s system address.
- 5.2.0 Other or undefined mailbox status.
- 5.2.1 Mailbox disabled, not accepting messages.
In general, though, any hard bounce with a 5.x.x code should be discarded and never sent to again.
When this isn’t done, the problem is as follows:
► If we exceed the maximum hourly limit of sends to addresses that have already been reported as bounced, the destination ISP may block or queue the messages that follow.
Let’s look at this example log, in which Hotmail states it unambiguously:
queue #rcpt kbytes conn st retry last error———————————————- —— ———- —- — ——– ———-hotmail.queue/cliente_ip-zone_com-6 500997 15929377.0 9 Maximum of 20 recipient errors detected; disconnecting while connected from smtp.consultorpc.com (93.159.xxx.xx) to hotmail-com.olc.protection.outlook.com (104.47.5.33)
· Solutions to this problem
First of all, if you use in-house sending systems, you need to handle the bounces and gradually clean them out of the database.
Sometimes this is complicated because it requires some programming or dedicating human resources, but we can get help from software available on the market that can handle them via POP3.
However, the best option is to send with a bulk email platform like Mailrelay that has this feature built in.
For databases that are already “dirty” because they haven’t been maintained, it might seem easy to fix, since from now on it would just be a matter of acting on the failed-account notices, but it isn’t.
It is true that when new invalid accounts, or accounts that are no longer operational, are detected, Mailrelay will mark them as bounced, but with the old ones, some will keep bouncing while others won’t.
The reason is that ISPs turn some of them into spamtraps, or what we could better call bouncetraps, which they reactivate several months later without returning a bounce, precisely to detect which senders comply with their requirement to clean out bounced and failed accounts and which don’t.
Related posts:
- SSL Certificate in Email Marketing: Is It Worth It?
- Email Marketing and Copywriting: The Perfect Match?
- Sending Email Attachments Securely and Without Increasing Their Size
- What is a SWOT analysis?
- 5 Ways to Repurpose Content in Your Emails
To clean these up, the only solution is to discard any databases we haven’t maintained or, at the very least, send to email addresses that have had some activity in the last 3 months.
To finish, it’s worth mentioning that cleaning up failed and bounced accounts tends to be overlooked because ISPs are normally not very strict (especially with well-behaved senders who don’t spam), but at certain times of the year (for example, right now, at the end and beginning of the year) they tend to make their rules tougher and start queueing for this reason.
It also happens when they have problems with excessive load on their servers.
Removing these failed accounts is an essential part of email list hygiene, and moving those contacts to your suppression list prevents you from contacting them again by mistake.
