Continuity
What happens to your mail when your server is down
Because the gateway is your MX, senders hand mail to us and not to you. When your destination is unreachable, that mail is queued and retried — for five days — instead of being returned to the sender.
Included on every protected domain. Nothing to configure and nothing extra to buy.
The failure this prevents
An Exchange server down over a weekend. A Friday-evening firewall change nobody notices until Monday. An expired certificate on a mail host. In each case the outage itself is recoverable; what is not recoverable is every message sent to you in the meantime being bounced back to its sender with a permanent failure.
A queue lifetime is the setting that decides which of those happens, and the difference between one day and five is the difference between a bad Monday and a lost week of business mail. Ours is five days.
And you can see it
Queued mail that nobody can look at is only marginally better than bounced mail. The console shows the queue per domain:
- What is waiting for each of your domains, and for which recipients.
- How long it has been there, and when it would start to bounce.
- The message itself, readable while it waits, so an urgent one is not stuck behind an outage.
- Send it now — when your server comes back, flush the queue rather than waiting for the next retry interval.
A queue entry belongs to whoever owns the recipient's domain, resolved from the domain record rather than from anything in the message. One tenant cannot read another's waiting mail.
And the person whose mail it is can read it too
The console shows the queue to whoever administers the domain. The person actually waiting on the invoice is the recipient, and they do not have a console account — almost nobody's users do.
So an administrator can issue a link for one recipient. It lists the messages queued for that one address and lets them read them, with no account and no password. It expires, it cannot release or delete anything, it cannot see anyone else's mail, and issuing one is recorded.
The link has to be handed over out of band — chat, phone, or an address on a domain that is still working. It cannot be emailed to the address it was made for, because that mail is exactly what is not being delivered. That is not a gap in the design; it is the constraint the whole feature exists inside.
What this is not
This is not a webmail replacement. You cannot send as your users, reply from their addresses, or work out of folders while your server is down. Products that offer that hold your credentials, and we do not.
Reading what is waiting and releasing it when the server returns is the part that can be done correctly without holding a customer's mailbox credentials, so that is the part we do. If a full continuity mailbox is a requirement for you, this is not that, and we would rather say so than let you find out during an outage.
Mail delivery outranks filtering
The same principle runs through the whole product. A scanning stage that cannot be reached is bypassed and the fact recorded, rather than mail being held until somebody notices. A reputation service that stops answering delays a signal; it does not delay a message.
Mail flow is probed end to end every five minutes and each filter is exercised every fifteen, so a failure is found by a test rather than by a customer.