ewetel.net email servers, SPF and DMARC

ewetel.net publishes a single MX host, mx1.ewetel.de. 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.

2 other domains we checked on the same day also route mail to hosts under ewetel.de, with different records from ewetel.net: ewe.net and osnanet.de.

The record on 5 November 2026 was v=spf1 ip4:212.6.122.0/24 ~all.

In plain terms, lists 1 IP range directly. The top level uses 0 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=none; rua=mailto:[email protected].

p=none only asks for reports; failing mail is delivered as normal.

Aggregate reports go to ewetel.de, so the domain's owner sees who sends mail as @ewetel.net.

_mta-sts.ewetel.net publishes v=STSv1; id=20251210T000000;, so ewetel.net uses MTA-STS: sending servers that support it must deliver over verified TLS or not at all (RFC 8461).

It also asks for TLS reports with v=TLSRPTv1;rua=mailto:[email protected] (RFC 8460).

Our checker treats @ewetel.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 mx1.ewetel.de answers for @ewetel.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.