Module 3 · 3.3

English

Nederlands English Deutsch Français Español Italiano

Aliases, forwarding and catch-all: handy, but risky

Module 3: Managing your mailbox · Reading time: 11 minutes

Learning objective: After this lesson, you can choose between a mailbox, an alias, a forwarder and a catch-all, and explain why forwarding to an external address and using a catch-all can harm your mail deliverability.

Key concepts: mailbox, alias, forwarder, internal and external forwarding, SPF breaks on forwarding, SRS (Sender Rewriting Scheme), DKIM when forwarding, ARC (RFC 8617), catch-all, dictionary attack, backscatter, sending on behalf of another address

Four ways to make an address work

If you want offerte@example.com to work, you have four options:

Option	What it is	When it's useful
Mailbox	Your own storage space with its own password. You can log in to it.	Someone needs to work with it directly, or the mail needs to be kept separately.
Alias	A second name for an existing mailbox. Mail to `offerte@` arrives in the mailbox of `info@`.	One person with multiple addresses.
Forwarder	Mail to the address is forwarded to one or more other addresses. Nothing is stored.	An address that needs to reach several colleagues; an old address that needs to keep working.
Catch-all	All mail to addresses that don't exist arrives at one address.	Almost never (see below).

In some control panels, an alias is technically the same as a forwarder to an address on the same server. The difference that matters is this: does the mail stay on the same server, or does it leave it?

Forwarding within your own domain: no problem

If you forward offerte@example.com to info@example.com, and both are on the same server, the server simply delivers the mail to the mailbox of info@. Nothing goes over the internet, and nothing is checked again. That's safe and reliable.

Forwarding outside: where it goes wrong

It's different when you forward to an address at another provider, for example a personal address at Gmail or Outlook.com. Then your server sends the mail again, now to Gmail. And Gmail checks the mail as if it came from your server.

Say klant@example.net sends a mail to info@example.com. Your server forwards it to Gmail. What does Gmail see?

Sender (From): klant@example.net.
Envelope sender: still klant@example.net, unless your server rewrites it.
Sending server: your server, for example 192.0.2.25.

Gmail checks the SPF record of example.net. Your server is, of course, not listed there. SPF fails. If example.net has a DMARC policy of p=reject, and the mail doesn't have a valid DKIM signature, Gmail rejects the mail. Your server gets a bounce back, and that goes to... the original sender, who now receives an error message from your server.

There are three mechanisms that soften this:

1. DKIM usually survives

A DKIM signature (lesson 4.3) sits in the mail itself. If your server forwards the mail unchanged, the signature from example.net is still valid. DMARC then passes on DKIM, even though SPF fails. That's why DKIM is so important: it's the only thing that survives forwarding.

But it goes wrong if the forwarding server changes the mail: adding text at the bottom ("forwarded by..."), changing the subject (adding [SPAM] in front), or converting the formatting. Then the signature no longer matches.

2. SRS rewrites the envelope sender

With SRS (Sender Rewriting Scheme), the forwarding server changes the envelope sender to an address on its own domain, for example:

SRS0=HHH=TT=example.net=klant@example.com

Now Gmail checks the SPF record of example.com, and your server is listed there. SPF passes. If a bounce comes back, your server can translate the address back and send the bounce to the real sender.

Note: SRS fixes SPF, but not DMARC. Alignment (lesson 4.4) compares the domain of the envelope sender with the From address. That's now example.com versus example.net: not aligned. So DMARC still needs to pass on DKIM.

3. ARC: a statement from the intermediary

ARC (Authenticated Received Chain, RFC 8617, experimental) lets an intermediary record what it saw: "when this mail arrived at me, SPF, DKIM and DMARC passed". The forwarding server signs that statement. The final recipient can decide to trust that statement if it trusts the intermediary. Large recipients such as Gmail and Microsoft use ARC, but you can't rely on it: it's a favour, not a right.

And the spam?

