Take the 2-minute tour ×

I use Postfix to send messages to a mail server outside my organization which frequently rejects/defers my mail. My Postfix server sees that these messages are deferred and tries again, eventually getting through. Final delivery can take up to an hour, which makes my users unhappy. In comparison, mail from my Postfix server to other hosts works normally.

I have now found out about a second, unofficial MX for this domain that does not reject/defer mail. This second MX does not appear when doing a DNS MX query for the domain. Therefore, for the problem domain I would like to use this second MX as a fallback. That is: whenever mail is deferred by the primary MX, try again on the unofficial second MX.

I see that there is already a postfix configuration "smtp_fallback_relay". However the documentation seems to indicate that I can not restrict usage of the fallback to a single domain. The documentation also doesn't mention deferred message handling.

So is there a way to configure a single-domain, deferred-retry fallback host in Postfix?

For reference, I am including my postconf output (the host names and ip addresses are fake):

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, hash:/etc/postfix/legacy_mailman, ldap:/etc/postfix/ldap-aliases.cf
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
default_destination_concurrency_limit = 2
inet_interfaces = all
inet_protocols = all
local_destination_concurrency_limit = 2
local_recipient_maps = $alias_maps
mailbox_size_limit = 0
mydestination = myhost.my.network, localhost.my.network, localhost, my.network
myhostname = myhost.my.network
mynetworks =, [::ffff:]/104, [::1]/128,
myorigin = my.network
readme_directory = no
recipient_delimiter = +
relay_domains = $mydestination
relayhost = 
smtp_fallback_relay = the.problem.host
smtp_header_checks = 
smtpd_banner = $myhostname ESMTP $mail_name
virtual_alias_maps = hash:/etc/postfix/virtual
share|improve this question
Please edit your post with the output of postconf -n, or nobody will read it. –  adaptr Nov 28 '12 at 14:31
Thanks; I shortened postconf –  EdwardTeach Nov 28 '12 at 16:57

2 Answers 2

up vote 2 down vote accepted

smtp_fallback_relay does not handle deferred messages; it will be tried immediately when the primary destination is unavailable.
This is normally what you want - as the setting indicates, it is a fallback for relaying mail.

I suggest you investigate WHY this mail server rejects your messages.

That said, there are several ways to approach this.
The first - and easiest - solution would be to fake this MX locally so postfix includes it during normal delivery.
To achieve this, set smtp_host_lookup to native; this will consult your /etc/hosts file as well as DNS (via the native system resolver, or, more specifically, via whatever is configured in nsswitch.conf.)

You could also install something like dnsmasq to allow you to override or add specific DNS entries to existing domains; if both relays have MX records this is the only DNS-based solution, since /etc/hosts only supports A records.

The postfix solution involves some lookup trickery, which is only possible when using SQL maps:

You have to add a transport_maps entry consisting of a lookup that can return an alternative result based on out-of-band manipulation; for instance, a periodic check for MX availability (via cron or the like) could replace a regex lookup table that alters the nexthop for this specific domain; postfix will pick up changes to these tables immediately.

share|improve this answer
As to why: rumor has it that the deferrals are due to greylisting. I have no control over the problem mail server, so I can't know for sure. –  EdwardTeach Nov 28 '12 at 17:04
For the dnsmasq solution, are the MXs tried in order immediately, or is there a delay before retrying? –  EdwardTeach Nov 28 '12 at 17:06
dnsmasq plus resolv.conf worked great for me. I'll post more details in another answer. Thanks! –  EdwardTeach Nov 29 '12 at 18:07

So here was the configuration I used on Ubuntu Lucid:

  • apt-get install dnsmaq
  • in /etc/dnsmasq.d, add file problem_domain_mx_override.conf:

    • back door has a lower value and will thus be tried first, but will fall back to standard mx if the back door ever disappears
  • /etc/init.d/dnsmasq restart
  • in /etc/resolv.conf:

    search my.domain
    nameserver # "normal" name servers
  • /etc/init.d/postfix restart
    • it seems a postfix reload is insufficient to accept the DNS trickery
share|improve this answer

Your Answer


