I’ve got multiple clients right now looking for insights about bounce handling. This means I’m doing a lot of thought work about bounces and what they mean and how they match up and how different ISPs manage delivery and how different ESPs manage delivery and how it all fits together. One thing I’ve been trying to do is contextualize bounces based on what the reason is.
Despite what people may thing, spam filtering isn’t the only reason an email fails to deliver. There are lots of other reasons, too. There is a whole category of network problems like routing issues, TCP failures, DNS failures and such. There are address issues where a recipient simply doesn’t exist, or is blocking a particular sender. There are spam and authentication issues. The discussion of all these issues is way longer than a blog post, and I’m working on that.
One of the interesting bounces that is so rare most people, including me, never talk about is “Relaying Denied.” This is, however, one of the easier bounces to explain.
Relaying Denied means the mail server you’re talking to does not handle mail for the domain you’re sending to.
Well, OK, but how does that happen?
There are a couple reasons you might get a “Relaying Denied” message, most of them having to do with a misconfiguration somewhere. For whatever reasons, the receiving server doesn’t handle mail for a domain.
DNS records are incorrect. These can be due to a number of things
- Failure to remove a MX record after a server is decommissioned;
- Pointing to a “backup” MX that isn’t configured to act as backup;
- DNS record changes have not yet propagated
In rare other cases, the DNS records are “correct” but there’s a misconfiguration on the receiving server and it doesn’t “know” that it is supposed to be handling mail for a domain. This can be temporary, if someone publishes DNS records before they finish the server configuration, this message may happen.
In these cases the mail won’t be delivered until the receiver fixes their configuration. It may be reasonable to continue mailing to the addresses, or they can be removed from the list completely.
The other case is that there was an error with the sending server. Some servers cache DNS records for longer than they should. This means that DNS is right but the sending server simply isn’t checking DNS before sending. The sender can fix this by making sure their system isn’t incorrectly caching DNS.
Chances are senders will never see a “Relaying Denied” message. But they do happen in some rare circumstances.
I tend to see these most often in conjunction with subdomain delivery, i.e. trying to deliver to email@example.com, and the same message sent to firstname.lastname@example.org is successful. It’s fairly common with institutional domains, specifically the US government (go figure).
It’s still not terribly common overall, but I was honestly a bit surprised by how many of these show up when sending to gov’t domains.
My Spam Resource page explaining “we do not relay / relaying denied” is probably one of my top ten pages, traffic-wise. People search for that a lot.