t-com.hr email servers, SPF and DMARC

t-com.hr publishes 3 MX hosts, all at priority 10, so senders spread mail across them.

The record on 5 November 2026 was v=spf1 mx ip4:195.29.150.236 ip4:195.29.150.85 ip4:195.29.150.125 ip4:195.29.150.14 ip4:195.29.150.135 ip4:195.29.150.139 ip4:195.29.41.21 ip4:195.29.150.17 ip4:172.26.133.19 include:_spf.mail.iskon.hr -all.

In plain terms, it delegates to _spf.mail.iskon.hr and lists 9 IP ranges directly. 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 hard fail (-all): receivers may reject mail from any server the record does not list.

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

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

Aggregate reports go to t.ht.hr, so the domain's owner sees who sends mail as @t-com.hr.

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

Our checker treats @t-com.hr 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 mx01.t-com.hr answers for @t-com.hr, 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.