There's another problem, and it's often the biggest one. Your spam filter doesn't stop everything. All the spam that gets through is now forwarded by your server to Gmail. To Gmail, it looks as if your server is sending spam. That damages the reputation of your server (and on shared hosting: that of every customer on that server). Gmail then also puts your genuine mail into spam more readily.

What's better?

Want to read your business mail in the Gmail or Outlook app? Add the mailbox as an IMAP account (module 2). The app retrieves the mail directly from your server. Nothing is forwarded, nothing fails, and no spam goes out. If you do need to forward, set the spam filter to strict before the forwarding step.

Catch-all: why almost never

A catch-all catches all mail to addresses that don't exist. A typo like inof@example.com then still arrives. That sounds handy, but:

Spam. Spammers send mail in bulk to made-up addresses on existing domains (a.jansen@, sales2@, xkq7@). This is called a dictionary attack. Without a catch-all, your server rejects all of it immediately. With a catch-all, all of it comes in, often hundreds per day.
No more error message. Anyone who makes a mistake in your address gets no bounce and thinks their mail arrived. Without a catch-all, they know straight away that the address is wrong.
Forwarding makes it worse. A catch-all that forwards to Gmail sends all that spam on to Gmail.
Backscatter. A server that first accepts everything and only later discovers that an address doesn't exist sends a bounce to the (spoofed) sender. This is called backscatter: error messages to innocent people, and a reason to end up on a blocklist.

Want to catch a few extra addresses, such as a common typo or an old address? Set up separate aliases or forwarders for those. Do you use a separate address per website or webshop (webshop-x@), to see who's reselling your address? Create that address as an alias at the moment you start using it.

Sending from an alias

An alias can also be a sender. For example, you may want to reply as offerte@example.com while logged in as info@. That's possible, but:

Many mail servers nowadays check which sender address belongs to which login. You're then only allowed to send from your own address and the aliases or forwarders that point to your mailbox. Any other address is rejected ("account can not send emails from ..."). That protects against misuse.
In your mail program, add the alias as an extra identity (Thunderbird: Manage Identities; Apple Mail: extra addresses on the account, separated by commas; Outlook: show the From field and type the address).
SPF, DKIM and DMARC work normally, as long as the alias is on the same domain and you send via your own server.

In practice: what it looks like in a control panel

In DirectAdmin, you create forwarders under E-mail Manager, Forwarders. The catch-all is under Advanced Features, Catch-All E-mail; there, "disable catch-all" is the recommended setting (mail to non-existent addresses is rejected). If you only have a domain name without a hosting package, forwarders are in My WebOké under My Domains, Forwarders. Other panels (cPanel, Plesk, Microsoft 365, Google Workspace) have similar sections, sometimes under names such as "aliases", "forwarding" or "groups".

Summary

An alias or forwarder within the same server is safe.
Forwarding outside breaks SPF. SRS restores SPF, but not DMARC alignment; only an intact DKIM signature saves the mail, and ARC can help.
Forwarded spam harms your server's reputation. Better to read external mail via IMAP in the app.
A catch-all attracts spam, hides typos and can cause backscatter. Use separate aliases instead.
Sending from an alias is possible, within your server's rules.

Quiz

Exercise

Exercise O3.3: Taking stock of your addresses. Make a list of all the addresses on your domain: mailboxes, aliases, forwarders, and whether a catch-all is switched on. For each forwarder, note whether it stays within your own domain or goes outside it (Gmail, Outlook.com, another company). Then answer: which external forwarder could you replace with an IMAP account in the app, and is there a catch-all switched on that could be turned off? Fill in the checklist.

Exercise O3.3: Taking stock of your addresses

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

No catch-all, or a deliberate reason noted down.
Every external forwarding has a reason, or has been replaced by IMAP in the app.
The spam filter is switched on before any external forwarding.
Addresses I send from (aliases) are set up as identities in my program.

Which addresses do you have (mailbox, alias, forwarding, catch-all) and where do they go?

Which external forwarding will you replace with an IMAP account in the app? Is a catch-all switched on, and can it be switched off?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing