Relay to your own server

Some organizations run their own mail server, e.g. an on-premises Exchange, a groupware appliance, or a departmental application, but want their domain's public mail to arrive here first, where we filter, log, and authenticate it.

Relaying does this. We accept the mail, give it the full treatment for incoming mail, and pass it to a server you run.

Nothing else about the domain changes

The MX records still point at us, and every other address keeps its existing type: domain user, group, forwarder, mailing list, rejector, or send-only account.

Two kinds of account

You relay to one of two account types: a user or a relayer.

	Domain user	Relayer
A mailbox here	Yes, unchanged	None
Sign-in and webmail	Yes	None
How you create it	As a domain user, then a setting on it or the domain default	As its own account type
Spam filtering	The same as an ordinary mailbox	Stricter, like a forwarder
Spam we pass to your server	Never	Not applicable; we refuse it before we accept it
If your server refuses a message	We tell the postmaster	We tell the postmaster and the sender
How you remove it	Set it to off, or delete the domain user	Delete the relayer

A domain user that we also relay to your server

A domain user is an ordinary mailbox, with storage, a sign-in, and webmail. Edit one and set Also relay to my own server. Nothing about the mailbox changes: its owner keeps reading it with webmail, IMAP, or POP3, with the same password, app passwords, and spam filtering. In addition, we pass every message we accept for the address to your server.

The setting belongs to that domain user. It appears on their edit page only once you turn relaying on for the domain, and it goes away with the domain user: delete the mailbox and the relaying stops, and the server refuses the address like any address that doesn't exist.

The control has three states: Default, on, and off. The domain carries a default of its own, and a mailbox left at Default follows it; see Relay every mailbox on the domain. The help text on the mailbox names the current value of that default.

Use this when the mail is really read in two places: somebody reads it here, and your own system also needs a copy, for archiving, indexing, a workflow, or a groupware calendar.

A relayer, which has no mailbox here

A Relayer is an account type, created like any other: open Email & Identity → Accounts, choose the domain, select Create, then Relayer. It takes the address and nothing else.

A relayer has no storage, no sign-in, no webmail, and no self-service portal. It's a route: we accept the mail, filter and log it, and pass it on. The mailbox that finally holds the message is on your server.

Use this when the address doesn't exist here at all: the person's real mailbox is on your Exchange or groupware server, and we are only the entry point.

The difference that matters

Your server refuses a message to…	What it means
A domain user	Nothing is lost; the message is in the mailbox here. We tell your postmaster address, and the sender nothing, because telling the sender their message failed wouldn't be true.
A relayer	The message really didn't arrive, and there's no copy anywhere. We tell your postmaster and, under the conditions below, the person who sent it.

Every other difference on this page follows from that one: the spam filtering, who we tell, and whether we pass spam on. Everything else applies to both kinds unless the text says otherwise.

This is not a catch-all

You create one relayer for each address that lives on your server. There is no option that says "send everything you don't recognize to my server"; we left it out deliberately.

The same thing under other names

Other control panels call this a default address, a default mailbox, default mail, or a catch-all account. All mean the same arrangement: the server accepts every address on the domain, whether it exists or not, and passes the ones that match nothing somewhere else.

Here we differ from most other products

Elsewhere, a catch-all is the normal way to put a mail server behind a provider: the provider declares the domain a relay domain, accepts everything for it, and passes it all to the server behind. Nobody maintains a list of addresses, which is why people like it.

If you've set this up before, on another panel or with a provider in front of your Exchange server, that's the arrangement you'll look for. We don't offer it.

The reason is the value of a refusal. We refuse an address that doesn't exist on your domain at delivery time, with a permanent error. That is what makes a bad address costly for a spammer: a sender who tries a@, aa@, and aaa@ learns immediately that they aren't real, and stops.

With a catch-all, the server accepts every guess, scans it, queues it, and delivers it to your server. Only the sender's wish limits the volume, and every message lands on the machine you asked us to protect. Filtering can't help: a message to an address that doesn't exist isn't a filtering question.

