Befunde per Klick beheben

Fehlende DMARC-, SPF-, TLS-RPT- und CAA-Records direkt beim DNS-Anbieter anlegen oder korrigieren: was DomainWarn vorschlägt und wann es schreibt.

Auf dieser Seite

Befunde per Klick beheben

Auf der Domainübersicht erscheint die Karte „Befunde per Klick beheben“, sobald ein aktueller Befund (höchstens 30 Tage alt, Monitor aktiv, letzter Lauf fehlerfrei) einen der unten genannten Records vermisst oder einen korrigierbaren Fehler zeigt; dieselben Vorschläge stehen auch dort, wo der Befund erscheint (E-Mail → SPF und TLS-RPT, Bereichsseiten). Jeder Vorschlag zeigt Typ, Name und Inhalt mit Kopierknopf; mit passender Integration und Nameservern beim Anbieter gibt es den Knopf „Bei {Anbieter} anlegen“ bzw. „Bei {Anbieter} ändern“ mit Bestätigungsdialog. Danach steht die Änderung im Audit-Log und in der Zeitleiste, und die Prüfung läuft nach etwa zwei Minuten erneut.

Einen bestehenden Record ändert DomainWarn nur nach ausdrücklicher Bestätigung: die Karte zeigt bisherigen und neuen Wert nebeneinander, und die Änderung scheitert, wenn der Record beim Anbieter inzwischen anders dasteht als in der Vorschau. Gelöscht wird nie etwas.

  • DMARC: TXT _dmarc.<domain> mit v=DMARC1; p=none; rua=mailto:<adresse>. Die Berichtsadresse gibst du ein (Vorschlag dmarc@<domain>); liegt sie auf einer fremden Domain, prüft DomainWarn deren Freigabe-Record.
  • SPF: TXT auf der Domain mit v=spf1 <include des erkannten Mailanbieters> <weitere Sender> ~all. Erkannt werden Microsoft 365, Google Workspace, IONOS, STRATO, ALL-INKL, Hetzner, mailbox.org, Posteo, Proton, Zoho, Fastmail und iCloud; ein unbekannter Anbieter ergibt mx. Weitere Sender trägst du als include:, ip4:, ip6:, a oder mx ein, bis zu acht; der fertige Record wird vorab aufgelöst und bei mehr als zehn Lookups abgelehnt.
  • TLS-RPT: TXT _smtp._tls.<domain> mit v=TLSRPTv1; rua=mailto:<adresse>. Mit Berichts-Postfach ist die Berichtsadresse von DomainWarn für diese Domain vorbelegt (die Berichte erscheinen dann unter E-Mail → Berichte), sonst lautet der Vorschlag tls-reports@<domain>.
  • SPF zu freizügig (+all, ?all oder kein all): derselbe Record mit ~all, auf Wunsch mit weiteren Versendern davor. Das ist eine Änderung des bestehenden Records, also nur mit Bestätigung; -all schlägt DomainWarn nicht vor, weil ein vergessener Versender dann abgewiesen würde. Nur bei genau einem SPF-Record ohne Syntaxfehler.
  • CAA: 0 issue "<ca>" für die Zertifizierungsstelle, die laut Zertifikaten und CT-Logs tatsächlich ausstellt, nur wenn genau eine CA im Spiel ist (etwa Let's Encrypt, Sectigo/ZeroSSL, DigiCert, GlobalSign, Google Trust Services, Amazon, GoDaddy, Buypass, SSL.com, HARICA).
  • CAA sperrt die ausstellende CA aus: ein zusätzlicher issue-Record (bei Wildcard-Zertifikaten issuewild, wenn der Satz issuewild-Records hat) für genau diese CA; die bestehenden Records bleiben. Nicht bei issue ";" (bewusst gesperrt), bei unbekannter CA oder einem Satz außerhalb der Zone. Route 53 führt je Name nur einen CAA-Satz und lehnt das Ergänzen ab; dort den Wert von Hand hinzufügen.
  • Nur als Empfehlung am Befund, nicht per Klick: mehrere SPF-Records (zusammenführen hieße löschen), zu viele SPF-Lookups (Entscheidung über die Dienste), DNSSEC (der DS-Record liegt beim Registrar) und die DMARC-Policy.
  • Sicherheit: Vor dem Schreiben werden die Nameserver frisch aufgelöst und die Zone im Konto gesucht; existiert schon ein passender Record, bricht DomainWarn ab. Je Zone, Typ und Name läuft nur ein Schreibvorgang gleichzeitig. Anlegen und Ändern dürfen Owner, Admins und Mitglieder, 20-mal je Minute; Kundenzugänge sehen die Vorschläge nicht.

Siehe auch: E-Mail-Monitoring