Fix Postfix “status=bounced (unknown user)” When Sending Mail to Your Own Domain

Mail to your own domain bounces with status=bounced (unknown user), even though the address looks valid. The underlying log line is a NOQUEUE: reject ... User unknown in local recipient table at SMTP time. This DevAnswers fix guide reads that log entry, then walks three fix paths: the domain belongs elsewhere, the user needs an alias, or the domain forwards. Verified on Ubuntu 22.04 / 24.04 / 26.04 and Debian 12 / 13 with stock Postfix 3.x.

What This Bounce Actually Means #

Postfix prints status=bounced (unknown user) in the mail log when two things are true at the same time:

• The recipient domain (the part after the @) is listed in the mydestination parameter of /etc/postfix/main.cf, so Postfix considers the domain to be served locally on this machine.
• The recipient username (the part before the @) is not found in the lookup tables that local_recipient_maps points at (by default, /etc/passwd via proxy:unix:passwd.byname plus /etc/aliases).

Postfix rejects the message at the SMTP server stage before it enters the queue. Per the Postfix Local Recipient README, this is intentional: “with the default Postfix configuration, the smtpd(8) server rejects mail for unknown local recipients with ‘User unknown in local recipient table’.” The benefit is no backscatter spam and no MAILER-DAEMON messages clogging the queue.

This is the same root cause whether you saw the bounce in a delivery notification, in journalctl -u postfix, or via a remote sender getting a 550 reply. It is a separate bounce class from the 5.7.26 SPF/DKIM bounce when sending to Gmail, which is about outbound sender authentication, not local recipient lookup.

Diagnose: Read the Bounce Log Entry #

Postfix logs go to two possible places depending on your distro:

• Ubuntu 24.04+ and Debian 12+ use systemd-journald by default. Tail with sudo journalctl -u postfix -f (or omit -f to read past lines).
• Ubuntu 22.04 and any system with rsyslog installed also write to /var/log/mail.log. Tail with sudo tail -f /var/log/mail.log.

Find the log line containing the bounced address. The line you want looks like this:

May 18 09:14:22 mail postfix/smtpd[12345]: NOQUEUE: reject: RCPT from external.example.com[203.0.113.42]: 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in local recipient table; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<external.example.com>

The key phrase is User unknown in local recipient table. Note the recipient domain (here, example.com) and the username (here, missing); both matter for the fix.

Confirm the recipient domain is listed in mydestination:

sudo postconf mydestination

If the bounced domain appears in the output, you have confirmed the local-recipient-table rejection path. Also check what local_recipient_maps is pointing at:

sudo postconf local_recipient_maps

The Debian/Ubuntu default is local_recipient_maps = proxy:unix:passwd.byname $alias_maps: Postfix accepts mail for any system user plus anyone listed in /etc/aliases.

Decide Which Fix You Need #

What you do about the bounce depends on what the recipient domain is supposed to do on this mail server. Three common scenarios cover almost every reader who lands on this error:

Per the Postfix Virtual README, a domain that is in virtual_alias_domains must not also appear in mydestination; the two are mutually exclusive. Fix A and Fix C both remove the domain from mydestination; Fix B keeps it there and changes the lookup tables instead.

Fix A: Remove the Domain from mydestination #

Edit /etc/postfix/main.cf and look at the mydestination line. The default on a fresh Ubuntu/Debian install includes the machine’s own hostname, localhost variants, and (after manual edits) any extra domains the operator added:

mydestination = $myhostname, mail.example.com, example.com, localhost.localdomain, localhost

Save and exit (press CTRL + X, press Y, then press ENTER)

Open the file in your editor:

sudo nano /etc/postfix/main.cf

Find the mydestination line and delete the domain that should not be served locally (in our example, example.com). Keep the other entries exactly as they were:

mydestination = $myhostname, mail.example.com, localhost.localdomain, localhost

Save and exit (press CTRL + X, press Y, then press ENTER)

