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.
 
 

11 Innovators in the Email Game
Spam complaints… ish

Related Posts

Bounce handling simplified

I am a strong believer that bounce handling should be designed to remove addresses that have no human on the other end while not removing addresses that have a real recipient on the other end.
Bounce handling should be designed to appropriately manage your subscriber base. Delivery problems are the consequence if you don’t do that. They shouldn’t be the reason you bounce handle, though.
Context matters.
My experience tells me that senders that think about the impact of their sends can do things that “break the rules” while still being respectful of their subscribers and still see good delivery.

Read More

Broken record…

The Return Path In the Know blog listed 4 reasons mailing those old addresses is a bad idea.
Ashley, the author, is completely right and I endorse everything she said. (Although I’d really like to hear what happened to the customer that added back all those addresses. What was the effect on that campaign and future email marketing?) As I was reading the article though, I realized how many times this has been said and how depressing it is that we have to say it again. And again. And again.
A number of folks have told me that the reason they don’t pay any attention to delivery professionals is because we don’t provide enough real data. They can show that sending mail to old addresses costs them nothing, and makes them real money.
That’s not really true, though. We do provide data, they just don’t like it so they don’t listen to it. Return Path publishes lots of numbers showing that mailing unengaged recipients lowers overall delivery. I can provide case studies and data but companies that are committed to sending as much mail as possible throw up many reasons why our data isn’t good or valid.
The biggest argument is that they want hard numbers. I do understand this. Numbers are great. Direct and clear answers are wonderful. But delivery is a squishy science. There are a lot of inputs and a lot of modifiers and sometimes we can’t get exactly one answer. The data is noisy, and difficult to replicate. One of the reasons is that filtering is a moving target. Filters are not, and cannot be, fixed. They are adaptive and are changing even between one hour and the next.
Delivery experts are about risk management. They are the parents requiring everyone in the car wear seat belts, even though the driver has never had an accident. They are the fire department enforcing fire codes, even though it’s the rainy season.
Risk management isn’t about the idea that bad things will absolutely happen but rather that it is more likely that a bad thing will happen in some cases.
In this case, it’s more likely that delivery problems will happen when mailing old addresses. And if those addresses aren’t actively contributing to revenue, it’s hard to argue that their presence on a list is more beneficial than their absence.
But I repeat myself. Again.

Read More

Bounces, complaints and metrics

In the email delivery space there are a lot of numbers we talk about including bounce rates, complaint rates, acceptance rates and inbox delivery rates. These are all good numbers to tell us about a particular campaign or mailing list. Usually these metrics all track together. Low bounce rates and low complaint rates correlate with high delivery rates and high inbox placement.

Read More