The cost is the one the catch-all avoided: your address list here has to match the list on your server. You can create relayers in bulk from the API and the command line, as well as from the panel.

Turn relaying on

You turn relaying on once per domain. Open Services, select the zone, select the Mail service for the domain, and edit Relay to Your Own Server.

Until relaying is on there, we relay nothing:

• The Also relay to my own server control doesn't appear on a domain user's edit page.
• A relayer you create does nothing. The server refuses mail to its address exactly as it refuses an address that doesn't exist, and the relayer's page says Nowhere: relaying is turned off for this domain.

tip

You can create relayers before you turn relaying on. They start to work the moment you do.

If you turn relaying off later, the relaying stops and nothing is deleted. Your relayers and your domain users' settings are still there when you turn it on again.

The mail that waits when you turn relaying off

When you turn relaying off, we accept no new mail to relay, but we don't delete the mail already waiting in the queue. It continues as usual until the queue is empty.

Method	What happens to the mail that waits
We send it to you	We keep delivering it, and retry after a failure as before. Send now keeps working.
You collect it from us	Your server can't collect it, because a collection credential works only while relaying is on. The mail stays in the queue.

With both methods, a message that waits longer than your retention period expires, and we report it as when relaying is on. See When your server does not take a message.

Until the queue is empty, the Status tab of Mail Relaying says that relaying is off and we still handle the queue, and the queue view keeps showing the waiting mail. In the API, draining is true. Some minutes after the queue empties, the panel removes the remaining configuration.

Before you turn relaying off for a server that collects

Let your server collect the queue first, or switch the method to We send it to you. Wait until the queue is empty, then turn relaying off.

If you turn relaying on again before the queue is empty, the waiting mail continues as usual.

Relay every mailbox on the domain

Setting mailboxes one at a time is right when a few addresses are read in two places. When all of them are, the domain carries the same setting as a policy, on the same Mail service page under Account Policy: Also relay to your own server.

It behaves like every other email policy:

State	Which mailboxes relay
Off (the default)	Only the domain users you set individually.
On, not enforced	Every domain user who didn't choose for themselves. A user who set their own control to off stays off.
On, and Enforced	Every domain user on the domain, including those set to off.

The policy doesn't affect a relayer. A relayer exists only to be relayed, and always is.

It still does nothing until you turn relaying on

The policy and the relay switch are two different forms on the same page. With the policy on and relaying off, we relay nothing, and the panel marks the policy Inactive to say so.

Enforcement is a bulk change to what your server receives

Enforcement starts copying every mailbox on the domain to your server, including one whose owner turned the setting off deliberately and one nobody wanted to leave this server. Nothing is lost or deleted, and clearing the policy stops the relay, but until then your server receives all the domain's incoming mail.

We still hold spam back, as for any relayed domain user. It stays in each mailbox's Spam folder.

Two ways for the mail to reach you

Choose one per domain, on the same page.

	We send it to you	You collect it from us
How it works	We open an SMTP connection to a host and port you give us and deliver each message, recipient address unchanged.	The mail waits in a spool on your account. Your server signs in and collects it over POP3.
What it needs	Your server must be reachable from the internet.	Nothing reachable from outside your network.
Right for	A server with a public address.	A server behind a firewall, or on an office connection.
Names elsewhere	No other name.	MDaemon calls it DomainPOP. Kerio, IceWarp, getmail, and similar products also support it.

Both kinds share one spool and one collection, so a domain with some mailboxes here and some on your server, relayed domain users and relayers together, is still one mailbox to collect from.

You can change the method later. Mail in the queue stays where it is, and whichever method is active then delivers it.

If we send it to you

Fill in your server's host and port, then choose how much protection the connection needs:

TLS setting	Meaning
Opportunistic (default)	We encrypt the connection when your server offers encryption.
Necessary	For a server that always offers TLS.
Verified	As Necessary, plus we check the server's certificate against its hostname.

