To understand what this message means, we need to understand, at least at a conceptual level, how email makes its way from your outbox to your recipient’s inbox.
That trip can be short or long, depending on a number of factors.
And one of those factors is the relay.
Become a Patron of Ask Leo! and go ad-free!
- How email gets from your outbox to your recipient’s inbox is complex magic.
- Multiple servers can be involved, including servers that simply relay messages from one to another.
- When neither the sender nor recipient is known to the server, it’s considered an “open relay”.
- Open relays can be abused by spammers, and are therefore denied.
- Today, “relaying denied” is typically the result of server misconfigurations you have no control over.
- There are a few things you can double check, just in case.
Email, in concept, is magic
When you send a message using the email program on your computer, you may have a picture like this in your mind about what’s happening:
You send email, magic happens, and your recipient downloads it.
We need to look a little more closely at that magic.
Email and servers
In reality, sending an email message is a multi-step process, even at the highest level.
Here’s what happens:
- Your email program contacts your ISP’s email server (or the server of whatever email provider you use) and sends that message to that server, typically using SMTP: Simple Mail Transport Protocol.
- Your ISP’s email server sees the domain (the part after the “@” in an email address) of your intended recipient, and looks up the internet server responsible for handling that domain’s email. (The “MX” record in the Domain Naming System or DNS contains this information.)
- Your ISP’s email server contacts that server directly, and, once again using the SMTP protocol, sends the email on.
- The receiving server, because it handles email for the recipient’s domain, accepts the email, examines the email name (the part before the “@”), and places the message into the mailbox for that email name.
- Your recipient eventually downloads email to his PC, typically using POP3 or IMAP protocols.
That’s what happens most of the time.
But it wasn’t always so.
Email and relay servers
The email system — like the internet itself — is designed to be both flexible and robust.
The scenario above assumes that any ISP’s email server can connect directly to any other ISP’s email server to deliver email. Particularly in the early days, that wasn’t always possible. Even today, it’s possible that your ISP’s email server may not be able to connect directly to the email server of your message’s intended recipient.
The result is that a middleman gets involved: the relay server.
The job of a relay server is to accept email from a server on one side, and pass it on to a server on the other. In other words, its job is to “relay” that email.
In fact, in the first scenario above (without the middleman), your ISP’s email server is acting as a relay as well; it’s accepting mail on one side (from you) and sending it on to the other (the recipient’s server).
Email relaying and spam
This is where spam, or rather spam prevention, complicates things.
When you send email through your ISP, you “authenticate” as you send, usually by including your account ID and password in your email program’s email-sending (SMTP) configuration. This means your ISP knows who you are, and that you have the authority to send email to anyone through the server.
When your ISP’s server contacts the recipient’s server, it does not authenticate. The receiving server looks at the destination of the email, knows it’s for a domain it manages, and therefore knows it is supposed to accept email for that domain from anyone.
Each server in the path accepts the email either because:
- The sender has authenticated and is allowed to send anything
or
- The server handles email for the recipient.
Relaying denied
So, what happens if a server tries to send mail to another server without authentication, and that server also doesn’t handle the email for the intended recipient?
You guessed it: relay denied.
When an email server receives an email:
- If the sender of an email has not been authenticated
and
- If the recipient of that message is not handled by that server
it’s considered a request to relay that message on to its final destination.
A server that would accept email from just anyone and forward it on as needed is called an “open relay”, meaning anyone could use it without accountability. In other words, spammers.
Most servers deny relays specifically to prevent spam. Open relays were once a commonplace and convenient way to connect up and send email. Today an open relay is considered a serious security hole, as it allows spammers unfettered access to send their junk.
Dealing with “Relaying Denied”
With all that as background, what do you do if you get a “relaying denied” message in response to something you sent?
- Double-check your own email program’s configuration — specifically its SMTP settings — making sure you’re following your ISP’s instructions.
- Double-check the email address you’re sending to, making sure that it’s correct.
- Try again later.
In reality, the vast majority of “relaying denied” messages today are due to email server configuration errors over which you have no control. When email starts to fail, server administrators often hear about it quickly and move to fix whatever caused the issue.
Trying again in a few hours, or a few days, is often the most effective solution.
Do this
Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.
I'll see you there!
I loved your first diagram and laughed as it came up. ‘magic happens’ [like Rumsfeld’s ‘stuff happens’] describes so much of what hasppens in life, not just in computing.Much of medical pratice and therapy is covered by ‘magic happens’.
Leo, there’s actually another step early in the authentication process that can cause this error, and it’s one often encountered by business traveleres like me. My e-mail is provided by RoadRunner, and when I’m home, I’m physically connected to the RoadRunner network domain and everything is fine. When I travel, however, I’m connected to either a hotel’s or client’s network, or in some cases a public (wireless) network.
So, the first thing the RoadRunner servers do is to authenticate the server I’m physically connected to. The RoadRunner servers will start by determining if they will “trust” the server I’m connected to; that can fail if the server I’m on doesn’t meet the minimum level of security protocols (this is usually a maintenance issue with a hotel’s network). (The figures above could be updated to add this “connection domain” server between your computer and the SMTP server.)
Sometimes I can work around this by changing my outbound settings to “log on to inbound server before sending mail”. If that doesn’t work, I contact the hotel network provider’s support number and ask for the IP address of their SMTP server. (If you do change the SMTP server while on the road, set an outlook reminder to change it back when you get home.)
This solves the first half of the authentication problem (denial by your usual SMTP server), though your recipient’s servers may still deny relaying from the hotel’s SMTP server. In that case, there’s always your ISPs web mail option (BCC yourself to get a copy to save in Sent Mail).
Finally, if you consistently have problems with one hotel’s (or hotel chain’s) network, bug them to keep their servers up to date!
div class=”leocomment”>There’s another hotel related scenario as well: Why can’t I send mail from my hotel room?
14-Oct-2009
Hello Leo!
Thks for a very good explanation about what really happens when sending an e-mail. An image is worth a thousand words – once again proved to be true.
Wonderful work!
Viggo.
Hello Leo!
I really find Good and helping answers from you everytime I visit your site. Especially the “relaying denied” The explanation is weel done that even a blind person can understand. Thks
See the comments at :
http://ask-leo.com/what_is_pop_or_pop3_or_a_pop_account_and_what_about_smtp.html
might give you more info about how to prevent unwanted Relay
This is a good explanation. But, the problem is VERY inconvenient. It happens all too often for me. I think the ISP should take extra steps to make sure their customers do not have to go through this problem. I let my ISP know often when this error occurs.
Thanks for the clear explanation. As it says, “A picture tells a thousand words”. I’ve already had this problem for a few days, checked numerous websites for solutions, talked to Microsoft staff (they wanted 90 Malaysian ringgit from me…of course I did not accept it), talked to my ISP provider staff, checked a few more websites, and finally hit the jackpot. Your clear explanation finally made sense and….presto! Problem solved. Thanks.
sweet and straight to the point, i’m sure to be visiting this often
In the following relaying denied error:
Your message cannot be delivered to the following recipients:
Recipient address: contact@xxx.com
Reason: Remote SMTP server has rejected address
Diagnostic code: smtp;550 5.7.1 … Relaying denied
Remote system: dns;mail.xxx.com (TCP|yy.yy.yy.yy|49953|xx.xx.xx.xx|25)
How can I tell which server exactly is rejecting the relaying? xx.xx.xx.xx is the IP address of the server where I am hosting the xxx.com domain, but I don’t recognize the IP address yy.yy.yy. Pinging it times out and traceroute to it hangs on the 24th hop.
The domain xxx.com is registered with godaddy and hosted at xx.xx.xx.xx, with the zone file having (I believe) the correct settings taken from another domain hosted at xx.xx.xx.xx where mail delivery works properly.
Thank you.
Vlad
The solution in my case was to add xxx.com to local-host-names.