Der Übergang zu einer Durchsetzungsrichtlinie ist eine wichtige Entscheidung zur Domänenkontrolle und nicht das Ende des E-Mail-Betrugs. Melden Sie die erreichte Grenze genau: Die Domäne fordert eine strengere Behandlung fehlgeschlagener Nachrichten DMARC. Erklären Sie dann die Bedrohungen, die sich dennoch authentifizieren oder außerhalb dieser Identitätsgrenze liegen können, sowie die operativen Maßnahmen, die erforderlich sind, um die Funktionsfähigkeit legitimer E-Mails aufrechtzuerhalten.
Geben Sie den Schutz ohne Garantie an
DMARC kombiniert eine abgestimmte Domänenauthentifizierung mit einem veröffentlichten Verarbeitungspräferenz- und Berichtsrahmen. Die tatsächliche Handhabung durch den Empfänger kann lokale Richtlinien beinhalten. Versprechen Sie nicht, dass jede fehlerhafte Nachricht überall abgelehnt wird oder dass ein Bestehen bedeutet, dass die Nachricht sicher ist. RFC 9989.
Lookalike-Domain-Nachrichten, die Nachahmung von Anzeigenamen und kompromittierte legitime Absender können auch nach der Durchsetzung gefährlich bleiben. Ein authentifizierter Lieferant kann dennoch eine nicht autorisierte Zahlungsanforderung senden. SPF Eine weiter gefasste Genehmigung als vorgesehen kann auch dazu führen, dass ein ausgerichteter Überholweg zur Verfügung steht. Dies sind Gründe, ergänzende Kontrollen beizubehalten, keine Gründe, die Domänenauthentifizierung aufzugeben.
Überprüfen Sie vor der Änderung legitime Routen
Pflegen Sie eine Absender-für-Absender-Matrix mit dem Dienst, dem verantwortlichen Eigentümer, der Autorendomäne, den authentifizierten Domänen usw. Ausrichtung Beweise, kritische Empfänger und Datum der letzten Prüfung. Beziehen Sie Systeme mit geringem Volumen wie Scanner und Alarme ein. Eine ruhige Strecke ist nicht zwangsläufig ungenutzt. Klären Sie unbekannte Absender auf, bevor Sie das Inventar als vollständig betrachten.
Dokumentieren Sie den vorgeschlagenen Richtlinienunterschied und wer ihn genehmigt. Eine Abwechslung von p=none Zu p=reject ist ein Beispiel, kein Wert, den man blind veröffentlichen kann. Überprüfen Sie die anwendbaren Domänen und Abhängigkeiten, planen Sie das Beobachtungsfenster und definieren Sie Wiederherstellungsauslöser für wichtige legitime Fehler. Verwenden Sie generierte dienstspezifische Werte anstelle der Demonstrationsidentitäten dieses Artikels.
Untersuchen Sie ein schriftliches Bereitschaftsbuch
Gehen Sie für die unten vorgeschlagene Änderung p=none zu p=reject von einem einzigen gültigen sichtbaren Absender pro Nachricht und einem festgelegten Empfängerauthentifizierungsnachweis aus. Es wird keine tatsächliche Änderung oder ein Empfängertest durchgeführt.
- Abrechnung: vorgeschlagener Eigentümer Billing Operations; invoice@billing.brand.test ; SPF -Pass für bounce@billing.brand.test ; DKIM Bestehen mit d=billing.brand.test. Beide Bezeichner stimmen genau überein, sodass die hypothetische Nachricht durchgelassen wird. Echte kritische Empfängertests und Änderungsgenehmigungen bleiben nicht vorgesehen.
- Support: vorgeschlagener Eigentümer Support Operations; Von agent@support.brand.test ; SPF -Pass für bounce@support.brand.test ; DKIM -Bestanden mit d=support.brand.test. Beide stimmen genau überein, sodass die hypothetische Nachricht durchgeht. Echte kritische Empfängertests und Änderungsgenehmigungen bleiben nicht vorgesehen.
- Legacy-Scanner: Besitzer unbestätigt; Von, SPF , DKIM und Empfängerabdeckung unbekannt. Es kann kein Nachrichtenurteil abgeleitet werden. Benennen Sie einen verantwortlichen Eigentümer und holen Sie einen Streckennachweis ein, bevor Sie die Bereitschaft erklären.
Die allgemeine Rollout-Bereitschaft ist nicht gegeben. Auch die beiden vorgeschriebenen Durchgänge gelten nicht als Produktionsbeweis. Der vorgeschlagene Änderungseigentümer sollte die Änderung zurückhalten, bis Unbekannte, Genehmigungen, Wiederherstellungsauslöser und Routenprüfungen behoben sind. Für dieses Ledger wurde keine Code-, DNS Abfrage- oder Signaturüberprüfung durchgeführt.
RFC9989 Abschnitt 7.4 erfordert gültige DKIM Signaturen beim Veröffentlichen von p=reject und rät von der Ablehnung für Domänen ab, deren Benutzer möglicherweise auf Mailinglisten posten. Diese Domänen sollten dann zunächst mindestens einen Monat lang aggregierte Daten mit p=none bewerten p=quarantine für einen ebenso langen Zeitraum. Wählen Sie die Richtlinie unter Berücksichtigung dieser Interoperabilitätseinschränkungen aus. Ein sauberes Direktversand-Beispiel beseitigt nicht das Risiko indirekter E-Mails.
Überprüfen Sie das Verhalten nach einem genehmigten Rollout
Erfassen Sie bei einer echten Änderung die veröffentlichte Richtlinie, die Zeit, den genehmigten Unterschied und die Tests für jede kritische Route. Vergleichen Sie die Ergebnisse vertrauenswürdiger Empfänger mit der tatsächlichen Abwicklung und überprüfen Sie die verfügbaren aggregierten Berichte mit ihren Abdeckungsgrenzen. Fehlende Berichte sind kein Beweis dafür, dass keine E-Mail gesendet wurde oder kein Fehler aufgetreten ist. RFC 9990. Untersuchen Sie legitime Ausnahmen nach Route, anstatt den Schutz ohne Eigentümer umfassend zu schwächen.
Erläutern Sie das verbleibende Betrugsrisiko in denselben Geschäftsbegriffen, die Sie vor der Durchsetzung verwendet haben. Zahlungsänderungen bedürfen weiterhin einer unabhängigen Überprüfung; Eine Kontokompromittierung erfordert weiterhin eine Reaktion der Kontosicherheit. Doppelgänger erfordern eine Erkennung und eine entsprechende Berichterstattung. Die Richtlinien des FBI zur Zahlungsüberprüfung bleiben auch dann relevant, wenn die Domain authentifiziert wird. FBI-Anleitung.
Eine solide Abschlusserklärung benennt die beobachtete Richtlinie, getestete Routen, ungelöste Ausnahmen und verbleibende Kontrollen. Es sollte nicht sagen Phishing ist gelöst. Halten Sie die Eigentümerschaft und regelmäßige Überprüfung aktiv, wenn sich Dienste, Schlüssel und Geschäftsprozesse ändern.