Fighting Spam: Block entire (T)TLD with Postfix

A Top-Level Domain (TLD) is at the highest level of the Domain Name System (DNS) structure. The domain .com is a TLD. So is .org, .net, and .biz.

I’ve presented on DNS (and BIND) – you can click the link to view my PDF slides (and you can view a listing of all of my posted workshops at https://developcents.com/knowledge-base/#workshops). You can also read an old blog post I wrote on an introduction to DNS & IPv6 at https://developcents.com/2013/10/28/introduction-dns-ipv6/.

But back to this topic… There are a lot of new TLDs, such as .bid and .science. At Develop CENTS, we’ve noticed that spammers are the only ones sending email from domain names inside many of these TLDs.

In an effort to curb this spam, we block email coming from many of these TLDs completely. Here’s how you can too (these instructions are for CentOS servers, but can of course be adapted to your your particular Linux distribution and wherever your Postfix configuration files are located).

1. Create a file in /etc/postfix, and name it “reject_domains”
(vim /etc/postfix/reject_domains)

2. Here are the current contents of our reject_domains file – it’s growing, but we currently are blocking email from 15 different TLDs:

/\.pro$/ REJECT We reject all .pro domains
/\.date$/ REJECT We reject all .date domains
/\.science$/ REJECT We reject all .science domains
/\.top$/ REJECT We reject all .top domains
/\.download$/ REJECT We reject all .download domains
/\.work$/ REJECT We reject all .work domains
/\.click$/ REJECT We reject all .click domains
/\.link$/ REJECT We reject all .link domains
/\.diet$/ REJECT We reject all .diet domains
/\.review$/ REJECT We reject all .review domains
/\.party$/ REJECT We reject all .party domains
/\.zip$/ REJECT We reject all .zip domains
/\.xyz$/ REJECT We reject all .xyz domains
/\.stream$/ REJECT We reject all .stream domains
/\.bid$/ REJECT We reject all .bid domains

3. Edit /etc/postfix/main.cf and add the following line:
smtpd_sender_restrictions =
check_sender_access pcre:/etc/postfix/reject_domains

4. Reload Postfix:
postfix reload

You’re done. Hopefully this will help you combat spam too.

Need help with your Linux web or email server? Contact me at https://developcents.com/contact/ to start a conversation.

Share

5 thoughts on “Fighting Spam: Block entire (T)TLD with Postfix

  1. Jacques

    Hi All,

    I use Postfix v2.10.1 and I followed your tutorial.
    My /etc/postfix/access file :
    /\.date$/ REJECT

    When I try this conf file with the next command, it seems that the regular expression doesn’t work :
    postmap -q “toto@test.date” hash:/etc/postfix/access

    But if I modified access file with an entry as follow :
    toto@test.date REJECT

    The test command works.

    Maybe any ideas ?

    Jacques

    Reply
  2. Thorsten Gust

    Hi David,

    Build my first own Mail-Server and realized how many things must be done to get that running, including
    fighting spam. In the past I’ve supported SUN Microsystems Mail Server and does not know how many stress it is to have an own one.

    So thanks for that blog it helps me so much !

    Thanks and best regards
    Thorsten

    Reply
  3. sophie

    1. I use a .xyz for my businness. Like many others. The domain was cheap to register a few years ago. Instead of blocking entire domains, why not be a little more intelligent in this?
    2. Postfix is not meant to be a spam filter, per se. It’s an MTA. Take the time to configure SpamAssasin or RSPAMD. Also chain in the clamav-milter. Maybe you’ll have fewer false positives.
    Regards..

    Funnily I knew a sys admin in the Netherlands who blocked the whole *.uk TLD, and then wondered why his email alerts from amazon.co.uk never arrived in his mailbox.

    Reply
    1. David Post author

      Those are certainly good points. And you are correct: Postfix is an MTA. You’ll get no argument from me there.
      However, as you likely know, the volume of spam that the typical MTA receives is absurd. We have made the decision to block these TTLDs because there has never been a use case for us, or any of our clients whose email is hosted on our infrastructure, to communicate with others who have an email address at one of those TTLDs mentioned. Here’s a nice article from Brian Krebs on the subject of TLDs and spam: https://krebsonsecurity.com/tag/new-tld-spam/

Leave a Reply

Your email address will not be published. Required fields are marked *