Case Study: Delivery Failures to AOL
One of our clients has a business partner in the U.S. using an @aol.com mailbox. From their self-hosted email server they were experiencing mail delays and then failures to this address. This is despite the use of a fixed IP address on the mail server, a correctly configured reverse-DNS entry and even a SPF (Sender Policy Framework) entry on the domain. We were also able to verify the server was not listed in any spam blocklists, among dozens checked.
The error appearing against the delayed message in Microsoft Exchange's Queue Viewer referenced http://postmaster.info.aol.com/errors/554rtrbb.html. This refers to AOL's policy of refusing email that originates from what it considers to be a “residential” or dynamically-assigned IP block. In this situation, the IP was static, but was from a block that is also assigned to non-static ADSL plans. Also, the ISP, and most ISPes in Australia, do not have IP blocks which are “residential” or “non-residential”. The fact that spare IPv4 blocks are in such short supply (or non-existent) has meant that ISPes do not have the luxury of assigning IPs to their customers out of specific pools for specific purposes.
AOL also references an additional error code 554 RTR:DU and mentions that they use Spamhaus Policy Block List (PBL) to manage their blocked addresses. However the IP address in question was not listed in this database.
So it's not clear on what basis AOL makes its decision about IP blocks.
A conversation with the ISP and a request to move to another IP block was not fruitful, as changing IP addresses without requesting various plan changes was not something their systems supported. So there was not going to be a simple path to a fresh IP on another block. And the ISP did not seem keen to follow up the way its IP blocks were regarded by other hosts.
Ultimately the solution was to lodge a ticket via http://postmaster.aol.com/SupportRequest.php requesting the IP be added to an allow list, and this was a simple process and the IP was approved within about 12 hours.
Previously, when using a Telnet test with:
telnet mailin-01.mx.aol.com 25
the Telnet session reports the same error URL and disconnects. After the IP is added to the allow list, the Telnet client responds properly.
Australian users may not send much email to recipients on aol.com and it seems that AOL is amongst a very small group that actively refuses email from IP addresses based on what they think its purpose is. It might seem onerous for organisations who host their own email server on connections that are less than data-centre grade to manually and individually request IP addresses to be allowed for some upstream recipient servers, but thankfully it doesn't need to be done very often.
(See also Windows 8/10 — Installing Telnet.)