← Back to news 24.07.2026

Who sends mail in your name

A phishing mail with your sender address does not hit you, it hits your customers, partners and applicants. Whether that is possible is decided by a handful of DNS records. Why the most common mistake is not a missing DMARC but an existing one that only watches, and what isidaten now checks per domain.

A phishing mail with your sender address does not hit your infrastructure. It hits your customers, your partners and your applicants, and damages a reputation you worked on for years. The uncomfortable part: whether someone can put your domain in the sender field is not decided by your firewall but by a handful of DNS records nobody looks at daily.

Three records, three jobs

SPF defines which servers may send for your domain. DKIM signs outgoing mail so tampering can be detected. And DMARC connects the two: it tells the receiving mail server what to do when a message fails the check. Only this third record turns the first two into enforcement.

The most common mistake is a DMARC that only watches

This is exactly where the trap sits. Many organizations have a DMARC record and consider the topic handled. But if the policy says "p=none", nothing happens when it counts: the receiver is merely asked to send reports. Forged mail is still delivered. "p=none" is meant as an observation phase, to see who legitimately sends in your name before tightening. As a permanent state it is protection that only looks like protection. Enforcement starts at "p=quarantine" or "p=reject".

What isidaten now checks per domain

Attack surface management now covers domain security as its own area: SPF, DKIM, DMARC, plus DNSSEC, CAA, MTA-STS, TLS-RPT and a DNSBL lookup. What is evaluated is not merely whether a record exists but whether it holds: a DMARC on "p=none" appears as a warning, a DKIM selector with an empty key as revoked, an RSA key that is too short as a weakness. The check runs exactly once per registrable domain instead of once per subdomain, so the same findings no longer multiply dozens of times. And when a check is technically impossible, for instance because no DKIM selector is known, it is recorded as not available rather than as a failure. A false positive in a security report costs more trust than it delivers insight.

More is shown on the attack surface management module page. Why phishing defense does not end with technology was covered here before.

Matching solution isidaten for ISO/IEC 27001

Questions about this update?

Talk to us – we are happy to show you this feature in a demo.