Die Einträge, die über Zustellung entscheiden
Seit Google, Yahoo und Microsoft SPF, DKIM und DMARC von Absendern verlangen, entscheidet die DNS-Zone über den Posteingang. Die Einträge sind schnell gesetzt und genauso schnell kaputt: Ein zusätzlicher include sprengt das Lookup-Limit, ein Hosterwechsel verliert den DKIM-Schlüssel, jemand setzt DMARC zum Testen auf none und vergisst es.
DomainWarn prüft die Einträge im Intervall des Tarifs, bewertet sie mit denselben Regeln wie die kostenlosen Tools und vergleicht sie mit dem letzten Zustand. Meldungen entstehen bei Fehlern und bei Änderungen, jeweils mit Vorher und Nachher.
Was überwacht wird
- SPF: Syntax, Lookup-Zahl, Abschluss, mehrere Records, Änderungen an den Mechanismen.
- DKIM: Auflösbarkeit und Schlüssellänge der eingetragenen Selektoren, widerrufene Schlüssel.
- DMARC: Existenz, Policy, pct, Berichtsadressen, Abschwächung der Policy.
- MX: Mailserver, Priorität, Auflösbarkeit, Wechsel des Anbieters.
- MTA-STS und TLS-RPT: Policy-Datei erreichbar, Modus, MX-Hosts abgedeckt.
- Blacklists: Mailserver- und Website-IPs gegen Spamhaus, Spamcop, Barracuda und weitere.
- DANE für MX: TLSA-Records der Mailserver, DNSSEC-Signierung und Abgleich mit dem per STARTTLS ausgelieferten Zertifikat; ein Zertifikatswechsel ohne neuen TLSA-Record wird als kritisch gemeldet.
- Mailserver selbst: Erreichbarkeit auf Port 25, STARTTLS, TLS-Version und Zertifikat je MX-Host sowie Reverse-DNS (PTR) der Mailserver-IPs.
Fehlende Records per Klick anlegen
Fehlt DMARC, SPF, TLS-RPT oder CAA, schlägt DomainWarn den Record mit konservativen Werten vor: DMARC mit p=none und Berichtsadresse, SPF mit dem include des erkannten Mailanbieters und ~all, TLS-RPT mit Berichtsadresse, CAA für die tatsächlich genutzte Zertifizierungsstelle. Liegt die Zone bei Cloudflare, Hetzner DNS, IONOS, netcup, INWX, OVHcloud, Amazon Route 53, deSEC oder autoDNS und ist das Konto als Integration verbunden, legt ein Klick den Record an. Ebenso per Klick: ~all statt +all oder ?all im SPF-Record und die ausstellende CA in einem CAA-Satz, der sie aussperrt. Bestehende Records ändert DomainWarn nur nach ausdrücklicher Bestätigung, gelöscht wird nie etwas, und geschrieben wird nur, wenn alle Nameserver der Domain auf den Anbieter zeigen. Ohne Integration stehen die Werte zum Kopieren bereit.
DMARC-Monitoring ohne Report-Dienst
DMARC-Report-Dienste werten die XML-Berichte aus und zeigen, wer im Namen der Domain sendet. Das ist wertvoll für die Einführung von p=reject. DomainWarn ergänzt das um die andere Seite: Es überwacht den Record selbst. Der häufigste Schaden ist nicht ein unbekannter Versender, sondern eine Policy, die jemand zurückgedreht hat, oder ein Record, der beim DNS-Umzug verloren ging.
Für MSPs und Agenturen mit vielen Kundendomains
Kunden, Domains und Benachrichtigungen sind getrennt: Jede Meldung nennt Kunde und Domain, der Kunde bekommt auf Wunsch eine Status-Seite und einen Monatsbericht, der Digest am Morgen fasst alle zusammen. Neue Kundendomains lassen sich importieren, die Monitore entstehen automatisch. Im Agency-Tarif kostet eine Domain unter 50 Cent im Monat, ein Bruchteil dessen, was eine Stunde Fehlersuche bei einem Spam-Problem kostet.
Häufige Fragen
- Wertet DomainWarn DMARC-Berichte aus?
- Nein, DomainWarn überwacht die Records und ihre Änderungen. Für die Auswertung der Berichte eignet sich ein Report-Dienst; beide ergänzen sich.
- Welche DKIM-Selektoren werden geprüft?
- Die beim Anlegen erkannten und alle, die du je Domain einträgst. Der Check meldet, wenn ein Selektor nicht mehr auflösbar ist oder der Schlüssel zu kurz wird.
- Wie schnell fällt eine abgeschwächte DMARC-Policy auf?
- Im Prüfintervall des Tarifs: SPF und DMARC werden im Agency-Tarif stündlich geprüft, im Freelancer-Tarif alle drei Stunden. Die Änderung wird als kritisch gemeldet.