If your server asks us to authenticate, set a username and a password. Leave them empty if it recognizes us by IP address instead.

Below "Necessary", a password can travel unencrypted

You can set credentials at any encryption level, including none; some servers offer a sign-in only without TLS. Choose that deliberately. The panel marks the combination where it shows the credential.

A message arrives from an address of ours, not from the original sender, for two reasons: it then passes SPF at your server, and a later bounce comes back to us rather than to a stranger. We don't change the body, so the original DKIM signature still verifies, and the original sender is still in the message's From: header.

Your server can still see how the message authenticated

Rewriting the envelope sender creates a small version of the forwarding problem: the original sender's SPF no longer matches, so a server that checks DMARC after the relay would refuse genuine mail.

We seal each message with ARC when it arrives, with your domain's own key, and relay it with that seal unchanged. A server that checks ARC reads the result from the message's first arrival and doesn't judge our address. A cloud provider does the same if you told it to trust your domain as a sealer.

The real sender is in X-Envelope-From

The envelope delivery address is ours, so your server would otherwise have no way to see who really sent the message, which it needs if it makes its own SPF or DMARC checks, records a return path, or decides where a bounce goes.

We record the original envelope sender in that header before we rewrite the envelope, on every message in the spool, so the information is never lost. An empty envelope sender, as on an automated bounce or a delivery report, is recorded as <>.

The most common mistake in the setup

Your server must accept mail for your domain from our IP address.

When your server doesn't answer, or answers with a temporary error, the mail waits and we try again, with a longer interval between attempts. Nothing is lost while your server is down for an afternoon or a weekend.

If you collect it from us

Create a collection credential on the Mail service page.

The panel shows the password once

You can't recover it later. Store it with your server's configuration.

The username is the same for every credential on the domain, and the panel shows it: [email protected]. It isn't one of your addresses; it names the spool they all share.

Point your server at our mail server's hostname, over POP3, with that username and the credential's password. IMAP works too, with the same credential, and is useful for looking at the spool yourself without removing anything.

Three things have to be right.

Your server must know which address each message went to

A POP3 mailbox holds messages, not delivery envelopes, so your product finds the recipient by reading a header.

• Set your product to use Delivered-To. We set it on every message in the spool, to the address the sender really used, with the +extension part.
• If your product can't use Delivered-To, we also add X-Envelope-To, with the same value.
• Don't set your product to read the Received lines. They name an internal address of ours, not one of yours. A wrong setting here delivers a whole domain's mail to one internal user, silently.

• The sender is in X-Envelope-From. Every message in the spool carries the original envelope sender there, whether you collect it or we send it, including <> for an automated bounce or a delivery report. A product that builds a return path, or makes its own SPF or DMARC checks after collecting, has to read this header, not From:.
• A delete tells us you have the message. A message stays in the spool until your server deletes it at the end of a collection. A collector set to leave mail on the server collects the same mail again.

Change the password without interruption

Create a second credential, then delete the first. A delete takes effect immediately.

Limit where a collection can happen from

A collection credential opens your domain's whole spool, so you can limit it to the addresses your server really connects from. Each credential has a Collect only from these addresses box: individual addresses or CIDR ranges, one per line, in the same form as a domain user's list of allowed addresses.

If you leave the box empty, the credential takes your domain's Allowed IP Addresses policy, which accepts any address until you set it.

Leave the box empty for a server whose address changes

A credential that can't reach us looks exactly like a broken password: mail collects in the spool silently, until it starts to expire. Set the box only for a server on a fixed connection.

Send through us with the same credential

The collection credential can also send. Your server uses it as an authenticated SMTP account, and the mail leaves from our servers, signed with your domain's DKIM key and covered by its SPF record.

For a server that receives its mail this way, that's usually better than a direct send: we maintain the reputation of our outgoing addresses, and the messages appear in your Email Traffic Log with everything else.

What the credential can send as

