Only a few people have tried MTX in the year since it was created, due at least in part to a belief that spammers can create junk domains faster than they can be blacklisted.
I'm not entirely convinced.

Bug requesting inclusion in spamassassin.

MTX Flow Chart

MTX Records

MTX records are just one DNS "A" record for each of your transmitting mail server IP addresses, on your own DNS servers.

A distributed DNS whitelist, requiring both IP and domain ownership.

Without SPF's forwarding breakage.

MTX Record Definition
Using with SpamAssassin
Using My Blacklist (Optional)
MTX Policy Records
Example Scenarios
Comparisons to Other Methods
Sending Error Messages for False Positives


  1. It is easier to maintain a Whitelist than a Blacklist due to many fewer entries.
  2. It is yet easier to allow others to maintain their own entries on the Whitelist on the authority of IP address ownership (DNS PTR record delegation).
  3. It is easier to maintain a Blacklist of Whitelist abusers than either a complete Whitelist or Blacklist.

MTX was conceived on 8 February 2010.

Recommendations at This Time

Create your MTX records to whitelist your mail servers

Benefit: Mail from your servers is less likely to be classified as spam.
Detriment: None.

Use MTX plugin for SpamAssassin for whitelisting only

Benefits: Legitimate mail from people using MTX is more likely to correctly pass SpamAssassin. More people will be encouraged to create their MTX records.
Detriment: Small chance of spammers getting past SpamAssassin by using MTX. Expected to be easy to handle with included blacklisting functionality.

Generate or Test MTX Records

This wizard, given a mail server IP address, will generate MTX DNS records in BIND server syntax, and check the condition of existing MTX records. It's not very friendly looking yet.

MTX Record Definition

Just one DNS "A" record for each transmitting mail server, with a value of "" in the format:


For a server with IP and hostname (DNS PTR record), it is:

(You also need to have a DNS PTR record for the IP defining the host name, but you should already have that.)

For IPv6, the IP is reversed in the same manner as reverse DNS (PTR) records, just like IPv4. The PTR record for 2001:470:1f05:1b8a::1 is, expanded to long form, reversed, then add a dot between each digit:

$ host 2001:470:1f05:1b8a::1 domain name pointer

Which makes the MTX record

The Bind DNS server syntax for these record is: IN A IN A

