Set Up Postfix Local Aliases Without Losing the Original Mail

A local Postfix alias redirects a system address like root or support to a real mailbox. This guide gets one working, then proves the indexed database actually picked up your change. It uses the aliases(5) format supplied by Postfix 3.8.6, installed here as Ubuntu package 3.8.6-1ubuntu0.1.

Allow about ten minutes. You need shell access, an editor, and permission to change /etc/aliases and rebuild its database. Reading the existing file and querying it are ordinary operations. Editing the system file and running newaliases normally need sudo.

1. Confirm which alias file Postfix uses

Never assume every Postfix installation uses /etc/aliases. Check the active settings first:

$ postconf -h alias_database alias_maps
hash:/etc/aliases
hash:/etc/aliases

On this installation, alias_database names the database rebuilt by newaliases, and alias_maps names the database queried by the local delivery agent. Output naming another file or map type? Stop and adapt the later commands to that configuration instead. Do not edit /etc/aliases just because it is the conventional path.

Checkpoint: record the exact path and map type from your output. The examples below assume both settings are hash:/etc/aliases.

2. Read the current aliases before editing

Make a dated backup first, then have a look at the file:

$ sudo cp -p /etc/aliases /etc/aliases.before-local-alias-$(date +%Y%m%d%H%M%S)
$ sudo sed -n '1,160p' /etc/aliases

Recovery: that backup is your way back. Keep it until a test message has actually reached its intended destination. Need to undo the change? Copy the chosen backup back to /etc/aliases and run sudo newaliases again.

Alias input runs on a small grammar. A definition is name: value1, value2. Blank lines and lines whose first non-whitespace character is # get ignored. A line starting with whitespace continues the previous logical line, so a stray indent can silently join two lines you meant to keep apart.

3. Add one local forwarding alias

Open the file as root and add an entry: a local name on the left, one or more destinations on the right:

$ sudoedit /etc/aliases

For example, replace REAL_USER with the local account that should receive the mail:

support: REAL_USER

For several destinations, separate them with commas:

ops: REAL_USER, [email protected]

The name is local, not a full domain address. Lookups fold it to lowercase, so Support and support land on the same alias. If a name has whitespace or special characters such as #, : or @, quote it. Stick to a simple local name unless you have a genuine reason not to.

Save the file, then check the exact entry landed before you rebuild anything:

$ grep -n '^support:' /etc/aliases
13:support: REAL_USER

Nothing printed? Your name or spacing does not match the example. More than one definition printed? Resolve the duplicate deliberately, do not just let whichever one wins by accident stand.

4. Rebuild the indexed database

The text file is input, not the fast lookup database Postfix actually reads. Rebuild it after every single edit:

$ sudo newaliases

A successful run normally prints nothing at all and returns status 0. Check that status straight away:

$ printf '%s\n' "$?"
0

This command only changes the generated database beside the configured aliases file. It does not send mail and it does not restart Postfix. Syntax or permission error? Fix the text file and run the command again. Never hand-edit the generated database itself.

Checkpoint: both the source line and the rebuilt database must now exist. A changed /etc/aliases with no successful newaliases run afterwards is not a completed configuration, it is half a job.

5. Query the alias before sending a message

Use postalias -q against the configured map to check the expansion without ever delivering mail:

$ postalias -q support /etc/aliases
REAL_USER

With the real account substituted, the output should be the destination you entered. The command returns status 0 for a found result. A missing name gets no output and a non-zero status instead:

$ postalias -q missing-alias /etc/aliases
$ printf '%s\n' "$?"
1

Query the lower-case spelling even if you typed the alias with capitals: the local delivery lookup is case-insensitive for the name. This check only examines the alias database. It proves nothing about whether the destination account exists, whether remote DNS works, or whether a message will clear later delivery policy.

6. Test delivery and understand special destinations

Send one test message through your normal mail submission path, then check the destination mailbox and the Postfix log. Keep the test address local if you are validating a production machine, and do not touch a real mailing list until the expansion has been verified.

Address extensions can be handy when recipient_delimiter is configured. With the delimiter set to +, a lookup for support+ticket can fall back to support when the extended address is not present. Check the local value instead of assuming:

$ postconf -h recipient_delimiter
+

The exact extension behaviour also depends on the relevant map and the propagate_unmatched_extensions setting. Treat it as a separate thing to test, not a reason to bolt on multiple near-duplicate aliases.

Security boundary: an alias destination can also be a remote address, a file path starting with /, a pipe starting with |, or an :include: file. File and command delivery are disabled by default in the installed settings shown here, and turning either on widens the security and maintenance boundary considerably. A command runs as part of mail delivery, while a file destination can expose message contents or chew through disk space. Do not switch either on for a quick experiment. Use a normal mailbox destination first.

7. Use owner aliases only for list-style workflows

For an alias named project, a companion owner-project alias can redirect delivery diagnostics to the list maintainer. Postfix can also use that companion alias to set the envelope sender when expand_owner_alias is enabled. The installed default for that setting is no; owner_request_special defaults to yes.

These names carry operational meaning, so do not create an owner- entry just because it looks like a tidy naming convention. Routing one system address to one mailbox? A plain alias is easier to audit and far less likely to alter bounce handling when you were not looking.

Done means