Ein SPF pass kann vollkommen korrekt sein, ohne dass dabei etwas unternommen wird, um die Adresse zu authentifizieren, die Ihr Kunde sieht. Der sendende Server ist möglicherweise für die Umschlagdomäne eines Anbieters autorisiert, während der sichtbare Absender Ihre Geschäftsdomäne verwendet. DMARC fragt, ob eine bestandene Authentifizierungsidentität mit dieser Autorendomäne übereinstimmt.
Hierbei handelt es sich um ein Identitätsproblem, nicht unbedingt um ein Problem mit fehlenden IP-Adressen. Beginnen Sie mit den Domänen in der tatsächlich empfangenen Nachricht, bevor Sie SPF Berechtigungen erweitern.
Vergleichen Sie drei separate Beobachtungen
Notieren Sie die sichtbare Von-Domäne, den ausgewerteten Domänen SPF und die Domäne bei jedem Durchgang DKIM Signatur'sd= Feld. Notieren Sie das Ergebnis des Empfängers für jeden Mechanismus separat. Nicht schlussfolgern Ausrichtung von einem grünen SPF oder DKIM Abzeichen, das die ausgewertete Domäne verbirgt.
RFC 9989 Abschnitt 4.4.2 definiert SPF Ausrichtung. Für eine strikte Ausrichtung müssen die SPF und Autorendomänen genau übereinstimmen RFC 9989 §3.2.10.2. Die entspannte Ausrichtung nutzt die Organisationsdomänenerkennung in RFC 9989 §4.10.2. Es sind keine Domains zulässig, die einem Anbieter gehören, mit dem Sie einen Vertrag haben.
Ausgearbeitetes Beispiel: ein korrekter Pass ohne Ausrichtung
Das Folgende ist eine synthetische Diagnosevorrichtung, die eine anwendbare DMARC Richtlinie voraussetzt. Eine Meldung wird angezeigt: From: accounts@example.com . Es ist POST VON ist delivery@vendor.example.net . Die Verbindungs-IP ist 192.0.2.17 . Die Umschlagrichtlinie des Anbieters lautet v=spf1 ip4:192.0.2.17 -all, also geht SPF durch.
Angenommen, die Organisationsdomänen sind example.com und example.net . Sie unterscheiden sich, sodass der SPF Pfad nicht im entspannten oder strengen Modus ausgerichtet ist. Wenn DKIM auch nur mit d=vendor.example.net, stimmt keine der übergebenen Identitäten überein. DMARC fehlt daher ein weiterführender, ausgerichteter Pfad RFC 9989 §5.3.5. Hinzufügen dieser IP zu example.com SPF Eintrag ändert nichts an der Tatsache, dass diese Transaktion vendor.example.net verwendet hat.
Betrachten Sie nun einen unterstützten benutzerdefinierten Umschlag von return@bounce.example.com . Wenn SPF für bounce.example.com gilt und sowohl es als auch example.com dasselbe entdeckt haben Organisationsbereich, eine entspannte SPF Anpassung kann vergehen. Eine strikte Ausrichtung ist immer noch nicht möglich, da die Namen unterschiedlich sind. Alternativ kann eine übergebene DKIM -Signatur mit d=example.com einen ausgerichteten DKIM Pfad bereitstellen.
Wählen Sie eine unterstützte Korrektur
Fragen Sie die Dienstdokumentation oder den Administrator, ob eine benutzerdefinierte MAIL FROM-Domäne, ausgerichtetes DKIM oder beides unterstützt wird. Erhalten Sie die genauen generierten DNS Werte vom Dienst. Ein generisches SPF Include konfiguriert selbst keinen benutzerdefinierten Umschlag, und die manuelle Erstellung der Rücksendeadresse des Anbieters kann die Bounce-Verarbeitung stören.
Wählen Sie die Korrektur, die zum Arbeitsablauf und Ihrer Richtlinie passt. Eine abgestimmte DKIM Bereitstellung bietet häufig nützliche Ausfallsicherheit durch Weiterleitung, obwohl Änderungen an abgedeckten Inhalten dazu führen können, dass die Signaturen beschädigt werden RFC 6376 §3.7. Wenn Sie benutzerdefiniertes MAIL FROM verwenden, testen Sie den tatsächlichen Umschlag, nachdem der Anbieter den Abschluss der Einrichtung meldet. Produktverfügbarkeit und Konfigurationsschritte müssen für das verwendete Produkt und Konto überprüft werden.
Lockern Sie die Ausrichtung nicht, nur um eine Warnung zu entfernen, ohne die dadurch entstehende Grenze zu verstehen. Wählen Sie umgekehrt keine strikte Ausrichtung als Sicherheitsmerkmal, wenn legitime Subdomain-Absender absichtlich für eine lockere Ausrichtung konzipiert wurden. Dokumentieren Sie, warum die gewählte Identitätsbeziehung akzeptabel ist.
Testen Sie den Pfad erneut, nicht nur DNS
Senden Sie eine repräsentative Nachricht an eine Mailbox, in der Sie die Ergebnisse vertrauenswürdiger Empfänger einsehen können. Testen Sie den Benachrichtigungstyp, der fehlgeschlagen ist, da die Marketing- und Transaktionsprodukte eines Anbieters möglicherweise unterschiedliche Identitäten verwenden. Erfassen Sie den neuen Umschlag, SPF Ergebnis, DKIM Signaturdomäne und DMARC -Ergebnis.
Wenn Direktmailings funktionieren, weitergeleitete Mails jedoch nicht, untersuchen Sie diesen Weg separat. Betrachten Sie eine DNS Korrektur nicht als erfolglos, nur weil ein unabhängiger Inhaltsfilter die Nachricht dennoch in den Spam-Ordner einordnet. Authentifizierungsergebnisse und Postfachplatzierung sind unterschiedliche Ergebnisse.
Der praktische Imbiss
Eine nützliche Diagnose benennt die vorbeikommende Domäne und zeigt, warum sie übereinstimmt oder nicht. Reparieren Sie die unterstützte Absenderidentität und überprüfen Sie dann eine echte Nachricht. Umfassendere SPF Berechtigungen für die falsche Domäne können eine Ausrichtungslücke nicht schließen.
Halten Sie die Entscheidung reproduzierbar
Verwenden Sie eine Zeile pro übergebener Identität und deren Ausrichtungsmodus. Da für From= example.com nur vendor.example.net übergeben wird, markieren Sie beide Rohdurchgänge als nicht ausgerichtet, anstatt ein Ergebnis mit einer anderen Domäne zu verknüpfen. Wenn d=example.com ebenfalls überprüft, zeichnen Sie diesen separaten ausgerichteten DKIM Pfad auf. Testen Sie das benutzerdefinierte MAIL FROM-Verhalten unabhängig, auch wenn DMARC insgesamt bereits bestanden wurde.