What I want to ask is about SMTP servers, say, which operate at different IT companies (hosting SMTP servers, corporate SMTP servers etc.) I know that every server can be configured differently, but maybe there's an unwritten standard in the industry or at least just let me know what kind of configuration you personally installed or know about.

  • I've edited the part which you considered irrelevant. So now it's like a production server that has a short outage. Therefore, it should match your guidelines now.
    – Gregory
    Feb 14, 2016 at 9:20
  • With regards to your edit: Ultimately you can't control how other systems are configured and you have to rely on them following the recommendations from the RFC's JoeQwerty pointed out. SMTP is resilient and messages either get delivered (directly or after a delay) or returned the sender with an error message.
    – HBruijn
    Feb 14, 2016 at 13:13
  • Almost no server is on 100% or even 99,99% of the time. Let's say your average production server is on 99% of the time. Still there's a good chance it'd miss its mail, right? So though my original question did sound somewhat unprofessional, the core of it is very relevant to your "normal" production environment as well, isn't it?
    – Gregory
    Feb 14, 2016 at 15:49
  • @Gregory: That's debatable. With load balancing, high availability, etc. it's very likely that while no individual server is up 100% of the time an alternate server or servers is/are available so that the receiving "domain" can receive email 100% of the time. This doesn't negate the fact that your basic question is valid: "How do sending email servers handle email that can't immediately be delivered?"
    – joeqwerty
    Feb 14, 2016 at 17:34

2 Answers 2


RFC 5321 states that the retry interval should be at least 30 minutes and then back off to retrying every 2 or 3 hours and that the maximum retry period should be at least 4 or 5 days, BUT those aren't hard rules and aren't required AFAIK. While mail that can't be immediately delivered MUST be retried, the retry intervals aren't specified as requirements.

Each email platform/system (Exchange Server, MDaemon, Postfix, etc.) will have their own default retry settings and intervals, and you'll typically find retry intervals of 15, 30, 60, 120, and 240 minutes and a maximum retry period of 2 to 4 days.

Now on to your particular implementation; if you're running an email server in a production environment then you ought to be running it 24 hours a day, 7 days a week, 365 days a year. If you're not running it 24 hours a day, 7 days a week, 365 days a year then it really isn't a production email server and this question isn't really topical, relevant or appropriate here.

Additionally, the information you're looking for is easily discoverable with a simple Google search and some reading of the relevant RFC and/or RFC's, which I would strongly recommend. Here's one to get you started:


  • Is there a way to query a mail server to find out its delivery attempts schedule (set up)? Or the only way is to explicitly ask its sysadmin about it?
    – Gregory
    Feb 14, 2016 at 8:54
  • 1
    No, there is not. Your server should be available 24x7 down times should be the exception, not the rule. Anything other than this is doing it wrong, at least when it comes to email receipt.
    – EEAA
    Feb 14, 2016 at 9:44

What most organizations with bad connectivity/availability for their primary mail server do is to set up a more reliable secondary mail relay server elsewhere.

The DNS MX record priority will direct other mail servers to your secondary mail server when your primary mail server is unavailable.

Since you control that secondary mail server you don't need to rely on how long/frequent your senders will retry to deliver your email messages before giving up. Messages will be accepted immediately by that secondary mail server and can be queued there, rather than on the senders mail server, for as long as they need to.

Even more interesting, when your primary mail server does become available again, it can send an ETRN command to the secondary MX server, which triggers immediate delivery of all queued messages.

How to configure for instance a Postfix relay server to support ETRN is documented in the ETRN Readme, but others such as sendmail and exim also support that.

  • It's very interesting, but if I had a secondary SMTP server that is more reliable, then I wouldn't be using the primary one. I can pay probably for some 3rd party service or just use hosting for everything, but I want to do everything in house, so to speak and also save an extra expense.
    – Gregory
    Feb 14, 2016 at 8:50
  • 1
    Obviously I can't know all your circumstances and requirements and therefore I wanted to provide an alternate way of resolving the underlying issue of your question :)
    – HBruijn
    Feb 14, 2016 at 12:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.