Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I try to send an email on my postfix server to an address on the same domain (for example, if the server hostname is and I try to send an email to, I get the following error in the log and the email is not delivered: Recipient address rejected: User unknown in local recipient table. If I send to an address on another domain, I don't have any problems. Here is my /etc/postfix/ file:

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname =
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
#myorigin = /etc/mailname
myorigin = $mydomain
mydestination = $mydomain, localhost.$mydomain, localhost
relayhost =
#fake IP address
mynetworks = 100.837.191.223
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
share|improve this question
I would like to know what user it thinks it is matching against vs what user you provided it. This error points to what the issue is, User unknown in local recipient table. You just have to figure out the details – aduljr Sep 9 '10 at 6:12

I know this question is a little old, so I'm assuming it's been answered satisfactorily already.

I just had this same issue, and it took me a while to figure out what was going on. I think my situation was the same as the original question.

Postfix should relay all mail to other servers on the internet, it does not actually receive mail for any domains. So any mail sent to should be forwarded to the mail server for The solution, as explained b techieb0y, is to remove $mydomain from the line:

mydestination = $mydomain, localhost.$mydomain, localhost

This line tells postfix that any messages sent to $mydomain are to be received and stored on this server. That's not what I want, I want those messages to be sent to the actual mailserver for Once I realised this, and removed, mail worked as I expected. I'm posting this on the off chance that this explanation helps somebody else who stumbles upon this question in the future.

share|improve this answer
This worked for me. Thanks – David Okwii Mar 17 '14 at 9:53

The error is pretty self-descriptive: the target email username (left of the @ sign) can't be mapped to a local user on the system (default postfix settings), nor to a virtual domain (as none are configured out of the box). The decision to try and perform this mapping is controlled by the list of domains in 'mydestination' (plus any virtual domains). If this machine is in fact a domain's primary MX, then users that don't exist have broken mail. If this box only needs to send outgoing messages, simply removing the target domain from mydestination (by removing $mydomain from the list) should suffice -- it will still accept messages directly for user@hostname.domain.tld, but messages for user@domain.tld will go through the MX lookup process for delivery elsewhere. You can shortcut the process by setting up a transport map (for individual domains), or for configuring a smarthost (for all mail).

share|improve this answer
you saved my day, I was going mad... why do I have two users for myself, tstaerk and thorsten ;) – Thorsten Staerk Nov 22 '14 at 11:48

When you send a message to your local domain, postfix is responsible for checking that the recipient exists. When you send an email to any other domain, postfix has no such responsibility.

You either need to have a local user called test

useradd -s /bin/bash -d /home/test -U test

or, you need an alias from test to a local user in /etc/aliases

echo "test: root" >> /etc/aliases
postalias /etc/aliases

An you should be all set.

share|improve this answer
Is there any way to bypass this check so I don't have to create a user for each person I would send an email to? I don't want to use this server as our primary mail server, just to send outgoing emails from an application when errors occur. I would prefer to not have to update the server every time I want to add a new recipient for the application email. – Tai Squared Sep 9 '10 at 15:47
Let's say you want to send email to '', what you need to do is to make sure your local postfix is NOT responsible of '', otherwise it will try to validate the user locally. So, set the directive 'mydomain' to something different, like 'mydomain = local.server' and postfix will send your email to the server responsible for '' – Julien Vehent Sep 10 '10 at 6:12

So I'm having a similar problem and haven't quite figured it out yet, but this should move you in the right direction:

Look at the "Postfix on a null client" section - I think that's what you want. I also tried setting local_recipient_maps setting as specified on postfix's website at the page: LOCAL_RECIPIENT_README.html

Both links should do what we're after here, but I can't get them to work. When I do the full null client setup, attempting to telnet in order to send a test SMTP email does not work. I get "telnet: connect to address Connection refused". When setting local recipient map, the lookup in the RCPT TO: command does not give an error message like it was before, but upon sending the email (looks normal), no email is actually sent, and there's an error in the maillog:

"550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown"

Let me know if you have better luck.

share|improve this answer

A) In Mailserver / SMTP / Hostname (FQDN): change the setting to: SmartHost.local and eliminate anything listed in Additional Domain.

If you do have any domains listed in either location, mail for those domains will NOT be sent out to the Internet. Instead, Mail Server (actually Postfix) will look to see if there is a LOCAL USER - admin, your login user name, your IT person's user name, your Service Account for backups, service account for File Shares, etc. - with the same User name as the inbound email. If so, Postfix holds the mail for a mail client to access. (Or in some configurations delivers the mail.)

But if what you want is for EVERYTHING to be sent out to the Internet, you have to make sure the above fields do NOT match up with any valid domain anywhere to which you might ever ever ever send mail. Because if there's a match Mail Server will either deliver it locally - if it can find a User name match - or bounce it because it has been told to deliver to a local domain (all domains listed in those two fields are defined as local domains to this mail server) and the user name doesn't exist locally.

B) From your printer, refrigerator, servers and so on - all of which are trying to send out alerts - point their local MTA settings at NAS-NAME (or if you have a FQDN, at NAS-NAME.domain.tld - and feel free to use Port 25 as you're in your internal network. (If indeed you are. If you're in a DMZ, what the Frack are you doing there; this is a NAS at heart, not a mail server. Don't put this anywhere except on an internal network with at least one good firewall between it and the Internet.)

Also make sure you've checked the box (above) which says: Ignore authorization for LAN connections. That essentially sets up this mail server as an open relay inside your network, which means every printer, refrigerator, scale, server, and every other damn thing you have will be able to send outbound alerts and messages without needing to authorize, which a solid 50% or more can't do anyway because their coders sucked.

C) When you think you have the SmartHost configured correctly, drop to Terminal (the command line) and do a SMTP test using Telnet. If you do in fact receive your mail, tada! Now just test with your dumb device (printer etc) to make sure you're good. If it doesn't work, troubleshoot.

Good luck.

share|improve this answer
You give no actual instructions, all you do is to write a largely unreadable wall of text, while the actual answer has been written 3 years ago in two paragraphs and a line of code. – Sven May 30 '15 at 8:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.