Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I see an email returned due to a hard bounce, after how many days is it acceptable to resend to that email address. It is possible for emails to be reactivated or for temporary outages, so it doesn't make sense to keep an email in my hard bounce email list forever. I've already seen cases where I receive emails from addresses that were put in my hard bounce email list months ago.

Any recommendations? Are there specific recommendations from ISPs?

share|improve this question

A hard bounce is an indication that you should never send a message to that address. The bounce message should contain an indication as to why you were bounced. If the address does not exist, then no amount of waiting is likely to resolve the issue.

If you get a soft bounce, such as you should get for over quota, use an exponential backoff. This should be part of the default ruleset for your mail server. Fail the message after at least two days. If you back off to daily retries, it is common to wait at least a week before failing the message. You may want to periodically (first failure, and after a day or two) notify the sender of the delay.

If you were hard bounced because of your configuration, then wait until you have resolved the issue. My mail server blocks for many of these conditions which may result in a hard bounce:

  • Improper DNS entries. Your address must resolve from IP address to DNS name and back to the same IP address. This is part of the RFC.
  • Sending email directly from a dynamic address. Use your ISP's relay, or another relay which requires authentication. (You will likely be violating DNS conditions above rule as well.)
  • Being blacklisted. Almost all the blacklists will allow you to get off them reasonably quickly. You can also get blacklisted at the receiving site, which can be more difficult to resolve.
  • Sending from an address not allowed by your SPF (Sender Policy Framework) DNS entries.
  • Supplying incorrect data when you send your HELO or EHLO message. This should be the fully qualified DNS name corresponding the the IP address. localhost, GEORGE, MY_HOST, and such are not valid, but may be accepted. Also claiming to be the host you are sending to or another host in their domain is not valid.
  • Sending incorrectly formatted messages. Missing headers, invalid dates, etc.
  • Sending a message which is identified as SPAM by a spam filter.
  • Sending from an address which can not be verified. Your IP address should be allowed to send from that domain.
  • Sending from an address belonging to a domain that is handled by the receiving system. This should require you to authenticate as the sending user first.
  • Using a message id indicating that the message was sent from the receiving domain.
  • Running an open relay.
share|improve this answer

If the bounce message states that the account is not active or does not exist you should stop sending to that account until you are told otherwise. Sending to an account that has responded in this way previously is usually just a waste of time.

If the bounce message was due to an account being over quota, or some other generally temporary situation, then I would hold back on resending for at least 24 hours, then if the second message also bounces, hold back a few days before sending a third time and so on extending the retry delay each time until the message gets through, returns a more permanent error, or you give up.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.