Earlier today I approved a comment from Mike on a post about problems at AOL from 2012. The part of the comment that caught my attention:
SMTP error from remote mail server after end of data:
521 5.2.1 : AOL will not accept delivery of this message.
Mike also mentioned his IP reputation is good, when he checks at AOL so he doesn’t understand why mail is being blocked.
I think the big clue is after the end of data and would look at the full content of the mail, particularly domains and URLs, to identify is triggering the block.
In the SMTP transaction there are only a few places the ISP can stop the transaction and each spot tells us different things about why the ISP is rejecting the message.
After connection
A block after connection is a block either against the IP address or against the domain in the rDNS of the IP. IPs with no rDNS or generic DNS can also be blocked here. Blocks here do happen, but many recipients will let the SMTP transaction continue.
After HELO/EHLO
A block after HELO/EHLO is often a block against the domain in the HELO/EHLO or against a particular HELO/EHLO. Malware and bots often have distinctive HELO/EHLO patterns and it’s common for those kinds of senders to be blocked at this point.
After Mail From
A block after Mail From is often directed at the domain in the bounce string. Some senders do check to make sure the domain has a MX and will block if it doesn’t. Blocks don’t happen here very often.
After RCPT To
Blocks here are not always spam related. Most of the delivery failures at this point have to do with non-existent addresses.
After DATA
Blocks after data mean the ISP has actually seen the full content of the email. If a block comes after DATA the full content of the message including the recipient and their permission status should be evaluated as part of the determination about what is triggering the block.
Using when the rejection happened is an important part of understanding why a block happened. For instance, if a block happens before DATA, you know that content isn’t relevant, because the ISP never saw the content. If a block happened before Mail From: you know it’s the IP address reputation or configuration. If a block happened after DATA you know you need to look at the whole message.
RSS - Posts
This post is so timely for me. Just today, I found a ton of AOL bounces with the reason “521 5.2.1: AOL will not accept delivery of this message. (in reply to end of DATA command)”
The interesting fact is that these are subscribers to a Baptist newsletter I send out daily, where most subscribers have been receiving it for months and years. So the conclusion would be that there is some new content in the current issues which AOL objects to?
Additional info: The Baptist newsletter I mentioned was actually sent via TWO servers (identical content) and AOL only blocked messages from one, not from the other. So the reason for the block was apparently not SOLELY the content. (See Filters Are Complex post. 🙂
From what I have seen, “521 5.2.1 : AOL will not accept delivery of this message.” block is often triggered due to absence of A records for RFC2822 FROM domain.
One of our IPs is getting that response for all mail being sent. When the same content is sent from a different IP it goes through just fine. The strange thing is that AOL reports that the IP with the issue has a Good reputation. We have a ticket open and will let you know what comes of it.
I was open a ticket with Postamster and the response came like this:
We identified an issue and believe we have resolved the issue. Please try emailing again and let us know if you continue to have this problem.
Thank you.
AOL Postmaster
But the result still “521 5.2.1 : AOL will not accept delivery of this message.”
What Laura said here are for folks who are getting these errors to check these issues. It doesn’t mean that any ISP will just check these variables only. Mail filters are more complex which we all know. Sanket, you are right and that is one of the reason. Joel, you are not seeing that bounce because you are sending from a different IP and it has there own reputation. Bottom line is how you are getting that data, what type of content you are using, how many bulk mailers are using that content which an ISP is receiving from internet to there domain and lots of other rule sets.