Save and exit (in nano, that is Ctrl+O then Ctrl+X). Reload Postfix so the new main.cf takes effect. postfix reload is the right command for parameter changes; the master process re-reads the configuration without dropping in-flight deliveries:

sudo postfix reload

Fix B: Add an Alias for the Missing User #

When the domain genuinely is local but the username does not exist as a system account, add an alias to /etc/aliases that maps the missing name to an existing destination. Edit the file:

sudo nano /etc/aliases

Add the mapping. The left side is the missing username; the right side can be another system user, an external email address, or a comma-separated list of both:

info: admin
support: admin, [email protected]
billing: [email protected]

Save and exit (press CTRL + X, press Y, then press ENTER)

After editing, rebuild the alias database so Postfix can read it, then reload:

sudo newaliases
sudo postfix reload

Fix C: Forward-Only Domain via virtual_alias_domains #

The most common multi-domain mail-server pattern: one machine receives mail for several domains, but each address simply forwards to an inbox somewhere else. There are no real mailboxes on the server for those domains. The Postfix-correct way to set this up is virtual_alias_domains plus virtual_alias_maps, not mydestination.

First, remove the forwarding-only domain from mydestination and add it to virtual_alias_domains, then point virtual_alias_maps at a file you can edit. Open main.cf:

sudo nano /etc/postfix/main.cf

Locate the mydestination line and remove the forwarding-only domain (in our example, example.com). Then add or update virtual_alias_domains and virtual_alias_maps. The relevant lines should end up looking like this (substitute your actual domain in virtual_alias_domains):

mydestination = $myhostname, mail.example.com, localhost.localdomain, localhost
virtual_alias_domains = example.com
virtual_alias_maps = hash:/etc/postfix/virtual

Save and exit (press CTRL + X, press Y, then press ENTER)

Save and exit. If you host more than one forwarding-only domain, list them comma-separated under virtual_alias_domains (e.g. example.com, anotherdomain.net).

Create or edit /etc/postfix/virtual with one line per forwarded address. The left side is the address as it arrives; the right side is where to forward:

[email protected]             [email protected]
[email protected]            [email protected]
[email protected]          [email protected]
@anotherdomain.net           [email protected]

Save and exit (press CTRL + X, press Y, then press ENTER)

The first three lines forward specific addresses at example.com (including the [email protected] that was bouncing in our running example). The last line is a catch-all: any address at anotherdomain.net forwards to [email protected]. Rebuild the hash map and reload Postfix:

sudo postmap /etc/postfix/virtual
sudo postfix reload

Verify the Fix #

Open a second terminal on the Postfix server and start tailing the log (use the journalctl form on Ubuntu 24.04+ / Debian 12+; use the tail form if your system has rsyslog installed and writes /var/log/mail.log):

sudo journalctl -u postfix -f

Then, in the first terminal (still on the Postfix server itself, so the message is handed to local Postfix rather than your workstation’s MTA), submit a test message. Replace [email protected] with the address that was previously bouncing:

echo "Test after the fix" | /usr/sbin/sendmail [email protected]

A clean fix produces a status=sent entry (instead of the previous NOQUEUE: reject line). For Fix C, the same log line also shows orig_to=<[email protected]>, confirming Postfix expanded the virtual alias to the forwarding target.

For Fix B specifically, the destination user receives the alias-routed message in their local mailbox; see our companion guide on reading local mail on Linux if you are checking the alias landed correctly.

Next Steps #

If your Postfix server still struggles with deliverability to mainstream providers after this fix, the practical alternative is to route outbound mail through a hosted SMTP service rather than try to maintain your own sender reputation. Our guide on configuring Postfix to relay through an external SMTP server covers the Mailgun and SendGrid setup paths.

For PHP application mail running through this same Postfix install, see the companion guide on configuring PHP’s mail() function to use local Postfix. If your bounce is actually the 550-5.7.26 SPF/DKIM authentication error from Gmail (which is a separate root cause from the local-recipient bounce covered here), the fix is in fixing the 550-5.7.26 Gmail SPF/DKIM bounce.