Ein Transportprüfer kann ein echtes Problem entdecken, ohne die Sicherheit jeder Nachricht, die Ihr Unternehmen sendet oder empfängt, nachzuweisen. Bei den meisten Prüfungen wird ein ausgewählter Endpunkt zu einem bestimmten Zeitpunkt mithilfe eines bestimmten Resolvers und einer bestimmten Validierungsmethode beobachtet. Ein vertretbares Ergebnis umfasst daher Umfang und fehlende Deckung, nicht nur ein bestandenes Abzeichen.
Definieren Sie den Lieferroutenbestand
Referenzen: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.
Listen Sie die Empfängerdomänen, MX Hostnamen, Prioritäten, IPv4 und IPv6 -Adressen, gehosteten Gateways und Failover-Routen auf. Beachten Sie, ob der Test dem normalen MX Routing oder einem explizit konfigurierten Smarthost folgt. Notieren Sie die Absenderimplementierung und ob sie unterstützt wird MTA-STS, DANE oder eine lokale obligatorische TLS-Richtlinie. Verschiedene Sendesysteme können für dieselbe Empfangsdomäne unterschiedliche Entscheidungen treffen.
Definieren Sie dann den Anspruch, den jeder Scheck unterstützen kann. Eine öffentliche HTTPS-Anfrage kann die Richtlinienverfügbarkeit von diesem Standpunkt aus ermitteln. Ein TLS Probe kann ein vorgelegtes Zertifikat an einer ausgewählten Adresse beobachten. Eine validierende DNS Abfrage kann Hinweise darauf liefern DNSSEC Status unter einem angegebenen Resolver-Vertrauensmodell. Keiner allein beweist, dass es sich um eine echte Sendung handelt MTA dieselben Daten verwendet und die erwartete Lieferrichtlinie durchgesetzt.
Erfassen Sie den Zustand und nicht nur die Ergebnisse
Referenzen: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.
Behalten Sie für MTA-STS den Erkennungsdatensatz, die genauen Bytes der HTTPS-Richtlinie, die Abrufzeit, den Modus, die Lebensdauer und den Cache-Status des Absenders bei. Behalten Sie für DANE die MX und bei TLSA Antworten, Validierungsstatus und Assoziationsvergleich. Erfassen Sie für jede SMTP Verbindung den ausgewählten Host und die ausgewählte IP. STARTTLS Verhandlung, Peer-Verifizierungsergebnis und Lieferentscheidung. RFC 8461 Abschnitte 3–5, RFC 7672 Abschnitte 2–3.
Eine fehlgeschlagene Sonde sollte ihr Fehlerstadium aufzeichnen. DNS Timeout, TCP-Timeout, fehlendes STARTTLS , Handshake-Fehler und Zertifikatskonflikt sind keine austauschbaren Ergebnisse. Ein erfolgreicher Handshake bedeutet auch nicht, dass der Absender eine zukünftige herabgestufte Verbindung ablehnen würde. Berücksichtigen Sie bei Genehmigung kontrollierte Negativfälle, insbesondere vor der Einführung einer strengen Transportanforderung.
Schließen Sie eine Deckungslücke
In diesem Beispiel für eine synthetische Bestandsaufnahme verfügt mx1.example.net über IPv4 und IPv6 Routen und mx2.example.net ist ein Backup. Eine Beispielbeobachtung deckt nur IPv4 Adresse von mx1 ab. Die Bestandsaufnahme muss die IPv6 und Backup-Routen als ungetestet markieren, anstatt den Erfolg auf alle drei zu übertragen. Die Beobachtung ist ausdrücklich synthetisch und erhebt keinen Anspruch auf einen realen Zusammenhang.
Fügen Sie eine senderseitige Akzeptanzzeile für einen unterstützenden MTA mit einer gültigen Durchsetzungsrichtlinie, eine weitere mit leerem Cache und einen DANE-fähigen Absender mit validiertem TLSA hinzu. Diese Zeilen bleiben ausstehend, bis tatsächliche Protokolle erfasst werden. Dies macht den Akzeptanzplan nützlich, ohne erwartete Ergebnisse als Messungen darzustellen. Außerdem kann ein Notfallhelfer sehen, ob die fehlgeschlagene Route jemals genutzt wurde.
Stimmen Sie Berichte und Betriebsnachweise ab
Referenzen: RFC 8460 §4.1, RFC 8460 §4.2.
TLS-RPT Berichte können Fehler aufdecken, die von teilnehmenden Absendern über einen Berichtszeitraum hinweg festgestellt wurden, und so punktuelle Untersuchungen ergänzen. Ihre Sitzungszahlen sind keine eindeutigen Nachrichtenzahlen und ihre Abdeckung ist nicht universell. Ein ruhiger Berichtszeitraum beweist nicht, dass alle Routen erfolgreich waren, und wiederholte Wiederholungsversuche können Schätzungen der geschäftlichen Auswirkungen erschweren. RFC 8460 Abschnitt 4.4.
Behalten Sie das Rohergebnis, den Zeitstempel, die Toolversion oder den Befehl sowie die engere Schlussfolgerung, die Sie daraus gezogen haben, bei. Erneuter Test nach Zertifikatserneuerung, MX Migration, DNSSEC Änderungen und Richtlinienaktualisierungen. Das Überprüfungspaket umfasst sieben aufbewahrte Loopback-Transkripte vom 7. November 2026 mit Peer-Zertifikat-Bytes für die vier Sitzungen, die die Zertifikatserfassung erreicht haben. Sie decken einen lokalen IPv4 -Python-Client/Server an generierten Ports mit explizit konfigurierten Vertrauens- und Richtlinieneingaben ab, nicht Internet- SMTP , eine DNSSEC Validierungskette, Produktions-MTA-Warteschlangen oder vollständige MTA-STS -Zertifikatprofilkonformität. Die historischen Sitzungen wurden eingesehen, hier jedoch nicht wiederholt. Die beispielhaften Internet- IPv4 , IPv6 und Backup-Pfade bleiben ungetestet; Keiner erbt einen lokalen Pass. Das neu ausgeführte Offline-Abdeckungsmodell prüft nur, ob eine synthetische beobachtete Route die anderen aufgelisteten Routen ungetestet lässt. Erfassen Sie die beabsichtigten MTA- und Routing-Beobachtungen, bevor Sie die Bereitstellungsgarantie in Anspruch nehmen.