If the value of that record matches 127.*.*.1 (PCRE /^127\.\d{1,3}\.\d{1,3}\.0$/), it's a legitimate transmitting mail server (for all domains), and unlikely to be spam. If it's anything else (particularly undefined, or it is not legitimate, and likely to be spam.

Protocol Notes

The wild cards in the MTX record value check are to enable the use of other values in the second and third octets in the future, similar to DNSWL.

Both PTR and A records can have multiple values. Use the first value of each. Future versions may involve multiple A (MTX) record values, as commonly used in DNS blacklists.

When implementing MTX checks, be sure not to DOS yourself by doing A record lookups on a maliciously large number of PTR values (just do the first).

Do not implement MTX without blacklisting. There is nothing else preventing a spammer from whitelisting their own IPs with MTX. If there are no spammers using MTX, it is because blacklisting is part of the protocol. (For example, there are plenty of spammers who use SPF, a protocol without blacklisting.)

There is nothing new here. The records are in a format identical to those used by DNSWL for several years, which are identical to those used by DNS blacklists forever, except with reverse meaning. The only difference from DNSWL is that the records are hosted by the domain of the host name (PTR) of the IP, basically where SPF stores them, instead of the centralized

Using MTX with SpamAssassin

Unrelated to MTX, you really should upgrade to SpamAssassin version 3.3.0 or newer.

  1. Download the SpamAssassin plugin (
    2019-03-02Current. SpamAssassin renamed the RegistryBoundaries module. SA v3.4.2.
    2011-05-29IPv6 support by Andreas Schulze. Tested with SA v3.3.1 and 3.3.2-rc1.
    2010-02-16Don't check Policy if None is already determined (optimization, not bug fix). Minor tidying.
    This and older versions have only been tested with SA v3.2.5.
    2010-02-15Implemented MTX Policy records. Fixed implicit split to @_.
    2010-02-14Don't "fail" on "last untrusted relay not available".
    2010-02-13Unexpected conditions = "fail" (duh). Un-broke CNAME handling. Use last untrusted relay instead of last external relay.
    2010-02-12Implemented blacklisting.
    2010-02-10Initial release.
  2. Save it in /etc/spamassassin/
  3. In /etc/spamassassin/ add the following lines:
    loadplugin Mail::SpamAssassin::Plugin::MTX
    header   MTX_PASS      eval:check_mtx_pass()
    header   MTX_FAIL      eval:check_mtx_fail()
    header   MTX_NONE      eval:check_mtx_none()
    header   MTX_NEUTRAL   eval:check_mtx_neutral()
    header   MTX_SOFTFAIL  eval:check_mtx_softfail()
    header   MTX_HARDFAIL  eval:check_mtx_hardfail()
    header   MTX_BLACKLIST eval:check_mtx_blacklist()
    score    MTX_PASS -2       # Bonus for Pass.
    score    MTX_FAIL 0.001    # Using NONE/NEUTRAL/SOFTFAIL/HARDFAIL instead.
    score    MTX_NONE 0.001    # No penalty for not using MTX, until it's
                               # more widely used.
    score    MTX_NEUTRAL 0.001 # Same lack of penalty for people using MTX prefering
                               # minimum penalty for IPs without an MTX record.
    score    MTX_SOFTFAIL 1    # More penalty for those who want it.
    score    MTX_HARDFAIL 100  # Major penalty for those who want it.
    # MTX_BLACKLIST score defined per domain.
    describe MTX_PASS MTX: Passed:
    describe MTX_FAIL MTX: Failed:
    describe MTX_NONE MTX: Not defined:
    describe MTX_NEUTRAL MTX: Neutral:
    describe MTX_SOFTFAIL MTX: SoftFail:
    describe MTX_HARDFAIL MTX: HardFail:
    describe MTX_BLACKLIST MTX: On your blacklist.
    # Hostname (PTR) of delivering IP to blacklist, and score.
    mtx_blacklist *  4   # Known to send spam *and* non-spam, nullify PASS score.
    mtx_blacklist * 100 # Only sends spam, big penalty.
  4. SA's trusted_networks must be configured properly, otherwise you can end up doing MTX checks on your own internal servers. The default is often fine.
  5. If you have SpamAssassin configured to reject spams during delivery, you could use the error message:

    I'm sorry, my server thought your email was spam. Your DNS administrator can correct this by creating MTX records to whitelist your mail servers:

This plugin, when run in debug mode, will tell you the MTX record for any email. This is useful for determining what record needs to be created to whitelist that email. For example, if you save an email to the file email.txt, and run "spamassassin -t -D < email.txt 2>&1 | grep -i mtx", one of the lines of output will be similar to:

[14152] dbg: mtx: Relevant MTX record is:

MTX_FAIL skips the MTX Policy check and hits whenever MTX_PASS doesn't, so it includes, and is meant to be used as alternative to, all of MTX_NONE, MTX_NEUTRAL, MTX_SOFTFAIL, and MTX_HARDFAIL.

Using My Blacklist - Optional

This is the kind of centralization I prefer to avoid. I'd prefer you maintain your own blacklist, with the mtx_blacklist syntax described above, in your spamassassin config. But I realize some will prefer full automation.

  1. Download
  2. Move it to /usr/local/bin/
  3. Run it (/usr/local/bin/
  4. Verify /etc/spamassassin/ was created.
  5. Put it in a cron job, once a day (just before restarting spampd if relevant) (no more than once a day or I'll probably block you):

    52 3 * * * /usr/local/bin/ ; /usr/bin/sa-update && /etc/init.d/spampd restart

  6. Add this line to /etc/spamassassin/

    include /etc/spamassassin/

  7. Change "$score{'somespam'} = 4;" in to be the reverse of your MTX_PASS score. The default, 4, is appropriate with an MTX_PASS score of -4 (as suggested above).

This will download my blacklist from, save it to /etc/spamassassin/mtx_blacklist.gz, then convert it to a SA readable blacklist named /etc/spamassassin/

It's currently empty.

Help mirror the blacklist.

MTX Policy Records

Without an MTX Policy record, the default is to assume that you would prefer mail from your domain which receives an MTX Fail to get no penalty.

These records allow you to specify that a Fail in your domain means Neutral (no penalty), SoftFail (further scrutinize), or HardFail (reject). The default is no penalty.


Most legit mail servers The owner creates an MTX record = Bonus.
Most spamming hosts The owner creates no MTX record = Penalty.
Hosts which send both spam and non-spam The owner creates an MTX record, and blacklisting is used only to negate the bonus = No bonus or penalty.
Spammers using MTX

Major penalty for being blacklisted.

MTX ties the spam to a domain name, which is tied to a registrar, which can be subpoenaed for the identity of the spammer, who can then be prosecuted.

If a spammer runs a registrar, it can be spotted by repeated abuse, and prosecuted.

For these reasons, I do not expect spammers to use MTX. A public blacklist is provided in case I'm wrong.

Legit servers without MTX Penalty, starting at 0 and rising gradually as adoption spreads.
Spammer using IP and brand new (throwaway) domain he owns. MTX will not block this.
I would love for this to be the biggest challenge to blocking spam. provides a list of domains seen over 10 days ago. Still, a spammer can wait 10 days without establishing a reputation for a new domain. Perhaps the answer would be quicker, possibly automated, blacklisting.

The penalty for both spammers and legit mail servers without an MTX record is necessarily the same. Therefore, the initial primary benefit is the bonuses from having the records (whitelisting), as the penalties can only be proportional to adoption and possibly your willingness to cause a few false positives. I am quite happy with the increased spam blockage that comes with a very small number of false positives.



MTX was created to address the forwarding breakage caused by SPF, by not tying the email to a domain, only tying the sending IP to a domain.

Forwarding breakage is a significant barrier to adoption for spam filtering:

When a user configures one email account to automatically forward their email to another email account, it is generally done without rewriting the "envelope from" which SPF uses for validation. So the forwarding server's IP doesn't match the SPF record of the original "envelope from", so it gets rejected. And the "envelope from" rewriting solutions seem to be even less appealing.


Without Full Circle DNS (FCDNS), a spammer can set the HELO to a domain he owns, create a validating SPF record, and send spam from every IP on the internet.

The disadvantages of SPF HELO + FCDNS compared to MTX are minor:

  1. Complication.
  2. 3 DNS lookups (HELO, PTR, SPF, possibly more if the SPF record isn't all IPs) instead of 2 (PTR, A).
  3. Negative association with SPF (MAIL FROM).
  4. Not implemented.



"The first version of DKIM synthesized and enhanced Yahoo!'s DomainKeys and Cisco's Identified Internet Mail specifications. It was the result of a year-long collaboration among numerous industry players, during 2005..."

MTX was basically conceived and finalized in the same instant. Fewer moving parts; less to break.
The parts that were not instant were deciding on the name, and sanity checking the obvious sequence of parts of the MTX record.


If a spammer manages to get one spam through your server with DomainKeys, they can then forward it to everyone on the internet with your domain's signature on it.

With MTX, if they get one spam through your server, it's just one spam.

Content Modification

DomainKeys: If, for example, a mailing list modifies the email by appending list information, you get a failure. It gets rejected.

MTX: No such problem.

CPU Overhead

DomainKeys: Cryptography adds CPU overhead.

MTX: Doesn't.


DNSWL involves dependence on a central authority. Blacklisting should be unnecessary. More difficult to maintain your own records.

MTX gives the authority to the owner of the IP (PTR delegate). Requires blacklisting participating spammers. Easy to maintain your own records on your own DNS servers.

Full Circle DNS (FCDNS)

My dynamic IP from my cablemodem provider passes that. It doesn't pass MTX.


Client SMTP Authorization

Doesn't require ownership of the IP. So a spammer could send spam from any IP on the internet, as long as they use a HELO matching a domain they own and have created the CSA records for.

Not implemented.

Certified Server Validation

Same problem as previous, doesn't require ownership of the IP.


I have yet to read about this one.

Error Messages for False Positives

False positives, non-spam incorrectly categorized as spam, are always a problem. Too often they are discarded, the recipient never gets them, and the sender never knows the recipient didn't get them.

You can't just send an error message after receipt, because many spams have forged "From:" addresses. That would be backscatter.

The solution is to filter spam during SMTP delivery, so instead of confirming receipt at the end of the transaction, your server can reject the email, with an error defined by you, and the sender gets responsibility for delivering the error. So legitimate senders get an error, and you emit no backscatter.

I think it's irresponsible not to do this.

Configuration instructions using Postfix + SpamAssassin + Spampd are half way down this page:
Spampd as a Before-Queue Content Filter

The Name

"RX" and "TX" are common abbreviations for "receive" and "transmit". DNS "MX" records list the mail servers for a domain. "MTX" is a combination of "MX" and "TX".



It would be nice to set up an email autoresponder to verify your MTX records, as is available for DKIM.


In addition to being simple and stabilized, I run this SpamAssassin plugin through a test harness which tests 12 different possible MTX and Policy record combinations for the correct results in SpamAssassin: Test harness output.

MTX was inspired by SPF by Meng Weng Wong, and DNSWL by Matthias Leisi.
Another anti-spam system I implemented with better short term chances of being useful to you, IPREP.
Its an IP address REPutation system.
My previous thoughts on spam.
Return to Darxus' home page.
Sat Mar 2 12:20:48 EST 2019
HTML validate this page.