Only the domain's relayed addresses: its relayers and its relayed domain users, including their +extension forms. If [email protected] is relayed, [email protected] and [email protected] both work.

It can't send as a domain user we do not relay, as an address on another domain, or as anything else. Every such attempt is refused.

The credential belongs to the domain's Mail service, not to an account, so a domain user's password, app passwords, and sign-in settings don't affect it. A relayer has no sign-in of its own, so nobody can authenticate as a relayer directly.

Spam and filtering

The two kinds are filtered differently, again because of whether a copy stays here.

A relayer is filtered more strictly than an ordinary domain user, for the same reason as a forwarder: we pass the mail on, so your server counts its spam against us, and after that against your server's own reputation.

• We refuse spam during the connection from the sending server. That returns the message to the sender and leaves nothing on our side.
• Everything we accept goes to you exactly as it is, with our authentication headers and spam-score headers unchanged. Your server then applies the policy you chose.

The result to know about

A legitimate sender whose mail gets a bad score is refused, not filed. That sender gets a delivery failure from their own provider, so nothing disappears without a message to somebody.

A relayed domain user keeps the filtering it has today. Nothing about your incoming mail changes because we relay the mailbox, and its owner sees exactly what they saw before.

Spam is filed in the mailbox's Spam folder, as usual, and not passed to your server. Nothing is lost, because the message is in the mailbox, and your server doesn't receive traffic it would have deleted.

The copies we hold back appear in the queue view under Not relayed, with the score that decided each one. There is no setting that sends them to you.

Why

A domain user is a mailbox first. If we made its filter stricter because a copy also goes to your server, we'd start refusing mail its owner would otherwise read, in exchange for a copy they asked us to send to themselves.

When your server does not take a message

Your server can refuse a message permanently, or a message can wait uncollected past your retention period, five days by default. In both cases we report it:

We report it to	When
The postmaster address of your account	Always, for both kinds. The report names the recipient, the reason your server gave, and where we keep the message. This is the copy that tells you something needs your attention.
The person who sent the message	For a relayer only, at most one report per sender in 24 hours, and only when that sender's message was correctly authenticated.

Why we don't write to a sender we can't verify

Replying to a forged sender means sending mail to a stranger about a message they never sent.

And a failed relay to a relayed domain user never tells the sender anything: their message did arrive and is in the mailbox, so telling them it failed wouldn't be true.

A message that failed this way is kept in a Failed folder in the spool, not deleted. The queue view lists each one's date, sender, recipient, subject, and size. A message not relayed because of a spam score is kept separately, under Not relayed, with its score.

The panel has one action for these messages: Send now. It tries the whole queue again.

See what happened

The relay log on the Mail service page lists every message that reached a final state: relayed, collected, not relayed because of spam, failed, or expired, with your server's reply where there was one.

The log includes the successes. "Did my server really get it?" is the question this screen exists to answer.

Mail that still waits is in the queue view on the same page instead, which shows how many messages wait, the oldest one, the last error, and the time of the next attempt.

Storage and limits

The spool is inside your account, so mail that waits for delivery or collection counts against your account's disk quota, like everything else.

warning

A long retention period lets a server that is down for a long time fill your allowance, not ours.

• For a relayed domain user, the message is stored twice while it waits: once in the mailbox and once in the spool.
• For a relayer, there is only the copy in the spool, because there is no mailbox here.

The retention period is at most 30 days. Mail older than the period is reported as above and moved to Failed.

What this is not

Not	Because
A backup MX	We accept mail only for the addresses that exist here.
A destination for each address	You set the destination, or the collection spool, once per domain. Everything we relay on that domain goes the same way.
A catch-all, elsewhere a default address or default mail	We pass on only the domain users you relay, individually or through the domain policy, and the relayers you create. An address you didn't create here is refused, not forwarded.
Available for every account type	A group, a forwarder, a mailing list, a rejector, or a send-only account can't be relayed: the panel doesn't offer the relay controls on them, and won't create one at a name where you already made a relayer. See Account types.