mts.net email servers, SPF and DMARC

mts.net publishes a single MX host, mx.mymts.net. With no backup host, a sender that can't reach it queues the message and retries until the server answers or the queue gives up.

The record on 5 November 2026 was v=spf1 include:_spf.mts.syn-alias.com include:bellnet.ca ~all.

In plain terms, it delegates to _spf.mts.syn-alias.com and bellnet.ca. The top level uses 2 DNS-querying terms; SPF allows 10 in total including nested includes (RFC 7208 §4.6.4).

It ends in a soft fail (~all): mail from unlisted servers should be accepted but treated as suspicious.

The record is v=DMARC1; p=quarantine; rua=mailto:[email protected];.

p=quarantine asks receivers to send failing mail to spam.

Aggregate reports go to dmarc.bellmts.net, so the domain's owner sees who sends mail as @mts.net.

What that means for you: if a contact gives an @mts.net address and you send to them, nothing changes. But never put an @mts.net address in the From line of mail sent through your own tool or ESP. It can't pass DMARC for mts.net, and this policy tells receivers to junk it.

1 other domain published exactly the same MX hosts and SPF record as mts.net on 5 November 2026: mymts.net. Mail to any of them lands on the same servers.

Our checker treats @mts.net like any domain: syntax, MX, disposable and role checks first, then a made-up address to rule out a catch-all, then your address at RCPT TO, disconnecting without sending. We have not published a test of how mx.mymts.net answers for @mts.net, so we make no claim here about whether single mailboxes can be confirmed; each result carries its own reason.

DNS tells you where mail goes, not whether one person's mailbox still exists. For a list, run the whole file through a verifier before you send: invalid rows come out, risky rows (catch-all, unknown, refused) go in their own segment, and valid rows are safe to mail.