Mail that is held back

On some servers there is an extra machine in front of the mail server: a mail gateway. All mail for your domain arrives there first, is checked there, and only then goes on to your mailbox. What looks suspicious does not go on — it stays on the gateway, in the quarantine.

This page is about that quarantine: how to see what is being held, and how to get a message through anyway.

Where to find it — Panel → Hosting → Accounts → your account → E-mail → Quarantine. If that tab is not there, there is no mail gateway in front of your server. The mail server filters for itself then, and unwanted mail belongs in the Junk folder — see Keeping spam out.

What you see

One row per message the gateway is holding, newest first:

The last seven days are shown by default. The menu above the table on the right switches to one day or thirty, and the search box filters on sender, recipient or subject.

You see only mail for your own domains. What the gateway holds for another customer is neither visible to you nor requestable.

Getting a message through anyway

1. Click the row. A panel slides open on the right with everything about it.
2. Click Deliver anyway.

The message is delivered to the mailbox it was addressed to, exactly as it was sent. It is there within a few seconds.

Does mail from this sender keep getting stuck? Releasing only does something for this message. Put the sender on the mailbox's allow list — E-mail → click the mailbox → the Spam tab → Always allow — and they come straight through from then on. With a mail gateway in front of your server the panel writes that rule in both places at once: on the mail server and on the gateway.

One page, two kinds of row

Since this round everything held or marked shows on one page, even when there is no mail gateway in front of your server. The badge in the Source column says where the message is, and that decides what you can do with it:

If none of your domains has a gateway you get an explanation at the top instead of an error — nothing is broken, there is simply nothing to release. If you have both kinds (one domain behind the gateway and one not), the explanation says how many domains are on each side.

Two switches, and who sets them

The gateway has two switches, and they stand apart:

• Filter incoming mail — the world delivers to the gateway, which filters and hands the mail on to the server. Your domain's MX then points at the gateway.
• Send outgoing mail through the gateway — your mail leaves the server through the gateway instead of directly. Useful for a clean sending address; there is nothing for you to configure.

They are set at three heights — server group, server, or your account — and the most specific choice wins. On for the whole group but off for your account means off. The other way round works too: your account can be on while the group is off. The page labels whether the choice was made here or inherited from a level above.

Managing the gateways themselves — the address, the password, the machines — is the platform administrator's. What you see and set is whether your mail goes through one.

Deleting a message

The same panel has Delete message. The panel asks for a confirmation first, because this cannot be undone: the message is then gone from the gateway and can no longer be delivered.

You do not have to delete anything. What you leave alone disappears on its own once the gateway's retention period is up.

Just switched on, and mail is still refused for a moment

When you switch the mail gateway on for a domain, the panel writes that domain to the gateway straight away — but the gateway itself needs a few minutes before it really accepts mail for that name. Measured on our own gateway: refused at the moment of switching on and for some three minutes after that, accepted around the five-minute mark.

What you can see during those minutes is a sender getting an error back along the lines of relay access denied or user unknown in relay recipient table. That is not a setting that is wrong, and it resolves itself.

So: switch the gateway on, wait five minutes, and only then test with a real message. If it is still going wrong after a quarter of an hour, see When something is not right below.

What changes about your DNS

With a gateway in front of your server, your domain's MX points at the gateway instead of at the mail server itself. That is exactly the intent: it is how mail arrives there first. If we host your DNS this is already arranged and there is nothing for you to do.

If your DNS is somewhere else, look at E-mail → DNS records for what should be published now. The MX is the gateway's name; mail.<your domain> keeps pointing at the mail server, because that is where your mail program signs in to collect and send mail. That does not change.

Checking for yourself where your mail arrives

If you want to see with your own eyes that mail goes past the gateway first, ask for your domain's MX. This works from any computer:

dig +short MX yourdomain.com

10 pmg.corecp.dev.

The gateway's name there means it is right. For comparison: the name your mail program signs in to still points at the mail server itself, and that is how it should be:

dig +short CNAME mail.yourdomain.com

stck1.corecp.dev.

When something is not right

Is the connection to the gateway really that gateway?

Short answer: yes, and it is checked again on every single connection.

A mail gateway usually carries its own self-signed certificate. Your computer can do nothing with that, because it appears on no list of trusted issuers. So the panel works with a fingerprint instead: your administrator records once which certificate the gateway is supposed to show, and the panel talks to nothing else.

That is less simple than it sounds. A secure connection is allowed to be resumed — the second time two machines speak, they skip the introductions because they already know each other. On a resumed connection the fingerprint used not to be looked at again. That is fixed: the check now sits on the resumed conversation too, so the second, tenth and hundredth connection all ask whether this is still the same gateway.

You notice none of this while everything is right. When it is not, you see it straight away:

1. Go to Email → Gateway.
2. Press Test connection.

Once the gateway has a real, issuer-signed certificate, the fingerprint field may be left empty — the ordinary check then applies.

Where the gateway form lives

Since August 2026, managing gateways sits in one place with every other coupling the platform has: Settings → Integrations. The Mail gateways card shows, per gateway, its status, the machines it is made of and when it last synchronised; the Manage gateways button opens the form where you add one or change it.

The old address keeps working. Anybody with /mail/gateway in their bookmarks still lands on the form — including the node group that bookmark named.

What did not move are the switches filter inbound and relay outbound through the gateway. Those live where the object lives: on the server's page, on the account's page, and on that account's mail page. One switch in one place — see above.

More about the other couplings (Cloudflare, Telegram, the certificate authorities and the per-server add-ons) is in Integrations.