Ein SPF Das Einschließen eines gemeinsamen E-Mail-Dienstes kann die von vielen Kunden genutzte Infrastruktur autorisieren. Oft ist der Dienst so konzipiert, aber die Erlaubnis verdient eine klare Erklärung. SPF prüft einen verbindenden Host anhand einer Domänenrichtlinie. Eine weitgehend positive Übereinstimmung ist kein mandantenspezifischer kryptografischer Berechtigungsnachweis.
Die praktische Frage ist, ob Ihr Provider verhindert, dass ein anderer Kunde mit Ihrer SMTP Identität sendet, und ob die Richtlinie nur die Infrastrukturberechtigungen gewährt, die Sie tatsächlich benötigen.
Ordnen Sie die Vertrauensbeziehung zu
Notieren Sie für jeden eingeschlossenen oder freigegebenen IP-Bereich den Dienst, den Geschäftsinhaber, die unterstützte Umschlagdomäne und die dokumentierte Anbietereinrichtung. Bestimmen Sie, ob Ihre E-Mails eine anbietereigene Umschlagdomäne oder eine von Ihnen kontrollierte benutzerdefinierte Domäne verwenden. Wenn der Anbieter Eigentümer der tatsächlich ausgewerteten Domäne ist, hat das Hinzufügen eines Include zu Ihrer Stammdomäne möglicherweise keinerlei Auswirkungen auf das SPF Ergebnis dieser Nachricht.
Lesen Sie die aktuelle Dokumentation des Anbieters zur Domainverifizierung und Absenderkontrolle. Wenn die Dokumentation unklar ist, identifizieren Sie die Frage an den Serviceeigentümer oder den Anbietersupport. Behaupten Sie nicht, dass alle Mieter isoliert sind, nur weil ein Test Ihres eigenen Kontos erfolgreich ist.
Verstehen Sie die Grenzen einer IP-basierten Entscheidung
RFC 7208 §11.4 beschreibt benutzerübergreifende Fälschungsrisiken, bei denen ein gemeinsames System es Benutzern ermöglicht, die Identität anderer Benutzer zu beanspruchen. Ein SPF Pass kann feststellen, dass der verbindende Host für die ausgewertete Domäne autorisiert ist, ohne nachzuweisen, welches Kundenkonto die Nachricht initiiert hat. Die anbieterseitige Durchsetzung ist daher Teil der Sicherheitsgrenze.
Dies bedeutet nicht, dass jeder gemeinsam genutzte Dienst unsicher ist. Das bedeutet, dass das Autorisierungsmodell zwei Ebenen hat: DNS gewährt der Infrastruktur Berechtigungen und der Dienst muss einschränken, wie Kunden Identitäten in dieser Infrastruktur verwenden. Beweise für eine Schicht sollten nicht als Beweis für die andere präsentiert werden.
Wählen Sie die schmalste unterstützte Konfiguration
Bevorzugen Sie die genaue Include- oder Domänenkonfiguration, die der Anbieter für Ihr sendendes Produkt und Ihre Region unterstützt, in der solche Unterscheidungen dokumentiert sind. Vermeiden Sie es, die gesamte Netzwerkzuteilung eines Anbieters hinzuzufügen, wenn eine enger gefasste Richtlinie verfügbar ist. Erfinden Sie keine engeren Einbindungen und ersetzen Sie keine vom Anbieter verwalteten Richtlinien durch einen Snapshot von IPs, es sei denn, Sie können dieses Design sicher beibehalten.
Ein engagierter Rückweg Eine Subdomain kann SPF Richtlinie eines Dienstes von anderen E-Mails trennen. Es verbessert das Eigentums- und Lebenszyklusmanagement, beweist jedoch nicht allein die Isolation zwischen Kunden, die den Anbieter gemeinsam nutzen. Überprüfen Sie andere Authentifizierungs- und Kontokontrollen als separate Teile des Designs.
Vergleichen Sie zwei Konfigurationen sorgfältig
Anschauliches Beispiel: v=spf1 ip4:192.0.2.0/24 -all autorisiert jede IPv4 -Adresse in diesem Dokumentationsnetzwerk für die ausgewertete Identität. Nur eine Richtlinienbenennung ip4:192.0.2.10 Autorisiert eine Adresse. Die engere Richtlinie reduziert den Quellensatz, ist jedoch nur dann sinnvoll, wenn der Anbieter diese Adresse tatsächlich für Ihren Dienst garantiert. Eine nicht unterstützte Einschränkung kann die legitime Zustellung während eines Failovers unterbrechen.
Unter RFC 7208 §5.2, ein Include wertet eine referenzierte Richtlinie aus; Bei der aktuellen Erweiterung handelt es sich um eine Beobachtung, nicht um einen dauerhaften Vertrag. Sie kann sich ändern, wenn der Anbieter seine Richtlinien ändert. Erfassen Sie die Abhängigkeit und den Besitz, anstatt die heute gelösten Adressen als die endgültige Wahrheit zu betrachten.
Überprüfen Sie, ohne andere Mieter zu testen
Nutzen Sie zur Validierung Ihre eigenen autorisierten Konten und kontrollierten Empfänger. Bestätigen Sie Ihre erwarteten Identitäten und notieren Sie, welche Infrastruktur den Pass erstellt. Bewerten Sie Mietereinschränkungen anhand von Dokumentation, genehmigten Konfigurationsnachweisen oder einem ausdrücklich autorisierten Sicherheitstest. Versuchen Sie nicht, sich als Domäne eines anderen Kunden auszugeben, um ein theoretisches Anliegen zu demonstrieren.
Überwachen Sie neue Funktionen, ungewöhnlich breite Netzwerkbereiche und Dienste ohne Eigentümer. Bei einer Richtlinienüberprüfung sollten auch rekursive Auswertungsgrenzen überprüft werden, da mehrere gemeinsam genutzte Anbieter ein Ressourcenproblem verursachen können, selbst wenn jedes Include einzeln legitim ist.
Machen Sie die Annahmeentscheidung explizit
Führen Sie eine kurze Aufzeichnung der erteilten Infrastrukturgenehmigung, der anbieterseitigen Identitätskontrollen, bekannter Beweislücken und des verantwortlichen Eigentümers. Planen Sie eine Überprüfung, wenn sich der Anbieter oder die Dienstkonfiguration ändert. Die Akzeptanz einer gemeinsamen Infrastruktur kann sinnvoll sein, die Entscheidung sollte jedoch auf dem vollständigen Vertrauensmodell und nicht nur auf einem grünen SPF Abzeichen beruhen.
Notieren Sie die nächste Entscheidung
Verwenden Sie zwei Beweiszeilen: Infrastrukturberechtigung (tatsächliche Richtlinie, Umschlagdomäne und beobachtete Quelle) und Mandantenkontrolle (dokumentierte Überprüfung/Durchsetzung, Konfigurationsnachweise und ungelöste Lücken). Ihr eigenes erfolgreiches SPF Ergebnis füllt nur die erste Zeile. Wenn der Anbieter eine engere Adresse nicht garantiert, betrachten Sie eine nicht unterstützte Einschränkung nicht als verifizierte Sicherheitsverbesserung. Es wurde kein mandantenübergreifender Test oder Anbieterwechsel durchgeführt.