GMail "multiple destination domains per transaction" problem in exim.conf


Verified User
Mar 28, 2008
I was grepping some old logs earlier to figure out why emails from someone (who'd said they'd emailed multiple times) hadn't come through.

Not solved that one yet (have a feeling they were sending to the wrong address) but I did notice a slightly worrying 430 "multiple destination domains per transaction" error from GMail's servers when we've sent emails to that person and they've been one of several CCed recipients... So, I thought I'd ask the resident guru.

For most servers handling incoming mail this doesn't seem to be as much of an issue (or is just a silent one). However unfortunately GMail seems to take issue, as described by Lee in this Debian Admin blog entry:

If you attempt to send an email to multiple addresses that are handled by google's email servers, but that have multiple domains, only the mail for one of the domains will be accepted.

All the other addresses will receive a temporary rejection message:
451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
451 4.3.0 try again.  random.string

What happens next is up to the logic of the server sending the mail. It'll try sending the messages to the next in the MX priority list - which for google-handled domains are going to be the same. And again, all but one of the delivery domains will get rejected.

I've yet to see a mail bounce as a result of this, but for mails with many different domains I've seen deliveries hit their retry limits and hang around on the mail queue for over an hour. Sub-optimal. A web-search for "Multiple destination domains per transaction is unsupported" will likely locate a few annoyed mail-admins.

Lee goes on to identify the variable
and suggests the change of transport and even provides some sample code for exim's conf. It does seem to need some further additional creation of a list to hold MX records for the "single domain mx" part of his new transport option.

Whilst I can transliterate those instructions to apply to the conf, it might be useful to highlight this potential scenario which seems to occur based on personal preferences whilst setting up exim -- and maybe include this fix, or something similar in the next spamblocker conf?

I'm loathe to just throw this code in without being able to fully appreciate the consequences and dependencies you've already coded into spamblocker conf and the fact it would then have an external dependency to properly detect servers matching the conditions in the transport). I'll gladly put up with the vastly reduced spam and more retries for now. I wonder though, is there anything realistically that can be done to workaround?
A quick overview shows it should work, but you should test it thoroughly.


Whilst I understand why many admins will want to implement a workaround, we have simply advised users that we cannot reliably convey messages to them if they use Google Mail (or other ISPs that use Google to provide their mail services).

This "problem was created simply because Google has identical MX records for all of the domains for which they handle mail, yet won't accept all mail legitimately sent in one SMTP session to those servers - madness! The "problem" would disappear if either they had different MX records for each domain or group of domains between which Google wants to differentiate. Simples!

See this thread:!topic/gmail/PQLLTW1d3DM - Google is simply ignoring the problem that they themselves have created.

As you might expect, our affected members have been slowly migrating away from Gmail because of this... we now have less than half of the original number who were using Gmail accounts.
A half-year later it looks as if multi_domain is going to fix the problem, though documentation appears scarce.

I'd like to consider it for the next version of SpamBlocker. Has anyone tried it? If so what is your experience, and hoiw and where did you use it?