Relaying Denied

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.
 
 

Related Posts

Increase in bounces at Y!

I’ve been seeing reports over the last few days about an increase in bounces at Yahoo. Reliable people are telling me they’re seeing some increase in “invalid user” bounces.
You may remember Yahoo announced an overhaul of their mail product back in December. Reliable sources tell me that this is more than just interface revamp. In the back end, Yahoo! is removing older products with few users and security problems. This fits in with the changes CEO Mayer has been making with the company: slim down and stop supporting unprofitable products.
It makes sense that while engineers are looking at the guts of the email program and cleaning up the cruft, they will also disable long unused email addresses. This will result in higher unknown users for some senders.
What’s interesting to me is that the reports are somewhat sporadic. Some senders are seeing a huge percentage of bounces, some are seeing the normal percentage. I expect this difference isn’t anything more than how actively a sender purges based on engagement. Senders that purge unengaged addresses are going to have already removed a lot of the addresses Yahoo! is now purging from their database. Senders that keep sending to their whole list, are going to see a lot of unknown user bounces.
I’ve asked a few folks and people who’ve responded told me that spot checks showed all the addresses turning up as invalid had no engagement for long periods of time.
If you are seeing a lot of bounces at Yahoo! over the last few days, you need to remove those addresses from your lists. I also recommend looking at the engagement statistics of these newly purged recipients. This will tell you, approximately, what an abandoned address profile looks like. You can use that information to make good decisions about purging unengaged users at other ISPs as well. Not only does this lower costs, because you’ll be sending to less non-responsive email addresses, it will also improve delivery at many ISPs.

Read More

Bounce handling is hard

Sometimes I find it hard to find a new topic to write about. I decide I’m going to write about X and then realize I did, often more than once. Other times I think I can blog about some issue only to realize that it’s too complex to handle in a quick post. There are concepts or issues that need background or I have to work a little harder to explain them.
One thing I haven’t blogged about before is bounce handling. That particular topic falls into the other category of posts that take a lot of time to write and need a significant amount of work to make sense. I was even joking with my fellow panel members at EEC a few months ago about how that’s a post that so needs to be written but I’m avoiding it because it’s so hard. There’s so much to be conceptualized and explained and I realize it’s not a blog post but multiple blog posts, or a white paper or even a book.
Bounce Rate words on a thermometer or gauge measuring the rate of abandonment as visitors or audience leaves your website or online page or resource
So let’s start with some simple definitions.  Those of you who work at ISPs are probably thinking of bounces in terms of accept than reject, that’s not exactly what I’m talking about here. I’m writing these for senders, who usually call rejects during the SMTP transaction bounces.

Read More

Thoughts on bounce handling

This week’s Wednesday question comes from D.

What are your thoughts on bounce handling

Read More