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.

MTX Records

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

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.

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

IPReversed.mtx.HostName

For a server with IP 64.71.152.40 and hostname (DNS PTR record) panic.chaosriegns.com, it is:

40.152.71.64.mtx.panic.chaosreigns.com

(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:

40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.8.b.1.5.0.f.1.0.7.4.0.1.0.0.2.mtx.panic.chaosreigns.com. IN A 127.0.0.1

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 127.0.0.0) 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 list.dnswl.org.

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:

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.

Change "$score{'somespam'} = 4;" in mtx_blacklist.pl 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 http://www.mtxbl.chaosreigns.com/mtxbl.gz, save it to /etc/spamassassin/mtx_blacklist.gz, then convert it to a SA readable blacklist named /etc/spamassassin/mtx_blacklist.cf.

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.hostkarma.junkemailfilter.com 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.

SPF

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.

SPF HELO

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:

Complication.

3 DNS lookups (HELO, PTR, SPF, possibly more if the SPF record isn't all IPs) instead of 2 (PTR, A).

Negative association with SPF (MAIL FROM).

Not implemented.

DomainKeys

Simplicity

"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.

Replay

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

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.

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.

The Name

ToDo

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

Reliability

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.