Of all the confusing and convoluted mail server rejections commonly in use, “Currently not permitted to relay through this server” causes more Support tickets for us than any other. Worse yet, it’s not even an error that we use, so we find ourselves constantly trying to coherently explain what someone else’s mail server is saying.
Given that this is arguably the worst mail server error message ever, we’re going to try to make sense of it once and for all.
When reviewing the following example, realize that the IP addresses and server names will change to reflect the server that is sending the email and also the one which is refusing to accept it. We’re replacing the receiving/rejecting server IP with 111.111.111.111 and the sending server’s IP with 222.222.222.222.
Also note that the layout and formatting for these rejections can often be confusing as well, with lots of line breaks and “550′s” scattered about.
Disclaimers aside, this ugly bounce/rejection/NDR message typically says:
SMTP error from remote mail server after RCPT TO:: host 111.111.111.111:
your-mailserver.com [222.222.222.222]: is currently not permitted to relay through this server.
Perhaps you have not logged into the pop/imap server in the last 30 minutes or do not have SMTP Authentication turned on in your email client.
While the language is fairly uncomplicated, at the same time it’s also impossibly confusing for the average user to decipher. Further, because of the dual nature of this error message, it actually confuses many experienced email and network admins too.
What on earth does this mean?
While the “currently not permitted to relay through this server” is a convoluted explanation, what it means is that the receiving server doesn’t believe that it is supposed to accept messages for the recipient domain, so it’s refusing/rejecting the email you sent.
Instead, the recipient server thinks that you’re trying to use it to deliver/relay messages to some outside domain for which is not responsible.
Usually this is seen after someone manually changes settings on a mail server or some automatic update is applied and the server which used to happily accept mail for “recipient.com” no longer thinks it’s supposed to host mail for them and rejects with this error instead.
On the other hand….
On the other hand, these error messages also contemplate that perhaps you’re not some outside mail-server trying to deliver inbound mail, but instead you might be a local user with a mail account on the server who is trying to send outbound email via SMTP but you (or your email software) forgot to login and authenticate.
The fact of the matter is that most mail-servers cannot actually tell the difference between another mail-server connecting to deliver inbound mail or an individual user who is connecting to send outbound mail. That may sound hard to believe, but it’s sadly true.
And that is why this part is confusingly tacked added to the end of the rejection:
Perhaps you have not logged into the pop/imap server in the last 30 minutes or do not have SMTP Authentication turned on in your email client.
Having this one rejection message trying to cover two completely different scenarios, combined with the most confusing of language, is what causes so many problems and misunderstanding.
Now, given that the above explanation still might not make perfect sense to the average user, let’s re-write the rejection to say what it really means:
We’re sorry, our server will not accept your message.
If you are a mail-server connecting to our system to deliver this message to us, then please be aware that our servers are not configured to accept mail for the recipient’s domain.
If you are a local user, trying to send this email outbound for delivery, the problem is that we don’t see you as having logged into the SMTP server. Please configure your software to use SMTP Authentication and/or restart your email client software.
Granted this still probably won’t make perfect sense to someone with no knowledge of how email actually works, but it’s hopefully a lot clearer for the rest of us.
