Fake MX Records - Null MX Records

EQ Admin

EQ Forum Admin
Staff member
A Fake MX record is an extra MX record in the DNS for your domain that is created with the intent of confusing spambots.

The terms fake mx record and null mx record seems to be interchangeable and not used consistently.

Many spambots target the lowest priority (highest number) MX record hoping to hit a backup-mx spooling mail server that has weaker anti-spam mechanisms that the primary MX records for the domain.

For example you might have the existing MX records :

@ MX 10 mail.example.com
@ MX 20 backup-mx.example.com

This is one of the several reasons why I don't like backup-mx services.

To create a Fake MX record you would add another MX record :

@ MX 10 mail.example.com
@ MX 20 backup-mx.example.com
@ MX 30 fake-mx.example.com

The fake-mx.example.com could take a couple forms including :

  • An A record pointing to an IP address that does not listen on port 25/tcp
  • A mail mail server that always defers incoming email connections with a 4xx smtp code.
I can see the logic in some mail admins wanting to create a fake mx record but I am not an advocate of this practice. Their goal is to have spambots hit the MX 30 above so that fewer resources are consumed on their incoming mail servers by spammers. If you are going to create a fake MX record I'd recommend that it point to a mail server that defers the connections so at least you'll have the mail logs when troubleshooting incoming email problems.

I have also read about mail admins that create a fake mx record as the highest priority MX record. In this case they always use a null MX record that does not answer on port 25. I feel that this is too aggressive and should never be done since it's more likely to cause problems with you receiving email email. An example of this MX record configuration is :

@ MX 05 fake-mx1.example.com
@ MX 10 mail.example.com
@ MX 20 backup-mx.example.com
@ MX 30 fake-mx2.example.com

My recommendation for your MX records would be either of the following :

@ MX 10 mail.example.com

or, if you must...

@ MX 10 mail.example.com
@ MX 20 fake-mx.example.com

Again, I don't believe there is ever a reasonable situation that would require creating MX records as both the highest and lowest priority MX records in your DNS.
 

prxy

prxy, Inc.
Here are two references to help differentiate between Fake MX and Null MX records.

Fake MX records normally refer to MX records that always return a temporary (4XX status code) failure, as you describe, requiring the sending server to try again later:
OtherTricks - Spamassassin Wiki

Null MX records were for domains that do not accept email at all. There was an IETF Draft for Null MX records, though the draft itself never went anywhere:
draft-delany-nullmx-00 - A NULL MX Resource Record means "I never accept email"

Unfortunately I haven't seen an official replacement to define a "no mail" domain. I've seen other variations such as "dev.null" as the MX host, but that has similar problems to "." (special case to deal with for optimal use, potential load on root DNS servers, etc).

You can use an SPF record to define that no mail is sent by a domain (e.g. a TXT record specifying "v=spf1 -all"), but that is generally checked by receivers (if it's checked at all!), not senders, so senders will still try to deliver to the MX host (or fall back to the A host).

When implementing different strategies, note that the RFC-Ignorant blacklist captures domains with bogus host names (private space, non-resolving etc) in their MX records:
Listing policy for bogusmx.rfc-ignorant.org zone
This doesn't impact the strategies described above, but I mention it just in case you're thinking of other variations :)

Noah
prxy, Inc.
 

EQ Admin

EQ Forum Admin
Staff member
I've never had to the need to deploy any of the above solutions but while talking with others the terms seems to get mangled. Thanks for some clarification! No, I'm not thinking of using those or other variations msyelf. Within my largest email environment we used the F5 MSM module on our Big IP's as the first level perimeter defense. With our scoring system we were rejecting 70-80% of incoming email. There were some other RBL's, SpamAssassin, in house rules, and other stuff going on, but I never saw the need to add fake MX records and risk introducing problems into the environment. File it under not having an answer to what problem are you trying to solve?
 

EQ Admin

EQ Forum Admin
Staff member
I noticed the bind 9.8 announcement mentioned the "." MX records :

* Don't run MX checks (check-mx) when the MX record points to ".".
[RT #22645]
 
Top