Das schnellste Nützliche DMARC Bei der Beweisanfrage werden eine repräsentative Nachricht, die Route, die sie erzeugt hat, und das Ergebnis des empfangenden Systems abgefragt. Ein Screenshot mit der Aufschrift „SPF „bestanden“ oder „Domäne verifiziert“ lässt normalerweise die Identitäten aus, die zur Erklärung des Fehlers erforderlich sind.
Fordern Sie den kleinsten Beweissatz an, der ein Authentifizierungsproblem unterscheiden kann Ausrichtung Problem, ein DNS Problem und ein Lieferproblem. Erweitern Sie die Anfrage nur, wenn eine bestimmte Unsicherheit besteht. Dies reduziert die unnötige Offenlegung von Kundeninhalten und gibt dem Absender eine Aufgabe, die er tatsächlich erledigen kann.
Bitten Sie zunächst um eine sichere Reproduktion
Wenn möglich, lassen Sie den Anwendungseigentümer eine nicht vertrauliche Testnachricht über den betroffenen Produktionsworkflow an einen autorisierten Testempfänger senden. Der Arbeitsablauf ist wichtig: Eine Testschaltfläche in der Anbieterkonsole kann einen anderen Absender oder eine andere Route als Rechnungen, Passwortzurücksetzungen oder geplante Benachrichtigungen verwenden.
Erfassen Sie die intern verwendete Anwendungs-, Kundenkonto- oder Mandantenreferenz, die auslösende Aktion, die UTC-Sendezeit, das vorgesehene Empfängersystem und ob eine Weiterleitung oder ein Gateway beteiligt ist. Eine Nachrichtenkennung kann dabei helfen, Protokolle zu korrelieren, sie darf jedoch nur über den vereinbarten Supportkanal weitergegeben werden. Fordern Sie keine Passwörter, privaten Signaturschlüssel, API-Anmeldeinformationen oder nicht verwandte Postfachexporte an.
Konzentrieren Sie sich bei der ersten Anfrage auf das technische Problem. Wenn es sich bei dem Fehler um die Nachricht eines echten Kunden handelt, verwenden Sie genehmigte Bearbeitungs- und Zugriffskontrollen, bevor Sie deren Inhalt mit einer anderen Partei teilen.
Bewahren Sie die Beweise, die die Identitäten unterscheiden
Fordern Sie die ursprüngliche Nachricht an, wie sie am betroffenen Ziel empfangen wurde, oder einen empfängerseitigen Diagnoseexport, der die relevanten Header beibehält. Zu den nützlichen Feldern gehören die sichtbare Absenderdomäne und die relevante Umschlagidentität, sofern verfügbar DKIM Signaturen und des empfangenden Systems Authentication-Results.
Der empfangende Bediener muss ermitteln, welches Ergebnis vertrauenswürdig ist. Allein der Kopfzeilentext kann gefälscht sein oder von einer nicht vertrauenswürdigen Quelle stammen; RFC 8601 §1.2 Und RFC 8601 §7.1 Erklären Sie die Vertrauensgrenzenanforderung. Wenn mehrere Authentication-Results Felder vorhanden sind, gehen Sie nicht davon aus, dass der oberste Durchgang automatisch autorisierend ist.
Für die erste Triage kann ein Administrator die relevanten Identitäts- und Ergebnisfelder extrahieren und gleichzeitig das Original sicher aufbewahren. Das unterscheidet sich von der kryptografischen erneuten Überprüfung DKIM . Das Bearbeiten signierter Header oder des Textes kann eine Signatur ungültig machen, sodass eine redigierte Kopie nicht unbedingt die ursprüngliche Validierung reproduzieren kann. Wenn eine unabhängige erneute Überprüfung erforderlich ist, sorgen Sie für einen kontrollierten Zugriff auf eine unveränderte Probe oder erstellen Sie einen sicheren neuen Test. Es folgt die signatursensitive Behandlung RFC 6376 §3.4 Und RFC 6376 §3.7.
Eine minimale Anfrage, die Sie anpassen können
Verwenden Sie Folgendes als operative Vorlage und nicht als Aufforderung zur Offenlegung von Anmeldeinformationen:
„Bitte senden Sie einen nicht sensiblen Test über den betroffenen Workflow und stellen Sie Folgendes bereit:
- Die Anwendung und der genaue Workflow, die Sendezeit in UTC und ob die Route eine Weiterleitung oder ein Gateway beinhaltet.
- Die ursprünglich über unseren genehmigten Supportkanal empfangene Nachricht oder die vom Empfängeradministrator extrahierte From-Domain, SPF-evaluierte Identität und Ergebnis, jedes relevante DKIM
d=Unds=Wert und Ergebnis sowie vertrauenswürdiges DMARC Ergebnis. - Die genaue Ablehnungsantwort, wenn die Zustellung fehlgeschlagen ist, einschließlich des Systems, das die Zustellung zurückgegeben hat. Wenn keine Empfängernachricht vorhanden ist, geben Sie stattdessen senderseitige Trace-Details an.
- Die von diesem spezifischen Workflow verwendeten Authentifizierungseinstellungen und die aktuellen Anweisungen des Anbieters für seine unterstützte Kundendomänenkonfiguration.
- Alle kürzlich erfolgten DNS , Schlüssel-, Gateway- oder Absenderadressenänderungen und deren Zeitstempel.
Bitte geben Sie keine Kontokennwörter, API-Schlüssel, privaten DKIM Schlüssel oder nicht verwandte Kundendatensätze an. Bewahren Sie das Originalmuster unverändert auf, falls eine Überprüfung der Unterschrift erforderlich sein sollte.“
Diese Anfrage schafft einen gemeinsamen Bezugspunkt. Es wird nicht davon ausgegangen, dass die gemeinsame Infrastruktur des Anbieters oder eine bekannte Quell-IP beweist, dass Ihre Organisation den Absender autorisiert hat.
Ordnen Sie jede Antwort einer Diagnosefrage zu
Erstellen Sie ein kleines Beweisarbeitsblatt, bevor Sie Änderungen vorschlagen.
- Beweis: Von der Domäne; Frage, die beantwortet wird: Welche Autorendomäne bewertet DMARC ?
- Nachweis: SPF Ergebnis und bewertete Domäne; Frage, die beantwortet wird: Wurde SPF als eine für diese Route relevante Identität erkannt?
- Beweis: DKIM Ergebnisse,
d=Unds=; Die Frage beantwortet: Welche Signaturidentitäten wurden überprüft und welche Schlüssel wurden verwendet? - Nachweis: Anwendbare Richtlinien und Ausrichtungsmodi; Frage, die beantwortet wird: Entspricht eine vorübergehende Identität der relevanten Regel?
- Nachweis: SMTP -Antwort oder endgültige Entscheidung; Frage, die es beantwortet: Was ist eigentlich mit der Lieferung passiert?
- Beweis: Änderungszeitstempel und aktuelle DNS Beobachtungen; Frage, die es beantwortet: Könnte der Konfigurationszeitpunkt unterschiedliche Beobachtungen erklären?
Es folgen die Identitäts- und Ausrichtungsprüfungen RFC 9989 §5.3.3, RFC 9989 §5.3.4 Und RFC 9989 §5.3.5. Das Arbeitsblatt und das Anfrageformat sind praktische Empfehlungen.
Behandeln Sie fehlende Beweise explizit
Wenn der Absender nur seinen Konsolenstatus bereitstellt, fordern Sie ein empfangenes Beispiel aus dem tatsächlichen Workflow an. Wenn ein Empfänger die Nachricht ablehnt, bevor er sie angenommen hat, bestätigen Sie, dass möglicherweise keine endgültige Postfachkopie vorhanden ist. Verwenden Sie die ausgehende Ablaufverfolgung des Absenders, die Ablehnungsantwort und die Protokolle des empfangenden Betreibers, sofern verfügbar.
Wenn der aktuelle DNS vom Zeitstempel der Nachricht abweicht, behaupten Sie nicht, dass er beweist, was der frühere Empfänger gesehen hat. Fordern Sie die Änderungshistorie oder eine frisch kontrollierte Reproduktion an. Wenn der Anbieter keine unterstützte ausgerichtete Identität anbieten kann, notieren Sie diese Fähigkeitslücke und den betroffenen Workflow, anstatt DNS Werte zu erfinden.
Beenden Sie die Untersuchung mit einem Vorher-Nachher-Identitätsvergleich, der genauen Änderung und einem neuen vertrauenswürdigen Ergebnis. Verknüpfen Sie diese Beweise mit dem Absenderbestand. Der Leitfaden für Ausrichtungsfehler hilft bei der Interpretation, während die Leitfaden zum Datenschutz bei der Berichterstattung unterstützt Entscheidungen über die Aufbewahrung von Beweismitteln.
Treffen Sie die nächste Entscheidung explizit
Wenn nur ein Konsolen-Screenshot vorhanden ist, markieren Sie die ausgewertete SPF Domäne, die ausgerichtete DKIM Identität und die Vertrauensgrenze des Empfängers als fehlend. Fragen Sie nach diesen Feldern, anstatt einen DNS Fix zu deklarieren. Wenn die Ablehnung die Postfachzustellung verhindert hat, verwenden Sie stattdessen die SMTP Antwort und die Absenderverfolgung. Zeichnen Sie den Zeitstempel jeder Beobachtung separat von einer späteren DNS Inspektion auf; Hier wurde keine Originalnachricht gesammelt oder überprüft.