Bewerten Sie die Beweise, bevor Sie den Schweregrad zuweisen
Eine Domänengesundheitsbewertung sollte erklären, welche Authentifizierungsabhängigkeiten überprüft wurden, was die Beobachtungen unterstützen und was unbekannt bleibt. Eine einzelne Bewertung kann den Unterschied zwischen einem defekten Produktionssender und einem ungetesteten verdecken Wähler und ein damit nicht zusammenhängendes Website-Problem. Dies ist ein Diagnoseleitfaden und ein vorgeschlagenes Bewertungsdesign, kein funktionierender EmailAuth Scanner. Es wurde keine Kundendomäne abgefragt und es wird kein Live-Ergebnis angezeigt.
Beginnen Sie mit dem Verwendungszweck jeder Domain: aktive Mitarbeitermail, Bewerbungsmail, Marketing, nur Empfang oder bewusst kein Versand. Identifizieren Sie den Geschäftsinhaber und bekannte Absender. Derselbe fehlende Datensatz kann in verschiedenen Kontexten unterschiedliche Konsequenzen haben, und eine Konfiguration, die restriktiv erscheint, kann legitime indirekte E-Mails stören. Priorisieren Sie ein nachgewiesenes Geschäftsrisiko und nicht die Anzahl der farbigen Warnungen, die auf einer Seite angezeigt werden können.
Bewahren Sie eine reproduzierbare Beobachtung
Erfassen Sie für jede vorgeschlagene Prüfung den genauen Domänen- oder Eigentümernamen, den Abfragetyp, die Beobachtungszeit, den Resolver oder autorisierenden Server, den Antwortstatus und relevante Antwortdaten. Unterscheiden Sie eine maßgebliche Beobachtung von einer zwischengespeicherten rekursiven Antwort. RFC 1034 beschreibt diese Rollen; Das Bedienfeld, in dem ein Administrator Änderungen vornimmt ein Rekord ist kein Beweis für die Antwort, die ein Empfänger erhalten hat.
Klassifizieren Sie fehlende Daten sorgfältig. NXDOMAIN , ein vorhandener Name ohne den angeforderten Typ, ein Verweis, eine Alias-Kette und SERVFAIL sind nicht austauschbar. RFC 2308 unterscheidet negative Antworten und den Kontext, der zu ihrer Interpretation erforderlich ist. Ein leerer Antwortabschnitt allein beweist nicht, NODATA . Halten Sie Zeitüberschreitungen und Lösungsfehler sichtbar, anstatt sie in eine permanente Konfigurationsfeststellung umzuwandeln.
Begrenzen Sie das Zwischenspeichern und Sammeln von Datensätzen, ohne zu versprechen, dass eine bestimmte Verzögerung die weltweite Konvergenz beweist. Ein erneuter Versuch von einem Resolver kann ein vorübergehendes Problem klären, stellt jedoch nicht die Ansicht des ursprünglichen Empfängers wieder her. Die Bewertung muss die Unsicherheit wahren, wenn die zugrunde liegende Beobachtung unvollständig ist.
Überprüfen Sie SPF als evaluierte Autorisierungsrichtlinie
Suchen Sie die SPF Richtlinie für die tatsächliche SPF Identität, nicht automatisch die sichtbare Von-Domäne. RFC 7208 erfordert eine Datensatzauswahl und unterscheidet keinen Datensatz von mehreren übereinstimmenden Datensätzen. Mehrere Strings in einem TXT Eintrag sind nicht automatisch mehrere SPF Einträge. Behalten Sie die Ressourcendatensatzstruktur bei, wenn Sie einen Syntaxbefund erläutern.
Notieren Sie für eine nachrichtenspezifische Auswertung die Verbindungs-IP und die relevante Umschlagidentität, einschließlich der HELO Fall, sofern zutreffend. Überprüfen Sie die ausgewerteten Mechanismen und deren DNS Abhängigkeiten. Die Beschränkung auf zehn Suchvorgänge betrifft bestimmte DNS-Abfragebegriffe während der Auswertung, einschließlich rekursiver Verarbeitung; Es handelt sich nicht einfach um die Zählung jedes DNS Pakets oder jedes Wortes in der Richtlinie. Abschnitt 4.6.4 definiert auch zusätzliche Grenzen. Erklären Sie den fehlgeschlagenen Weg, anstatt eine wahllose Reduzierung der Datensätze vorzuschlagen.
Unterscheiden Sie permanente Richtlinienfehler von temporären DNS Problemen und von einer gültigen Richtlinie, die eine bestimmte Quelle nicht autorisiert. Ein syntaktisch gültiger Datensatz kann immer noch einen legitimen Absender auslassen oder zu viel autorisieren. Um zu entscheiden, ob eine Quelle vorhanden sein soll, ist die Unternehmenseigentümerschaft erforderlich.
Für DKIM sind Selektor- und Nachrichtennachweise erforderlich
Ein Domänenname allein zählt nicht jeden verwendeten DKIM Selektor auf. Erhalten Sie Selektor- und Signaturdomänenwerte aus autorisierten Nachrichtennachweisen oder einem verifizierten Absenderinventar. RFC 6376 erklärt die Verwendung von Selektoren. Eine erfolglose Schätzung eines gemeinsamen Selektors ist kein Beweis dafür, dass die gesamte Domäne fehlt DKIM.
Überprüfen Sie den ausgewählten öffentlichen Schlüssel und Algorithmus unter den entsprechenden Updates, einschließlich RFC 8301. Ein veröffentlichter Schlüssel stellt eine DNS Abhängigkeit her und bedeutet nicht, dass ein Absender den privaten Schlüssel besitzt, den beabsichtigten Datenverkehr signiert oder Signaturen erstellt, die die Übertragung überdauern. Überprüfen Sie bei Genehmigung die tatsächlichen Verifizierungsnachweise auf der Empfängerseite. Nachrichteninhalte und private Schlüssel schützen; Beides gehört nicht in einen öffentlichen Diagnosebericht, nur um ein Beispiel vollständig erscheinen zu lassen.
Bewerten Sie DMARC und betriebliche Auswirkungen getrennt
Aktueller DMARC benötigt einen zulässigen Weitergabemechanismus, der auf die Autorendomäne abgestimmt ist. Roher SPF und DKIM Erfolg kann nebeneinander bestehen DMARC Fehler, wenn ihre Domänen nicht übereinstimmen. Notieren Sie die Annahmen zur Richtlinienerkennung und -kennung, insbesondere dort, wo sie aktuell sind DNS Tree Walk Verhalten und Legacy-Implementierungen können unterschiedlich sein. Betrachten Sie eine Richtlinienzeichenfolge nicht als Beweis dafür, dass jeder Empfänger der gleichen Implementierung folgt.
Priorisieren Sie bestätigte Störungen des kritischen legitimen Datenverkehrs, dann ungelöste Abhängigkeiten mit wesentlicher Gefährdung und dann Hygienemaßnahmen mit geringeren Auswirkungen. Halten Sie die vorgeschlagene Begründung für den Schweregrad sichtbar. A p=reject Der Datensatz allein vervollständigt ein Authentifizierungsprogramm nicht, und seine wahllose Anwendung kann Allzweckdomänen mit indirekten E-Mail-Flüssen schaden. Die Handhabung des Empfängers, die Eigentümerschaft des Senders und die Überwachungskontinuität müssen gesondert überprüft werden.
In einer fiktiven Bewertung verfügt receipts.example über einen dokumentierten Zahlungs-Mail-Absender, dessen beobachtete DKIM Verifizierung fehlschlägt, während ein vermutlich nicht verwendeter Selektor ebenfalls keinen Datensatz zurückgibt. Das erste Ergebnis verdient eine Untersuchung, da es sich um einen bekannten Geschäftsablauf handelt; der zweite bleibt ergebnislos. Hier kam es zu keiner der beiden Beobachtungen. Das Beispiel veranschaulicht, wie der Kontext die Priorität ändert, ohne ein echtes Diagnoseprotokoll zu erstellen.
Überprüfen Sie die Korrektur und die Bewertung selbst
Geben Sie für jede Feststellung die vorgeschlagene Maßnahme, den Genehmiger, die erwartete Beobachtung und die sichere Wiederherstellungsbedingung an. Wiederholen Sie die entsprechende Prüfung nach einer autorisierten Korrektur und vergleichen Sie die Beweise, anstatt nur die Ergebnisse zu vergleichen. RFC 8601 erfordert die Beachtung der Vertrauensgrenze von Authentifizierungsergebnis-Headern. Die endgültige SMTP Akzeptanz legt auch nicht die Platzierung im Posteingang fest, da die Transportverantwortung darin liegt RFC 5321 deutlich machen.
Eine funktionierende Bewertung erfordert Tests auf gültige Eingaben, fehlerhafte Datensätze, Aliase, negative Antworten, vorübergehende Fehler, fehlende Selektoren und nicht unterstützte Fälle mit erwarteten Ergebnissen und erklärten Fehlern. Offen bleibt die genaue Inbetriebnahmevoraussetzung: Ein funktionierendes Tool mit erwarteten Ergebnisvorgaben, Originaleingaben, Beobachtungszeit und erklärten Fehlern. Dieser Leitfaden und die vorgeschlagene Karte erfüllen diese Anforderungen nicht. Die Veröffentlichung als Arbeitsressource erfordert eine Implementierung, autorisierte Originalbeobachtungen und reproduzierbare Tests, gefolgt von einer technischen und Eigentümergenehmigung.