How do I block an SMTP connection when I determine the sender's MX record will reject mail?

That is, if the advertised (MX record) way to send mail back to the domain will in fact not work, I want to reject the incoming SMTP connection.

I'm administrating a mail service for a small business. They have a mail host, foo.example.org, whose internet connection is an ADSL service with a permanent IP address.

Unfortunately, many mail systems are misconfigured in the following way:

  • the sending host, bar.example.com, will happily deliver to foo.example.org, and
  • the DNS for bar.example.com has an MX record listing the host (mail.example.com) to which mail should be directed for that domain; but
  • the specified host mail.example.com rejects SMTP connections from foo.example.org.

So the declared sender's domain has an MX which refuses to receive connections from this host. That misconfiguration makes their system a one-way mail sender, which is a problem.

Note that I'm not, as some commenters have assumed, talking about hosts which only send mail; that's not the problem. The misconfiguration is in that domain's mail system, declaring a sender domain for the message when that domain's MX won't accept SMTP connections from the domain to which you're sending.

I have also confirmed the DNS configuration is correct (with A and PTR records that map correctly both ways) and confirmed the host's IP address is not blacklisted in many of the reputable blacklist services, with helpful links from JohnnyD.

Those mail systems that are rejecting this host seem to be doing so primarily because it's on an ADSL service, regardless of the fact that it has a permanently-assigned IP address and is not listed in reputable lists of dynamic IP addresses (because it's a permanently-assigned address).

How can I configure Postfix on this customer's mail host to refuse SMTP sessions that declare a sender domain which itself refuses SMTP from this host? That is, if the SMTP client declares a domain that we can't make SMTP connections back to, then there's not much point accepting the incoming connection in the first place.

I'm imagining a late check (after the low-cost checks to winnow most of the rubbish connections) that keeps the client on the other end while it attempts an SMTP client connection back to the declared domain of the sender. If that connection is rejected, the incoming one is also rejected.

Yes, that means some mail might be blocked. But that's better than accepting the message, and then not having a way to reply or tell the sender there's a problem at their end. By blocking the message at SMTP time, the sender will at least receive prompt notification, which isn't the case now.

I'm also open to other suggestions for how this problem might be addressed (short of not using this mail host, which isn't an option).

  • 1
    Just something to consider - One of our web sites is an on-line store, so it sends a fair number of emails (order confirmations and the like). However, that system will not receive emails. If our customers implemented what you are proposing the whole system would be worthless. Jun 9 '10 at 3:51
  • I fail to see how you have come to the conclusion that the "other" mail server is misconfigured because it won't accept email from your server. Many entities use different servers for sending and receiving email. My worry is that your lack of understanding of the nuances of email transport may cause undesired results, like users not receiving emails.
    – joeqwerty
    Jun 9 '10 at 4:53
  • So basically, the next time I fat finger my mail server and accidentally break inbound mail, you'll compound the situation by rejecting my outgoing mail too? Jul 2 '10 at 1:17
  • While it is totally bogus to reject an entire range of IP addresses based on the fact that they are ADSL, it is equally bogus to reject an entire class of senders who reject you. Two wrongs and all that... Jul 2 '10 at 1:21

I would start by doing a thourgh check of all composite blocking lists:


Barracuda Central

Anti-Abuse Project - enter IP in Multi-RBL Check textbox on right


Let me know how you make out.

  • 1
    The address is no doubt listed as “belongs to a range of addresses assigned to ADSL service”. While true, these lists appear to be misused as “nobody should ever be making SMTP connections from these addresses”, which is an abuse of the list; the address is permanently assigned to this service and is valid for use. So, the problem is the misconfiguration of the remote server blocking this address, not the list itself.
    – bignose
    Jun 9 '10 at 22:08
  • 2
    Unfortunately, yes, it is a valid reason, sorry. You may request that this pool of addresses be removed from the list of dynamic addresses, you should work in cooperation with your ISP.
    – silk
    Jun 10 '10 at 20:32
  • Thanks for the links, JohnnyD. The mail host's address gets a clear report from all of those services, so we can be confident it's not listed in a reputable blacklist.
    – bignose
    Jun 11 '10 at 2:52
  • A very thorough blacklist-checking service (147 blacklists, ATM) is at mxtoolbox.com/blacklists.aspx.
    – user70549
    Mar 11 '11 at 6:06

What do you suppose is the most parsimonious explanation:

  • "Many" mail systems are misconfigured because they won't accept mail from you.
  • "Many" mail systems won't accept mail from you because your system is misconfigured.

I'm leaning toward the second option. Even if it were the first, it's still bad form to punish the other networks for daring to not accept mail from you. Wouldn't it be more productive to find out the root of the problem?

