Eine Website kann perfekt laden, obwohl E-Mail-Konfiguration Identitätsmissbrauch erleichtert oder Passwort-Zurücksetzungen verhindert. Das liegt in Domain-Einträgen und Versanddiensten und ist visuell nicht erkennbar. Ziel ist Domain-Schutz ohne Zurückweisung legitimer Geschäftspost.
Das E-Mail-DNS-Modul fragt MX, TXT, DMARC, CAA und den MTA-STS-Discovery-Eintrag des Zielhosts ab. Es meldet Richtliniensignale und behält Abfragefehler. Prüfen Sie die tatsächlich sendende Domain: www.example.com ist nicht automatisch ein vollständiger Test der Mailkonfiguration von example.com.
Umfang dieser Prüfung
Was messbar ist
- Beobachtete MX-, SPF-TXT-, _dmarc-TXT-, CAA- und _mta-sts-Discovery-Einträge des abgefragten Namens.
- Erlaubende oder neutrale SPF-Enden, direkte Zählung DNS-abfragender Mechanismen und DMARC-Beobachtungsmodus.
- Unterstützte erfolgreiche Richtlinienprüfungen und DNS-Fehler als Belege.
Was sie nicht belegt
- Das native Modul versendet keine Testnachrichten, prüft keine Posteingangsplatzierung und nicht jeden DKIM-Selektor.
- Die direkte SPF-Zählung löst verschachtelte Includes nicht rekursiv auf; eine kleine Zahl beweist keine Einhaltung.
- Ein MTA-STS-TXT beweist weder funktionierende HTTPS-Richtliniendatei noch Mailserver-TLS.
Prüfen Sie ein autorisiertes, verifiziertes Ziel und die wirksamen Module von Tarif und Profil. Öffentliche Konfiguration ist nicht gleich Anbieteranbindung oder Zustellnachweis; dafür sind weitere Schritte nötig.
Vor DNS-Änderungen alle Absender erfassen
Inventarisieren Sie Mitarbeiterpost, Support, Transaktionsmail, Rechnungen, Marketing und aktive Altdienste. Notieren Sie sichtbare From-Domain, Envelope-Absender, DKIM-Signaturdomain und Verantwortliche. Lassen Sie jeden Anbieter seine aktuellen DNS-Anforderungen bestätigen; übernehmen Sie keinen geratenen Include-Wert anderer Unternehmen.
Halten Sie abgefragten Namen, Ergebnis und Zeitpunkt fest. Ein DNS-Timeout ist keine autoritative Auskunft über fehlende Einträge. Prüfen Sie Unerwartetes beim DNS-Anbieter und berücksichtigen Sie Caches. MX beschreibt Empfang; eine Domain kann ohne MX senden. Schweigen bei fehlendem MX beweist daher keinen sicheren Versand.
Richtlinienbefunde angemessen bewerten
| Beobachtung | Typische Priorität | Bedeutung |
|---|---|---|
| SPF endet mit +all | Hoch | Jeder Absender ist autorisiert |
| Kein SPF oder DMARC für Maildomain beobachtet | Meist mittel; Abfrage und Domain prüfen | Wichtige Anti-Spoofing-Richtlinie fehlt |
| SPF-Abfragelimit-Warnung | Mittel | Auswertung kann fehlschlagen |
| DMARC p=none | Niedrig; möglicherweise bewusste Einführungsphase | Beobachtung ohne Quarantäne- oder Ablehnungswunsch |
| CAA oder MTA-STS-Discovery fehlt | Meist niedrig | Zusätzliche Härtung untersuchen |
Eine schwache Richtlinie beweist keine zugestellte Fälschung. Eine vorhandene Richtlinie garantiert keine Zustellung. Priorisieren Sie Domains für Anmeldelinks, Rechnungen und Support, deren Missbrauch Vertrauen unmittelbar schädigt.
SPF reparieren, ohne gültige Absender zu verlieren
SPF bewertet den verbindenden Absender gegen die Envelope-Domain, nicht direkt die sichtbare From-Adresse. Veröffentlichen Sie eine konsistente Richtlinie mit tatsächlich genutzten Anbietern. Vermeiden Sie +all; wählen Sie die endgültige Regel nach Tests legitimer Quellen.
Das Protokoll begrenzt DNS-abfragende Terme während der Auswertung auf zehn, einschließlich verschachtelter Includes und Redirects. Die direkte Textzählung von Sitelemetry ist ein Frühhinweis, keine rekursive Auswertung. Prüfen Sie die vollständige Kette mit Anbieterhilfe. Entfernen Sie alte Absender und unnötige Mechanismen zuerst. Blindes Ersetzen von Includes durch feste IPs erzeugt Wartungsrisiken bei Infrastrukturänderungen.
DMARC sicher von Beobachtung zu Durchsetzung führen
DMARC verbindet die sichtbare From-Domain mit ausgerichteter SPF- oder DKIM-Authentifizierung. Einer der ausgerichteten Mechanismen kann genügen; beide sind nicht immer erforderlich. DKIM-Selektoren sind anbieterspezifisch, ein öffentlicher Scan kann nicht alle Schlüssel zuverlässig erraten.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comDies ist eine beispielhafte Beobachtungsrichtlinie. Ersetzen Sie das Postfach durch ein kontrolliertes und auswertbares Ziel; externe Berichtsempfänger können DNS-Autorisierung benötigen. Prüfen Sie Berichte und alle legitimen Ströme einschließlich Weiterleitungseffekten. Korrigieren Sie Ausrichtung vor quarantine oder reject. Ein gestufter Wechsel schützt Passwort-Mails und Rechnungen besser als Ablehnung mit unvollständigem Inventar.
CAA und MTA-STS beantworten unterschiedliche Fragen
CAA bestimmt zulässige Zertifikatsaussteller. Stimmen Sie Einschränkungen mit tatsächlichen Anbietern, CDN-Zertifikaten und Wildcard-Anforderungen ab. Fehler können Erneuerungen stören. Fehlende CAA ist eine Härtungsmöglichkeit, kein Beweis für ein Angreiferzertifikat.
MTA-STS ermöglicht teilnehmenden Absendern eine veröffentlichte TLS-Richtlinie für eingehende Zustellung. TXT-Discovery allein genügt nicht: HTTPS-Datei, MX-Muster und Mailserver-Zertifikate müssen zusammenpassen. Testen Sie alles vor Durchsetzung. Es ist nicht Website-HTTPS; ein fehlender TXT beweist nicht, dass sämtliche Mail unverschlüsselt übertragen wird.
Einträge und echte Zustellung validieren
- Bisherige DNS-Werte und Dienstverantwortliche sichern.
- Geprüfte Änderung beim autoritativen DNS-Anbieter veröffentlichen und Hostnamen bestätigen.
- Nach relevanten Cache-Zeiten erneut prüfen und denselben Scanumfang wiederholen.
- Kontrollierte Nachrichten jedes legitimen Dienstes an eigene Testkonten senden.
- Empfänger-Authentifizierung und DMARC-Berichte auswerten; Passwort-Mails, Rechnungen und Supportantworten bestätigen.
Trennen Sie Richtlinienprüfung von Zustellüberwachung. Reputation, Filter und Inhalt wirken auch bei erfolgreicher Authentifizierung. Dokumentieren Sie DNS-Fehler, unbewertete Selektoren und ungetestete Dienste, damit eine grüne Zusammenfassung keine Lücken verdeckt.
Häufige Fragen
Prüft Sitelemetry, ob alle E-Mails im Posteingang landen?
Nein. Öffentliche DNS-Prüfungen bewerten Konfigurationssignale. Zustellung benötigt Testnachrichten, Authentifizierungsergebnisse beim Empfänger und Anbieter- oder Postfachdaten.
Ist DMARC p=none eine Fehlkonfiguration?
Es kann eine bewusste Beobachtungsphase sein. Da keine Durchsetzung angefordert wird, sollten Berichte und Ausrichtung vor Verschärfung geprüft werden.
Kann SPF trotz erfolgreicher Prüfung das Limit überschreiten?
Ja. Die native Prüfung zählt sichtbare Mechanismen, statt sämtliche Includes rekursiv auszuwerten. Bestätigen Sie verschachtelte Anbieterrichtlinien, bevor Sie vollständige Einhaltung behaupten.
Quellen und weiterführende Links
- RFC 7208: Sender Policy Frameworkwww.rfc-editor.org
- RFC 9989: DMARCwww.rfc-editor.org
- RFC 8659: DNS-Autorisierung von Zertifizierungsstellenwww.rfc-editor.org
- RFC 8461: SMTP MTA Strict Transport Securitywww.rfc-editor.org
- RFC 9990: aggregierte DMARC-Berichtewww.rfc-editor.org
Vom Sitelemetry-Team mit dem Prüfumfang des Produkts und verlinkten Primärquellen abgeglichen. Beispiele dienen der Veranschaulichung, sofern kein beobachteter Fall ausdrücklich genannt wird.
