SPF, DKIM und DMARC: Ein E-Mail-Authentifizierungs-Workflow
Überprüfen Sie SPF, DKIM und DMARC in einer sinnvollen Reihenfolge, ohne veröffentlichtes DNS mit erfolgreicher Lieferung zu verwechseln.
Inventarisierung der Dienste, die für Sie senden
Beginnen Sie mit einer Liste der Systeme, die Sie tatsächlich verwenden: ein Mailbox-Anbieter, eine Newsletter-Plattform, ein Transaktionsservice und jede Support- oder Rechnungssoftware. Notieren Sie für jeden die sichtbare From-Domäne, die erwartete Return-Pfad-Domänen und den vom Anbieter bereitgestellten DKIM-Selektor. Dieses Inventar gibt DNS-Ergebnisse Kontext. Ein Datensatz kann isoliert plausibel aussehen, während ein Dienst weggelassen wird, der legitime E-Mails sendet oder ein Dienst beibehalten wird, den Ihre Organisation nicht mehr verwendet.
SPF beschreibt einen autorisierten Sendepfad
SPF wertet eine sendende IP gegen Richtlinien aus, die mit der Envelope-Sender-Domäne verknüpft sind, anstatt einfach die sichtbare Adresse von zu lesen. Seine Ein- und Umleitungsstruktur kann von weiteren DNS-Antworten abhängen. Verwenden Sie den SPF-Checker, um den veröffentlichten oder eingefügten Datensatz und seine konservative Lookup-Schätzung zu überprüfen. Eine statische Zählung kann nicht jede nachrichtenabhängige Auswertung vollständig reproduzieren. Wenn eine DNS-Anfrage nicht abgeschlossen ist, halten Sie das Ergebnis nicht schlüssig, anstatt den nicht verfügbaren Datensatz als Pass zu behandeln.
DKIM verbindet eine Signatur mit einem veröffentlichten Schlüssel
Ein sendendes System signiert Nachrichteninhalte mit einem privaten Schlüssel. Empfänger verwenden die Auswahl- und Signierdomäne, um einen öffentlichen Schlüssel in DNS zu finden, üblicherweise unter selector._domainkey.example.com. Dieser Checker kann die Veröffentlichung, gängige Tags und die base64-Codierung überprüfen. Es validiert nicht die ASN.1-Struktur oder Modulstärke eines RSA-Schlüssels. Es kann eine Nachricht nicht ohne die Signatur und den signierten Inhalt dieser Nachricht überprüfen. Notieren Sie den Selektor, den Ihr Provider tatsächlich verwendet; Das Abfragen eines vermuteten Selektors kann eine Abwesenheit erzeugen, die wenig über einen anderen gültigen Selektor aussagt.
DMARC bringt den sichtbaren Absender in den Vergleich
DMARC überprüft die Ausrichtung zwischen der sichtbaren From-Domäne und einer erfolgreichen SPF- oder DKIM-Identität und veröffentlicht eine angeforderte Handhabungsrichtlinie. Ein Record Checker hilft, die Tags und Richtlinien zu überprüfen; Ein generierter Record ist ein Entwurf, der mit Ihrem Versandinventar verglichen werden soll. Gehen Sie nicht davon aus, dass eine Änderung der Richtlinie einen nicht ausgerichteten Dienst behebt. Bestätigen sie zuerst die authentifizierungseinstellung jedes dienstes und verwenden sie dann beobachtungen und anbieteranleitungen, wenn sie entscheiden, wie nachrichten behandelt werden sollen, die die ausgerichteten Überprüfungen nicht bestehen.
| Überprüfung | Verwendungen | nicht etabliert |
|---|---|---|
| SPF-Aufzeichnung | Envelope-Sender-Politik | Sichtbar aus Ausrichtung oder Posteingangsplatzierung |
| DKIM-Aufzeichnung | Veröffentlichter Selektorschlüssel und grundlegende Kodierung | RSA-Schlüsselstruktur oder Message Signatur Pass |
| DMARC-Aufzeichnung | Ausrichtungseinstellungen und angeforderte Politik | Dass jeder sendende Dienst ausgerichtet ist |
| Header/Berichte | Vom Empfänger gemeldete Beobachtungen | Authentizität willkürlich eingefügter Beweise |
Verwenden Sie echte Nachrichten und Berichte als separate Beweise
Senden Sie für eine praktische Überprüfung eine gewöhnliche Testnachricht über jeden erwarteten Dienst und prüfen Sie die von einem vertrauenswürdigen Empfangssystem hinzugefügten Header. Vergleichen Sie die sichtbare Domain, den Rückweg und die Signatur-Domain mit Ihrem Inventar. DMARC-Aggregatberichte bieten eine weitere Ansicht: Quellen, Nachrichtenzählungen und gemeldete Authentifizierungsergebnisse über einen Zeitraum. Verwenden Sie den Berichtsleser, um eine Quelle zu identifizieren, die es wert ist, untersucht zu werden. Ein Bericht kann Fehler zusammenfassen, aber er erklärt nicht automatisch, ob es sich um Missbrauch, Weiterleitung oder eine legitime Fehlkonfiguration handelt.
Halten Sie Umfang und Vertrauen sichtbar
Eingefügte Header und XML-Berichte sind Daten, die dem Tool zur Verfügung gestellt werden; der Leser stellt ihre Authentizität nicht fest. Eine kopierte Authentifizierungsergebniszeile aus einem nicht vertrauenswürdigen Teil einer Nachricht sollte die vertrauenswürdigen Ergebnisse des Empfängeranbieters nicht überwiegen. Ebenso beweist ein öffentlicher DNS-Schlüssel die Veröffentlichung, nicht dass Ihr Dienst die von Ihnen inspizierte Nachricht signiert hat. Führen Sie ein kurzes Evidenzprotokoll mit dem Datensatz, der relevanten Nachricht oder dem Bericht, dem Anbieter und dem Zeitpunkt der Überprüfung, bevor Sie eine Schlussfolgerung ziehen.
Untersuchen Sie die Lieferung mit einer breiteren Checkliste
Passing Authentication ist nur ein Teil der Postzustellung. Gmail veröffentlicht Absenderanforderungen, die auch das Senden von Infrastruktur, die Formatierung von Nachrichten und benutzerbezogene Praktiken abdecken. Beginnen Sie eine Lieferuntersuchung mit der genauen Antwort des empfangenden Anbieters und einem reproduzierbaren Beispiel. Überprüfen Sie die Änderungen an Ihrem Absenderinventar, bevor Sie das DNS erneut ändern. Authentifizierungstools klären Aufzeichnungen und Beobachtungen; Sie können keine Posteingangsplatzierung versprechen, die Richtlinien eines Anbieters umgehen oder die Reputation anhand einer einzigen Datensatzprüfung bestimmen.