I suspect that one or both of the following are true:

  • Your DNS settings are screwed up. Let's say your SMTP server is mail.example.com. You need to make sure that your DNS servers have an A record mapping to mail.example.com, that mail.example.com is listed as an MX server for example.com, and (this is the big one) your ISP's DNS servers have an rDNS record mapping your public IP address back to mail.example.com. As a spam countermeasure, many mail servers won't accept inbound connections from IP addresses that fail these DNS tests.
  • There is a spam-spewing bot on the LAN, so your IP address has been blacklisted.
  • The explicit reason given, in a majority of these cases, is “your host is on an ADSL connection”. That's true, but seems to imply that the address is dynamic, which is false. To block merely because the client is assigned to an ADSL range is a misconfiguration.
    – bignose
    Jun 9 '10 at 22:04
  • 1
    "To block merely because the client is assigned to an ADSL range is a misconfiguration." No, this is a feature of a particular anti-spam technique. They aren't making assumptions about DHCP, they are making (rational) assumptions about consumer-grade circuits (from which they see a lot of spam). All that the recipients want is for you to configure DNS settings that you ought to have configured anyway. Why wouldn't you want your rDNS entry to be correct?
    – dbc lab
    Jun 11 '10 at 6:11
  • Where have you got the impression that the DNS entries are incorrect? They're not; PTR and A records are present and correct. Also, the recipients have made plain that their reason for rejection is not poorly-configured DNS settings, but rather that ADSL is the criterion on which they're rejecting.
    – bignose
    Jun 13 '10 at 5:07
  • "Where have you got the impression that the DNS entries are incorrect?" The fact that you specifically mention A and PTR records, but you ignore rDNS, is a good indication you've messed up there.
    – dbc lab
    Jun 13 '10 at 15:42
  • One of us is very confused. I answered your questions about rDNS. Do you think rDNS uses something other than PTR records?
    – bignose
    Jun 14 '10 at 7:23

Doing what you propose here will likely eventually result in you no longer receiving email from the biggest and most widely used domains in the world (gmail, hotmail, yahoo, etc.).

I'm also open to other suggestions for how this problem might be addressed (short of not using this mail host at all, which isn't an option).

The first thing I'd try is to make sure the PTR record for your IP matches your domain, and does not resolve to something like "user1235.big-isp-adsl-for-the-masses.com".

But ultimately, and I know this answer sucks, I think the only thing you are going to be able to do to properly send to those domains that currently reject you is to get a new IP address for your mail host. I know, it isn't fair. And I strongly urge you to fight the good fight. But when you get tired of your mail getting lost sporadically, then I think you'll decide that getting a new IP is what you've gotta do (or bite the bullet and move to a different server/host that works).

  • Thanks. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end.
    – bignose
    Jul 2 '10 at 12:26

You could use ppolicy to add new policies. You will probably need to write your own module, but it should be do-able



Check http://www.spamhaus.org/pbl/ list.

If it is there, and it is a static address, you will be able to remove it.

  • That is one of the black lists included in the aggregate checks suggested in JohnnyD's answer. The address is not currently listed at that service.
    – bignose
    Jun 13 '10 at 2:21

Spamhaus and/or greylisting will drop most of the problem addresses. Requiring FQDN in the helo/ehlo messages will catch a lot of the rest.

Dropping messages from servers which don't accept messages won't work if they also do the same. There are a number of legitimate senders who don't accept bounce messages after the fact.

Bounce the message during the connection not afterwards or you will contribute to SPAM through backscatter.

DNS and rDNS need to agree for your server. If your address is listed as dynamic at Spamhaus, you will be refused by a large number of servers, mine included.

  • Senders don't themselves have to accept mail, but they do need to have an MX record. If the sender's MX host refuses mail, I don't want to accept the incoming connection from the sender in the first place.
    – bignose
    May 8 '11 at 1:53
  • @bignose: There are a number of legitmate mailing list and autmated senders who do NOT accept e-mail in any form either at the address or their MX. This is bad form, but gets rid of all the spam they are likely to get. If you don't mind dropping these mail sources, you can drop senders you can't reply to. Howver, callouts to some of the big freemail senders can get your reputation with them downgraded (again bad form).
    – BillThor
    May 8 '11 at 18:28
  • “If you don't mind dropping these mail sources, you can drop senders you can't reply to.” Yes, that's exactly what this question is asking. If you know how to do that, please write an answer!
    – bignose
    May 12 '11 at 3:26
  • @bignose Exim provides a verify_sender condition for ACLs. I limit it to sroute checking, as checking senders drops legitimate mail my user want. There are options to check for a valid postmaster or random userids. See exim.org/exim-html-current/doc/html/spec_html/… for details.
    – BillThor
    May 12 '11 at 13:41

Can you set up your mailserver to pass all outbound mail to an upstream host (at the ISP, or a separate paid service) that's not blacklisted?

Does your customer know you're proposing/working on an approach that's going to result in them not getting inbound E-mail from their customers? I think the "bounce mail from people who discriminate against ADSL SMTP senders" policy is going to cause confusion for your customer (who will get phone calls asking about the bounces) and ultimately make their system(s) less useful, which is hard to justify.

  • Thanks. Currently, senders succeed in getting a message delivered, but then there's no way to reply back. By blocking the messages at SMTP time, with an explanatory message, the sender will at least know that the problem is at their mail transport provider's end. That will be an improvement over the current situation.
    – bignose
    Jul 2 '10 at 12:27

i am VERY recommend you to find freshest instruction for antispam or your mail server became spam-botted within 2 days.

and "refusing SMTP sessions that declare a sender domain which itself refuses SMTP" is not enough!

it`s from my own experience :( (but for another mailer)

  • Thanks, but this doesn't address what I've written. The mail server is existing for a while, and has adequate protection against unsolicited junk. I'm talking about adding a new restriction onto an existing mail server.
    – bignose
    Jun 9 '10 at 6:13

It dawned on me. You keep mentioning MX records, but those are not what you're looking for. The DNS feature you want to leverage is the TXT record with the SPF line.


This allows you to whitelist IPs that are allowed to send mail for that domain. But be careful, you can easily cut yourself off if you fail to whitelist your ISP's SMTP relay or if it changes.

And after knowing the name of what we want, finding articles is easy:


  • Yes, MX records – the incoming domain's advertised way for that domain to receive mail – are what I'm looking for (and I've now clarified this in the question, thank you). SPF addresses an entirely different problem, so this answer doesn't apply.
    – bignose
    Apr 10 '19 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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