Ask Ubuntu is a question and answer site for Ubuntu users and developers. 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

I have setup an intranet email system using postfix, dovecot and squirrel mail, Which is working fine, I can send and receive mail to all users on the system. I presume that the issue is in the postfix configuration, because when I configure Thunderbird to send mail I am getting the following error:

An error occurred while sending mail. The mail server responded:  4.1.8 <>: Sender address rejected: Domain not found. Please check the message recipient and try again.

Also here is the relevant syslog entries:

NOQUEUE: reject: RCPT from [More Information] [ [More Information] ]: 450 4.1.8 <>: Sender address rejected: Domain not found; from=<> to=<> proto=ESMTP helo=<[ [More Information] ]> 

I have configured MX records on the DNS server and they respond appropriately when I query them for those MX records, so I do not think that is the issue. I think that my issue is caused by the default configuration of:

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination 
smtpd_sender_restrictions = reject_unknown_sender_domain

Since this is on an internal network and it will not be exposed to the internet as a whole which options can I remove safely?

share|improve this question
so I was able to get thunderbird to send emails by removing reject_unknown_sender_domain and reject_unknown_recipient_domain, but is there a way to resolve this issue without doing that? Is it a DNS issue? I do not have forward or reverse records setup for the IPs that are connecting to the mail server, could that be the issue? – Mark S. Nov 7 '13 at 17:03
Still looking for any commentary that can be provided on the issue, anyone?? – Mark S. Dec 3 '13 at 16:01
up vote 2 down vote accepted
smtpd_sender_restrictions = reject_unknown_sender_domain

Don't accept mail from domains that don't exist. (source)


Reject the request when Postfix is not final destination for the recipient domain, and the RCPT TO domain has 1) no DNS A or MX record or 2) a malformed MX record such as a record with a zero-length MX hostname (Postfix version 2.3 and later) (source)

If you need to change both to make it work, will you have to fake the sender domains in your local DNS or add them to the /etc/hosts file on the server. From the explanation, postfix will reject it if it can't look up the domain.

For the second, should you be fine with adding the receiver domain in the servers /etc/hosts file. Explaination: Dovecot use virtual transport, and thus Postfix is, as i have understood it, not considered the final destination and you will need to have proper "path" to the destination. How? Add a DNS A record (to the servers host file) or a proper MX record to your local DNS.

For your question: Yes, you can remove safely, but that will turn off the filters refereed above.

share|improve this answer

You have to add the line:

my_destination =,, localhost

and it will tell postfix that this machine is the responsible for handling e-mails sent to this domain/host.

If this is the only entry/exit point for the internal e-mails you are sending/receiving, it's all you will need. On the other hand, it's always wise to properly set up your DNS servers, adding MX records for your domain and pointing them to your MTA.

It is advisable to keep localhost into the line above so it may handle internal e-mails, sent by other daemons to/from root.

share|improve this answer
@AndersF.U.Kiær, as far as I understood from the question, this is exactly what is missing from the "working configuration" of the OP. No matter if canonical or hosted, postfix has to know about the domain and that it is responsible for it. The way to segregate users and other domains is to use canonical tables, be it virtual or not. But without seeing the actual configuration, it's hard to know what is the OP's intention. ;) – fboaventura Dec 10 '13 at 16:13
Wrong, Postfix do gladly take anything on it's queues, regardless of where it is going to deliver it (over smtp, locally or virtually), unless Postfix is told anything else. Here we explicit tell Postfix to restrict on the header fields on its smptd daemon. – Anders F. U. Kiær Dec 10 '13 at 17:39
Correction, removing my first comment as it was not related. Then for the follow up: Your answer is missleading as it has nothing to do with the error or the question. my_destination is telling what to deliver over local transport and has nothing to do with the header filtering. Also if he is using Dovecot as LDA is virtual_mailbox_domains the equivalent of my_destination (source) – Anders F. U. Kiær Dec 10 '13 at 18:19
@AndersF.U.Kiær, again as far as I understood, OP is using just one domain, internal and not internet valid. Being so, it doesn't matter if virtual_mailbox_domains or my_destination is used, as long as postfix is told to handle mail sent to that domain. If you don't specify it on any of those transport possibilities, but set your MX pointing to the server, you will end up seeing error messages like "status=bounced (mail for domain loops back to myself)". Dovecot will just pick the mail on the mailbox, postfix has to know how to put it there... just one more – fboaventura Dec 11 '13 at 0:22
I do not understand what part of the manual you do not understand.It clearly states that the open relay is done with smtpd_relay_restrictions and the option reject_unauth_destination. It also states if you run with a with a old config or pre 2.10 postfix is it done with smtpd_recipient_restrictions and the same option reject_unauth_destination. We are not discussing the reject_unauth_destination part but reject_unknown_sender_domain and reject_unknown_recipient_domain. So it is no risk of becoming a open relay. Understood? : ) – Anders F. U. Kiær Dec 12 '13 at 10:16

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.