{"id":96828,"date":"2018-12-17T07:59:34","date_gmt":"2018-12-17T07:59:34","guid":{"rendered":"https:\/\/mailrelay.com\/blog\/2026\/09\/30\/failed-accounts-in-the-email-database-the-importance-of-removing-them\/"},"modified":"2026-09-30T01:16:35","modified_gmt":"2026-09-30T01:16:35","slug":"failed-accounts-in-the-email-database-the-importance-of-removing-them","status":"publish","type":"post","link":"https:\/\/mailrelay.com\/en\/blog\/2018\/12\/17\/failed-accounts-in-the-email-database-the-importance-of-removing-them\/","title":{"rendered":"Failed accounts in the email database: the importance of removing them"},"content":{"rendered":"

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.<\/p>\n

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<\/strong> (usually because they send with homemade in-house systems that don’t handle bounces).<\/em><\/p>\n

For example, when a send returns any of these SMTP response codes:<\/strong><\/p>\n

    \n
  1. 5.0.0 Address does not exist.<\/li>\n
  2. 5.1.1 Bad destination mailbox address.<\/li>\n
  3. 5.1.2 Bad destination system address.<\/li>\n
  4. 5.1.3 Bad destination mailbox address syntax.<\/li>\n
  5. 5.1.4 Destination mailbox address ambiguous.<\/li>\n
  6. 5.1.6 Mailbox has moved.<\/li>\n
  7. 5.1.7 Bad sender\u2019s mailbox address syntax.<\/li>\n
  8. 5.1.8 Bad sender\u2019s system address.<\/li>\n
  9. 5.2.0 Other or undefined mailbox status.<\/li>\n
  10. 5.2.1 Mailbox disabled, not accepting messages.<\/li>\n<\/ol>\n

    In general, though, any hard bounce with a 5.x.x code should be discarded and never sent to again.<\/p>\n

    When this isn’t done, the problem is as follows:<\/p>\n

    \u25ba 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.<\/p>\n

    \n
    Let’s look at this example log, in which Hotmail states it unambiguously:<\/div>\n
    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)<\/p>\n<\/div>\n<\/div>\n

    \u00b7 Solutions to this problem<\/h2>\n

    First of all, if you use in-house sending systems, you need to handle the bounces and gradually clean them out of the database.<\/p>\n

    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.<\/p>\n

    However, the best option is to send with a bulk email platform like Mailrelay<\/a> that has this feature built in.<\/p>\n

    For databases that are already \u201cdirty<\/em>\u201d because they haven’t been maintained, it might seem easy to fix<\/strong>, since from now on it would just be a matter of acting on the failed-account notices, but it isn’t<\/strong>.<\/p>\n

    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.<\/p>\n

    The reason is that ISPs turn some of them into spamtraps<\/strong><\/a>, or what we could better call bouncetraps<\/strong>, 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.<\/p>\n