While discussing a draft of a Deliverability BCP document the issue came up of what rejections at different phases of the email delivery transaction can mean. That’s quite a big subject, but here’s a quick cheat sheet.
At initial connection
Dropped or failed connection:

1. your reputation with the receiver is so bad that they don’t want to see any email from you, ever
2. their mail server is badly overloaded and can’t accept any connections right now
3. the server you’re connecting to isn’t a mail server – this is common with bad email addresses

Temporary (4xx) failure:

1. your reputation with the receiver is poor or unknown and they’re waiting for more information before they’ll accept your mail
2. the mail server is overloaded and can’t accept any new mail right now
3. your reputation is “grey”, the mail server is overloaded and it’s accepting mail preferentially from other senders right now
4. there is something technically wrong with your mailserver, such as non-existent reverse DNS, and your mail won’t be accepted until you fix that

Permanent (5xx) failure:

1. a 554 response can mean “there’s no mailserver here”. If someone has set up a mailserver specifically to reject connections this way, it’s probably been done for a domain that has a lot of bad delivery attempts. That might mean that the recipient email address is one that’s commonly used for fake signups, or it may be a common thinko address (e.g. something.com vs something.net)
2. they’ve explicitly blocked all mail from your mailserver due to a poor reputation – this is a common way of implementing DNS blacklist based blocking

Any time

1. when a mailserver is shut down, it may drop existing sessions with a 421 response
2. if you violate SMTP – send a bad command, bad parameters, lines too long – you might get 5xx responses at any time

After HELO or EHLO

1. a syntactically bad or obviously forged (e.g. yahoo.com) HELO hostname – unless you’re a spammer or have a badly misconfigured server, this probably shouldn’t happen

After MAIL FROM

1. mail from a domain (or, in theory, return path) might be blocked here, but it’s more likely to be rejected at RCPT TO time

After RCPT TO
This is a favorite point to apply reputation based filtering, for several reasons. It’s the first point at which you know who the intended recipient is, and that’s a very useful thing to record to help with diagnosing spam filtering false positives. So even the mailserver has decided it’s going to reject a message, based on the IP address it’s being sent from, waiting until the RCPT TO to reject if will give better diagnostics. There may be special recipient addresses that are exempt from global filtering (such as role addresses), so that filtering can’t be applied until this step. Also, some mailing list managers historically don’t handle rejections before RCPT TO gracefully – they’ll keep retrying and won’t unsubscribe the user forever.
If a mailserver waits until after this point it either has to accept the entire email or unceremoniously crash the connection (which violates SMTP and will provoke a redelivery attempt, so is rarely seen).
Temporary (4xx) failure:

1. the server is out of resources, and just needs you to come back later
2. the server is low on resources and mail from you isn’t as important as mail from other senders right now,
3. the overall volume of mail you’re sending has exceeded short term limits the receiver is applying to you (based on reputation) and it’s deferring mail so as to throttle your traffic
4. there’s a temporary problem (DNS blacklist resolution, perhaps) in looking up your reputation
5. your reputation is “grey”, the mailserver hasn’t decided whether your mail is likely to be wanted or not, and it’s letting a small fraction of your mail through, to see how recipients respond
6. your reputation is “grey” or there isn’t enough information about you to make a delivery decision, so your mail is being deferred in the hope that there’ll be a clearer reputation decision when you try to redeliver it
7. some combination of all the above

Permanent (5xx) failure:

1. the recipient doesn’t exist – sometimes a bad address is just a bad address
2. the source (IP address or domain) of the email has a poor reputation and mail is blocked
3. there’s a per-recipient block on this email

After DATA

1. the content of the message “looks like spam” – either because it looks similar to recently received unwanted messages or based on heuristics such as those used by spamassassin
2. URLs in the message have a poor reputation (or resolve to IP addresses with poor reputation)
3. DKIM signatures will be checked at this point, so if the mail would have been delivered due to DKIM-based whitelisting and the DKIM signature doesn’t validate that may cause rejection here
4. DMARC failures
5. virus or malicious content filters
6. any of the reasons given for RCPT TO – some filters may defer any rejection until after data, either so as to be able to analyze the content of rejected messages, or because they use a simple architecture that does all it’s filtering at once,
7. score-based filtering – based on combining everything the mailserver knows about this message, including the content

There’s probably something I’ve missed – call it out in the comments – but these are some of the things I think about when working out why a message has been rejected with an unhelpful error message.

filtering • SMTP