Überprüfen Sie eine Abhängigkeitskette und nicht einen TXT Wert
MTA-STS hängt von der Erkennung, einer authentifizierten HTTPS-Richtlinie und den von dieser Richtlinie beschriebenen empfangenden E-Mail-Hosts ab. A TXT Eintrag Das korrekt aussieht, kann mit einer nicht erreichbaren Richtliniendatei oder einem MX Zertifikat koexistieren, das nicht übereinstimmt. Ein nützlicher Checker meldet daher jede Phase separat und erläutert, welche späteren Schlussfolgerungen nach einem früheren Fehler nicht gezogen werden konnten.
Dieser Leitfaden schlägt das Diagnoseverhalten vor, ohne ein funktionierendes EmailAuth Tool bereitzustellen. Es ist keine DNS Suche, kein HTTPS-Abruf für eine Kundendomäne, SMTP Verbindung oder keine Richtlinienänderung aufgetreten. Das genaue Implementierungstor ist offen: Implementieren und testen Sie die versprochene Funktion. Ein Artikel, ein Modell oder eine Spezifikation allein ist kein Arbeitsinstrument.
Leiten Sie die Erkennung von der beabsichtigten Empfängerrichtliniendomäne ab
Beginnen Sie mit der auszuwertenden Richtliniendomäne und notieren Sie, warum sie in den Geltungsbereich fällt. Der Discovery-Eigentümer ist _mta-sts gefolgt von dieser Domäne. Unter RFC 8461 erfordert die Erkennung Filter für die unterstützte Version, erfordert einen verwendbaren passenden TXT Eintrag und akzeptiert einen CNAME Pfad zum TXT Wert. Mehrere Zeichenfolgen innerhalb eines TXT Datensatzes werden ohne eingefügte Leerzeichen verkettet; Mehrere übereinstimmende Datensätze sind ein anderes Problem.
Das ID-Feld identifiziert eine Richtlinienrevision, weist jedoch keine implizite numerische oder chronologische Reihenfolge auf. Ein Prüfer sollte den genauen Bezeichner beibehalten, anstatt davon auszugehen, dass eine länger aussehende Zeichenfolge neuer ist. Wenn kein verwendbarer Erkennungsdatensatz vorhanden ist, wird eine Richtlinie, die ein Absender bereits zwischengespeichert hat, nicht automatisch entfernt. RFC 8461 , Abschnitt 3.1.
Authentifizieren Sie den Richtlinienhost und überprüfen Sie die genaue Antwort
Die vorgeschriebene URL verwendet https, die Hostbezeichnung mta-sts und /.well-known/mta-sts.txt. Für fiktives recipient.example wird daraus https://mta-sts.recipient.example/.well-known/mta-sts.txt. Dies ist eine konstruierte Illustration, keine abgerufene Ressource. Das Policy-Host-Zertifikat muss für diesen Host gültig, nicht abgelaufen und an einen vom Absender vertrauenswürdigen Stamm verkettet sein.
RFC 8461 erfordert eine HTTP 200-Antwort, verbietet das Befolgen von HTTP-Weiterleitungen und verbietet HTTP-Caching für den Richtlinienabruf. Es wird empfohlen, den Medientyp „Text/einfach“ zu überprüfen. Ein Checker, der einer Weiterleitung auf die Homepage einer Website folgt und dann Erfolg meldet, hat das falsche Verhalten ausgewertet. Unterscheiden Sie DNS Auflösungs-, Verbindungs-, Zertifikats-, Status- und Richtlinienanalysefehler. Ein Zertifikatsfehler ist ein zu erklärendes Ergebnis und keine Erlaubnis zur Umgehung einer Sicherheitswarnung. RFC 8461 , Abschnitte 3.2–3.3.
Gebundene Abrufzeit und Antwortgröße. Eine serverseitige Implementierung muss auch ausgehende Ziele steuern, damit ein übermittelter Name keine Anfragen an interne Dienste oder Metadatenendpunkte auslösen kann. Wenden Sie Netzwerkbeschränkungen an und validieren Sie das tatsächliche Ziel, einschließlich Adressänderungen, anstatt sich nur auf einen benutzerfreundlichen Hostnamen zu verlassen. Hierbei handelt es sich um vorgeschlagene Designanforderungen, nicht um implementierte Abwehrmaßnahmen. OWASP SSRF-Präventionsleitfaden.
Parse-Modus, Lebensdauer und MX Bereich zusammen
Die Richtlinie deklariert Version, Modus, max_age und zulässige MX Muster, wobei MX Anforderungen vom Richtlinienmodus abhängen. Jeder erlaubte MX Eintrag belegt eine eigene Zeile. Der max_age-Wert einer Richtlinie regelt ihre Lebensdauer in Absenderrichtlinien-Caches, nicht die DNS TTL oder ein HTTP-Cache-Control-Header. Zeigen Sie diese separaten Konzepte an, anstatt alle drei Ausbreitungszeit zu nennen.
Vergleichen Sie jeden relevanten MX Kandidaten mit den zulässigen Mustern. RFC 8461 beschränkt einen Platzhalter auf das gesamte Label ganz links: *.example stimmt mit mail.example überein, aber nicht mit example oder abexample . Ein umfassender visueller Teilstringvergleich ist daher ungeeignet. Behalten Sie den Kandidatenhost und das genaue Muster bei, das übereinstimmte oder fehlschlug. Ein legitimer Backup- MX der in einer Durchsetzungsrichtlinie weggelassen wird, kann zu einem Verfügbarkeitsproblem werden. RFC 8461 , Abschnitte 3.2 und 4.1.
Verwechseln Sie das Website-Zertifikat nicht mit SMTP Validierung
Das HTTPS-Richtlinienzertifikat authentifiziert den Richtlinienabruf. Der empfangende MX benötigt separat STARTTLS und ein passendes Zertifikat für den eigenen Hostnamen. Ein erfolgreicher Website-Abruf zeigt nicht die Konfiguration des SMTP Servers. Bei jedem später autorisierten aktiven Test sollten der ausgewählte Host, der Verbindungskontext, die Zertifikatsidentität und das Vertrauensergebnis unter Angabe des tatsächlichen Umfangs des Tools beibehalten werden.
Ein Prüfer, der nur DNS und HTTPS liest, sollte die SMTP Phase als ungetestet und nicht fehlerfrei melden. Auch die Überprüfung eines Kandidaten beweist nicht, dass sich jeder MX gleich verhält. Die Implementierung des Absenders und die Vertrauensspeicher wirken sich auf Beobachtungen aus, daher ist ein einzelner Diagnoseaspekt keine Garantie für jeden Korrespondenten. RFC 8461 , Abschnitt 4.
Planen Sie einen kontrollierten Übergang vom Testen zur Durchsetzung
Im Testmodus kann ein implementierender Absender trotz Richtlinienvalidierungsfehlern zustellen, während kompatible TLS -Berichte diese Fehler aufdecken können. Im Durchsetzungsmodus darf ein Absender, der eine gültige Richtlinie einhält, nicht an einen Kandidaten zustellen, der die erforderlichen Prüfungen nicht besteht. Keiner der Modi verwandelt MTA-STS in SPF, DKIM oder DMARC Validierung; Der Mechanismus betrifft SMTP Transport.
Ein vorgeschlagener Übergang sollte einen Eigentümer, einen genehmigten Richtlinienunterschied, eine verifizierte primäre und Backup- MX Abdeckung, eine Zertifikatsbereitschaft und einen definierten Beobachtungszeitraum haben. Überprüfen Sie relevante TLS -Berichte und das tatsächliche Absenderverhalten, bevor Sie entscheiden, ob eine Durchsetzung akzeptabel ist. Das Fehlen von Berichten ist kein Beweis für die Bereitschaft. RFC 8461 , Abschnitt 5 Und RFC 8460.
Bei der Wiederherstellungsplanung müssen zuvor zwischengespeicherte Richtlinien berücksichtigt werden. Das Löschen einer Erkennung oder das Reduzieren eines neuen max_age kann eine bereits zwischengespeicherte ältere Richtlinie nicht sofort verkürzen. Behalten Sie frühere Richtliniengremien und Gültigkeitsdauern bei und planen Sie eine autorisierte Aktualisierung, anstatt ein sofortiges Rollback zu versprechen. Diese Anleitung führt keine Übergangs- oder Wiederherstellungsaktion aus.
Lassen Sie die eigentliche Spur und das Werkzeugtor offen
Der Katalog erfordert: Eine DNS-zu-HTTPS-zu-MX-Validierungsverfolgung und einen kontrollierten Testplan zur Durchsetzung. Bei den oben vorgeschlagenen Prüfungen handelt es sich nicht um diese Spur und es handelt sich nicht um einen getesteten Prüfer. Es wurden keine Umweltnachweise oder genehmigte Übergangspläne eingeholt. Standards und Sicherheitsrichtlinien wurden am 8. November 2026 überprüft; Unabhängige technische Überprüfung, Implementierungstests, visuelle Live-Validierung und Genehmigung der Eigentümerveröffentlichung bleiben noch ausstehend.