A DMARC Rollback sollte die beabsichtigte Kommunikation wiederherstellen und gleichzeitig die Beweise bewahren, die zur Erklärung des Geschehens erforderlich sind. Das Bearbeiten des Datensatzes ist nur ein Teil dieser Aufgabe. Das Team muss außerdem wissen, welcher legitime Dienst fehlgeschlagen ist, welche Richtlinie ein Empfänger gesehen haben könnte und was einen weiteren Versuch rechtfertigt.
Bereiten Sie diesen Wiederherstellungspfad vor der Änderung vor. Wenn ein Vorfall eintrifft, sind ein vorheriger Wert, ein benannter Eigentümer und ein getesteter Genehmigungsweg nützlicher als eine improvisierte Suche anhand von Screenshots.
Notieren Sie den Zustand, der möglicherweise wiederhergestellt werden muss
Speichern Sie den vollständigen Datensatz unter dem genauen Namen des betroffenen DNS Besitzers, zusammen mit seiner TTL, den autorisierenden Servern und der Erfassungszeit. Behalten Sie die geltenden übergeordneten und Subdomain-Richtlinien bei, wenn sie für die Erkennung wichtig sind. Ein kopierter p-Wert allein kann Meldeadressen oder weglassen Ausrichtung Einstellungen, die gleichzeitig geändert wurden.
Behalten Sie die genehmigte Änderung als lesbares Diff bei. Identifizieren Sie den Zweck jedes geänderten Tags und die autorisierte Person, die die vorherige Konfiguration wiederherstellen kann. Rezension Erkennung von Subdomain-Richtlinien Bevor Sie davon ausgehen, dass sich durch die Bearbeitung eines Elterndatensatzes die Beurteilung jedes Kindes ändert.
Speichern Sie DNS Verwaltungsnachweise getrennt von sensiblen Nachrichtenproben. Für beide ist ein entsprechender Zugriff erforderlich, ein Vorfallprotokoll muss jedoch nicht den vertraulichen Inhalt eines Kunden wiedergeben.
Definieren Sie einen Auslöser, der Fehler von Verdacht unterscheidet
Wählen Sie konkrete Rollback-Kriterien für die Änderung: zum Beispiel eine überprüfte Ablehnung eines kritischen legitimen Flusses, der auf die neue Richtlinie zurückzuführen ist, und die Unfähigkeit, diesen Fluss innerhalb des vereinbarten Reaktionsfensters zu reparieren.
Allein eine Support-Beschwerde löst eine Untersuchung aus; DMARC wird nicht als Ursache nachgewiesen. Erfassen Sie den vollständigen zurückgegebenen SMTP Text, Dienst und Konto, Uhrzeit, Empfängerdomäne, sichtbare Absenderdomäne und verfügbare Sendeprotokolle. Bewahren Sie für zugestellte E-Mails eine repräsentative Originalnachricht und die Authentifizierungsergebnisse des vertrauenswürdigen Empfängers auf RFC 8601 §7.1.
Eine niedrige Gesamterfolgsquote allein erfordert auch einen Kontext. Nicht autorisierter Datenverkehr kann während einer fehlerfreien Bereitstellung fehlschlagen. Fragen Sie, welcher legitime Geschäftsweg betroffen ist, bevor Sie die Politik schwächen.
Trennen Sie eine Absenderreparatur von einer Richtlinienwiederherstellung
Wenn eine Anwendung eine falsche Signaturidentität aufweist, kann eine unterstützte Anwendungskorrektur die geeignete Wiederherstellung sein. Wenn die umfassende Richtlinienänderung Konsequenzen hat, stellen Sie die genehmigte frühere Richtlinie wieder her, während der Antrag untersucht wird.
Vermeiden Sie Veränderungen SPF, DKIM, DMARC und die sendende Plattform gleichzeitig, es sei denn, der Vorfall erfordert dies und jede Änderung wird aufgezeichnet. Mehrere gleichzeitige Bearbeitungen erschweren die Zuordnung von Verbesserungen oder Fehlern.
Durch das Wiederherstellen der Richtlinie wird der zugrunde liegende Authentifizierungs- oder Ausrichtungsfehler nicht behoben. Halten Sie diesen Mangel mit einem Eigentümer, Beweisen und einer Anforderung zur erneuten Prüfung offen.
Üben Sie eine kontrollierte Wiederherstellung
Diese fiktive Übung veranschaulicht das Führen von Aufzeichnungen und keinen tatsächlichen Produktionstest:
- Zeit: 10:00 UTC; Ereignis: Genehmigte Richtlinienänderungen von „Keine“ in „Quarantäne“; Beweissicherung: Vollständige alte und neue Rekordsätze, TTL und Genehmigung
- Zeit: 10:08 UTC; Ereignis: Rechnungsworkflow erhält eine richtlinienbezogene Ablehnung; Beweissicherung: Zurückgesendete Antwort, sendende Konto- und Nachrichten-IDs
- Zeit: 10:13 UTC; Ereignis: Eigentümer des Vorfalls genehmigt die geplante Wiederherstellung; Beweissicherung: Entscheidung und betroffener Umfang
- Zeit: 10:16 UTC; Ereignis: Früherer vollständiger DMARC Wert unter demselben Besitzernamen wiederhergestellt; Beweissicherung: Autorisierende DNS Antwort und Änderungsbeleg
- Zeit: 10:26 UTC; Ereignis: Ein kontrollierter Rechnungswiederholungsversuch wird bei einem Testempfänger akzeptiert; Beweissicherung: Neues SMTP Ergebnis und erhaltener Authentifizierungsnachweis
Die letzte Zeile zeigt diesen bestimmten Wiederholungsversuch über diese Route. Es beweist nicht, dass jeder Empfänger eine zuvor zwischengespeicherte Antwort verworfen hat oder dass alle Kundennachrichten wiederhergestellt wurden.
Üben Sie während einer Probe den realen Verwaltungs- und Genehmigungsweg in einer geeigneten Testumgebung. Notieren Sie, wer die Änderung vornehmen kann und was passiert, wenn diese Person oder DNS Anbieter nicht verfügbar ist.
Erwarten Sie, dass sich DNS Ansichten und Berichtszeiträume überschneiden
Ein Resolver kann eine frühere DNS Antwort beibehalten; RFC 8767 §4 erlaubt die qualifizierte Verwendung veralteter Antworten über den TTL-Ablauf hinaus, daher ist die TTL keine garantierte globale Entfernungsfrist. Das Verringern einer TTL, nachdem ein Resolver eine frühere, langlebigere Antwort zwischengespeichert hat, verkürzt nicht rückwirkend die verbleibende Cache-Lebensdauer dieser Antwort.
Fragen Sie nach der Wiederherstellung des Datensatzes die autorisierenden Server und relevanten rekursiven Ansichten ab und testen Sie dann die betroffene E-Mail-Route erneut. Eine neue maßgebliche Antwort beweist die aktuellen Daten der Zone; Es beweist nicht, was jeder Fernempfänger derzeit verwendet.
Halten Sie die Berichterstattung aktiv, wo es angebracht ist. RFC 9990 §3.3 erklärt, dass eine Richtlinienänderung innerhalb eines Berichtszeitraums zu einem Bericht führen kann, in dem Bestimmungen unter verschiedenen Richtlinienversionen kombiniert werden. Einige Implementierungen können stattdessen mehrere Berichte erzeugen. Kommentieren Sie die Zeitleiste des Vorfalls, anstatt ein einzelnes Richtlinienfeld als Beweis dafür zu betrachten, dass jede Nachricht im betreffenden Zeitraum genau diese Version verwendet hat.
Stellen Sie eine vollständige, gültige Konfiguration wieder her
Verwenden Sie den genauen Namen des vorgesehenen Eigentümers und gleichen Sie den vorhandenen Datensatz ab. Unter RFC 9989 §4.10, fügen Sie neben der ersten keine zweite DMARC Richtlinie hinzu, um diese zu überschreiben. Behalten Sie die genehmigten Berichtsziele und alle erforderlichen Genehmigungen für externe Ziele bei RFC 9990 §4 es sei denn, die Wiederherstellung ändert sie explizit.
Überprüfen Sie die gesamte resultierende Richtlinie auf unbeabsichtigte Änderungen. Eine Wiederherstellung, die die Ausrichtung oder den Subdomain-Bereich stillschweigend ändert, ist eine neue Richtlinienentscheidung und nicht nur eine Wiederherstellung.
Verwenden den Datensatz-Workflow zur Veröffentlichung und der Reporting-Leitfaden für die Interpretation der nachfolgenden Beweise.
Schließen Sie Wiederherstellung und Behebung getrennt ab
Die Wiederherstellung erfolgt, wenn die definierten betroffenen Arbeitsabläufe die vereinbarten Tests bestehen und die Konfiguration innerhalb ihrer bekannten Grenzen überprüft wird. Die Behebung wird erst abgeschlossen, wenn die Ursache verstanden und die Senderoute korrigiert oder die beabsichtigte Richtlinie überdacht wurde.
Die nächste Änderung sollte die fehlenden Beweise umfassen, die zum Scheitern des ersten Versuchs geführt haben. Die Interoperabilitätsleitlinien in RFC 9989 §7.4 bedeutet auch, dass die Ablehnung möglicherweise für eine allgemeine Mitarbeiterdomäne ungeeignet ist. Eine fehlgeschlagene Änderung kann zeigen, dass die vorgeschlagene Richtlinie selbst einer anderen Entscheidung bedarf.
Bewahren Sie die ursprünglichen Beweise, das fehlgeschlagene Ergebnis, die Wiederherstellungsentscheidung und den erfolgreichen Wiederholungstest zusammen auf. Diese Spur beschleunigt die nächste Genehmigung, da sie erklärt, was sich geändert hat, was wiederhergestellt wurde und was noch ungelöst ist.
Halten Sie die nächste Aktion spezifisch
In der fiktiven Zeitleiste ist die Annahme um 10:26 Uhr eine Wiederherstellungsbeobachtung und kein Beweis dafür, dass der Authentifizierungsfehler behoben wurde. Lassen Sie das Element „sender-remediation“ geöffnet und vergleichen Sie die tatsächlichen Ergebnisse der neuen Methode separat. Der 26-Minuten-Zeitplan ist kein Erholungsversprechen oder empfohlenes Warteintervall. Für diesen Artikel wurde keine DNS Wiederherstellung, Autorisierung oder Nachrichtenwiederholung durchgeführt.