Support Start > Greylisting Error

If you sent a message to one of our customers, and your mail server returned it as “undeliverable” because your address is “greylisted”, the mail server you’re using to send your messages (which is probably run by your ISP or your company) isn’t working properly.

The quick solution to this problem is to resend your message from the same address. Your message will almost certainly go through if you send it again.

However, you should also report this problem to the person who runs your outgoing mail server (probably your ISP or your company network administrator). Your outgoing mail server has a technical problem that needs to be fixed to make sure the same problem doesn’t happen again in the future.

The rest of this page contains technical information that may help your network administrator fix the problem.

A note to mail server administrators

If you’re seeing a link to this page in your mail server logs (rather than in a permanent “bounce” message), that’s probably normal. If your mail server is properly configured, it will automatically “queue” the message and keep trying to resend it again. Our servers will accept the message after a short time has passed.

In other words, seeing a link to this page in your logs doesn’t mean anything is wrong. The message hasn’t been permanently rejected; it’s merely been delayed for a short time. A problem exists only if you see a link to this page in a permanent bounce message, which would indicate your server didn’t retry the delivery as required by the Internet standards described below.

What is greylisting?

Greylisting is a technique that we, and many other ISPs, use to protect the mailboxes of our customers from spam.

The idea behind greylisting is that when our mail server sees a “suspicious” incoming message — one that is probably spam — it will send a “454 temporary rejection” error code to the sending mail server. The error code means “We can't accept this email message right now, but try sending again soon and we'll accept it then”.

This temporary rejection code is used for all sorts of temporary mail problems, and happens often on the Internet for all sorts of reasons. The sending mail server should try sending it again in a few minutes, and our servers will then accept the message. The person sending the message doesn’t see a “bounce”, and in fact has no idea that anything unusual happened.

Most of the messages tagged as being “suspicious” are actually spam, not personal messages, so this system has a minimal effect on normal email. But it has a great effect on spam, because the vast majority of spammers use special software that doesn’t meet Internet standards and will not try sending the message again. The spammer’s software simply deletes the spam and the recipient never sees it.

What happens if the sending mail server doesn’t try sending the message again?

If a sending mail server receives a “454 temporary rejection” error code, it’s required by Internet standards to retry sending the message. We can’t emphasize that enough: any mail server that doesn’t retry the message isn’t sending mail properly, and will be unable to properly deliver mail to tens of millions of mailboxes on the Internet that use greylisting.

A mail server with this problem will have all sorts of other problems delivering mail, regardless of greylisting. For example, it will be periodically unable to deliver messages to servers that temporarily reject messages when they’re busy, such as those at hotmail.com. A server misconfigured in this manner can find that as much as 5% of mail sent to hotmail.com is unnecessarily rejected.

Where do Internet standards say that retrying is required?

The technical explanation of why retrying is required is that RFC 2821 defines a 454 error code as a “Transient Negative Completion reply” in section 4.2.1. Then, in section 4.2.5, it specifies that if an SMTP mail server receives such a reply, it must continue “retrying delivery some reasonable number of times at intervals as specified in section 4.5.4.” Finally, section 4.5.4 says “mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender”, and that retrying should continue for “at least 4-5 days”.

So what does this all mean to me?

Greylisting can delay a suspicious message for a short time, but it will never reject a message or cause it to be returned as “undeliverable” — as long as the sending mail server meets Internet mail standards.

If your SMTP server sent one of our customers an email message but received a “454” temporary error code, and your server immediately returned the message as “undeliverable” instead of retrying it for several days, your server is misconfigured. You should fix it so that when it receives a 454 error code, it retries the delivery for at least a few days, instead of immediately returning the message to the sender. This will ensure your mail server can reliably deliver messages.