What does "relaying denied" mean?

When you send mail using the email program on your PC to someone else, in your mind you probably have a picture like this:

You send email, magic happens as it goes out on to the internet, and your recipient downloads it.

We need to look a little more closely at that magic.

In reality the process is more like this:

When you send a message it's actually a multi-step process:

• 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, the "Simple Mail Transport Protocol".

• Your ISP's email server then looks at the domain (the part after the "@" in an email address) of your intended recipient, and looks up the server out on the internet that is responsible for handling that domain's email. (The "MX" record in the Domain Naming System or DNS).

• Your ISP's email server then 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 a mailbox for that email name.

• Your recipient eventually downloads email, typically using the POP3 or IMAP protocols, and the email arrives on their machine.

That's what happens most of the time.

Now, 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 to any other ISP's email server directly across the internet to deliver email.

Sometimes that's not possible. A middle-man gets involved.

The job of that server is to accept email from a server on one side, and pass it on to a server on the other.

In other words to "relay" that email.

In fact, in the first scenario above without the middle man, 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 another (the recipient's server).

Any email server that accepts email for a domain simply for the purposes of forwarding that email on to another email server is a relay.

Now, this is where spam, or rather spam prevention, starts to complicate things.

When you send email through your ISP, you "authenticate" as you send - meaning that 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 that it's for an email address on a domain that it manages, and therefore knows that it is supposed to accept email for that domain.

Each server in the path accepts the email either because the sender has authenticated and is allowed to send anything, or because the server handles the email for the specific recipient.

So, what happens if some random server tries to deliver mail to a server on which it has no authorization, and for which that server does NOT handle the email for the intended recipient?

You guessed it ... relay denied.

When an email server receives an email then:

• if the sender of an email has not been authenticated to send mail

and

• if the recipient of that email 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 for the purposes of preventing spam. Open relays were once commonplace, and a convenient way to simply 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.

So, what do YOU do if you get the "Relaying Denied" message in response to something you sent?

In reality, the vast majority of "relaying denied" messages today are due to email server misconfigurations over which you have no control. When email starts to fail server administrators often hear about it pretty quickly, and move to fix whatever has caused the issue. Trying again in a few hours, or a few days, is often the most effective solution.