Alle Angebote richten sich an Gewerbetreibende, nicht an Endverbraucher und verstehen sich zzgl. MwSt.
© 2024 nicmanager.com. Alle Rechte vorbehalten.
© 2024 nicmanager.com. Alle Rechte vorbehalten.
SPF-Einträge können recht einfach sein (v = spf1 a-all), sie können jedoch auch recht komplex sein, um die Vielzahl der im Internet vorhandenen Konfigurationen für Postausgangsserver zu berücksichtigen. Dabei scheinen besonders SPF-Neulinge beim Erstellen ihres ersten SPF-Datensatzes häufig ähnliche Fehler zu machen. Im Allgemeinen sollten Sie auf die folgenden Punkte achten.
Der Zweck von SPF besteht darin, die Mailserver Ihrer Domain zu bewerben. Oft hilft es, vor dem Start eine Liste zu erstellen. Überlegen Sie, ob eine der folgenden Optionen zum Senden von E-Mails verwendet wird:
Nur der letzte Mailserver ist dabei relevant. Denn wenn in Ihrem Unternehmen die Einrichtung komplizierter ist und ein interner Mailserver E-Mails über einen Postausgangsserver an die Welt weiterleitet, wird in SPF nur der Postausgangsserver aufgeführt.
Zu einem bestimmten Zeitpunkt erfasst AOL den ausgehenden SMTP-Verkehr (Port 25) von seinen Benutzern und fängt die Nachrichten transparent ab und leitet sie über die Postausgangsserver von AOL weiter. Somit würden alle AOL-Benutzer E-Mails über die Mail-Server von AOL senden, ob sie dies nun wollen oder nicht. Die Verwendung eines alternativen Ports wie Port 587 kann dabei Abhilfe schaffen, wenn Ihr Hosting-Unternehmen dies unterstützt.
Möglicherweise haben Sie mehr als nur eine Domain. Doch auch sollten Sie vorsichtig sein, da auch nicht von Ihnen genutzte Domains von Spammern missbraucht werden können! Sehen Sie dazu auch die Veröffentlichung von SPF-Nulldatensätzen für ...
Letztendlich werden SPF-Lookups in eine IP-Adresse aufgelöst. Es ist deshalb nicht erforderlich, denselben Server unter Verwendung mehrerer Hostnamen aufzulisten (z. B. werden "example.com" und "www.example.com", beide in dieselbe IP aufgelöst). Tatsächlich ist dies jedoch auf Ihren DNS-Servern etwas schwieriger, da ein empfangender Server, der Ihren Datensatz durchläuft, möglicherweise gezwungen ist, mehrere DNS-Lookups durchzuführen, wenn lediglich ein einmaliger Verweis auf den Hostnamen des Servers ausreichend gewesen wäre.
Wenn sich die IP-Adresse des Servers selten ändert, sollten Sie die Schreibweise ip4: x.x.x.x (oder ip6) verwenden, damit die Empfänger DNS-Lookups vollständig vermeiden können. Da es ein Limit von 10 DNS-Suchvorgängen pro SPF-Eintrag gibt, ist die Angabe einer IP-Adresse oder eines Adressbereichs für lange Listen ausgehender Mailserver vorzuziehen. Oft aber kann ein SPF-Datensatz auf etwas wie v = spf1 ip4: x.x.x.x -all komprimiert werden, wenn nur ein Postausgangsserver vorhanden ist.
Der Zweck von SPF besteht darin, eine Liste der Postausgangsserver zu veröffentlichen. Alle Server, die keine E-Mails an die Welt senden, z. B. Webserver oder reine Posteingangsserver, sollten daher nicht aufgelistet werden.
Manchmal ist es bei Verwendung von Konfigurationshilfen einfach, den mx-Mechanismus hinzuzufügen. Da MX-Einträge jedoch zum Weiterleiten von eingehenden E-Mails für Ihre Organisation verwendet werden, werden möglicherweise dieselben Server für ausgehende E-Mails verwendet oder auch nicht. Sollte die IP-Adresse Ihres ausgehenden Servers durch einen a-, ip4- oder anderen Mechanismus abgedeckt sein, muss dieser Server nicht erneut mit dem mx-Mechanismus referenziert werden (siehe Server nur einmal oben auflisten). Wenn die in Ihren MX-Einträgen aufgelisteten Server jedoch nur für eingehende E-Mails verwendet werden, muss der MX-Mechanismus nicht verwendet werden.
Die Angabe von mx: mailserver.example.com ist im Allgemeinen falsch, es sei denn, Sie möchten mit der SPF-Überprüfung wirklich alle Hosts ermitteln, die E-Mails für die Domäne "mailserver.example.com" akzeptieren. (Normalerweise wird es keine solchen Hosts geben, da "mailserver.example.com" selbst ein Host ist, keine Domain.) Dies wird allerdings nicht als Syntaxfehler angezeigt, sondern es wird einfach nichts gefunden. Die korrekte Verwendung für die Überprüfung anhand der MX-Datensätze für "example.com" lautet mx: example.com, oder wenn Sie den Hostnamen oder die IP eines bestimmten Mailservers angeben möchten, a: mailserver.example.com oder ip4: x.x.x.x.
Beachten Sie schließlich, dass "example.com" die Standarddomäne für die Regel ist, wenn Ihre SPF-Regel als mit "example.com" verknüpfter DNS-Eintrag gespeichert ist. Daher ist mx allein (ohne Angabe einer expliziten Domäne) ausreichend, um die Absender-IP mit allen MX-Mail-Hosts zu vergleichen, die in diesem Kontext für "example.com" aufgeführt sind. Seit 2008 macht es der SenderID-Assistent einem leicht, dies falsch zu verstehen. Wenn z.B. die Befehle "dig -tmx mailserver.example.com" oder "nslookup -q = mx mailserver.example.com" nichts ergeben, verschwendet die Verwendung von "mx: mailserver.example.com" die Bandbreite der Empfänger, die den SPF überprüfen, sowie die Bandbreite Ihrer eigenen Nameserver, die dann sinnlose Fragen beantworten.
Wenn Sie E-Mails für andere hosten, erstellen Sie keinen SPF-Datensatz für einen Kunden, ohne zu untersuchen, welche E-Mail-Server dieser Kunde verwendet, denn möglicherweise haben Sie den Postausgang Ihres Kunden von seinem internen Mailserver oder von den Endbenutzern, die E-Mails über den Mailserver ihres Internetdienstanbieters zu Hause senden, blockiert oder behindert. Beachten Sie hier die Hinweise für ISPs, um sicherzugehen.
Angenommen, Sie möchten die Postausgangsserver Ihres Webhosting-Unternehmens in Ihren SPF-Datensatz aufnehmen. Außerdem hostet Network Solutions Ihre Website und Ihre E-Mail. Möglicherweise sind Sie versucht, Folgendes zu verwenden: networksolutions.com in Ihrem SPF-Datensatz. Dann werden Sie vielleicht dazu verleitet Folgendes in Ihrem Datensatz zu verwenden: networksolutions.com. Dies kann jedoch zu zwei Problemen führen.
Erstens wenn zum jetzigen Zeitpunkt Network Solutions keinen SPF-Eintrag für die Domäne networksolutions.com. veröffentlicht und Sie aber include: networksolutions.com verwenden, wird Ihr Datensatz sofort ungültig.
Das andere Problem ist subtiler: include: networksolutions.com würde auch Mailserver miteinschließen, die zum Senden von E-Mails über die Domain networksolutions.com berechtigt sind. Dies kann also die gleiche Liste von Mailservern sein, die Network Solutions zum Versenden von E-Mails über Kundendomänen verwendet. Manchmal erstellt ein ISP einen speziellen SPF-Datensatz, den Kunden in ihren Datensatz aufnehmen können, z. B. _spf.example.com.
Wenn Sie also die Mailserver eines ISP verwenden möchten, sollten Sie ihn fragen, ob er einen SPF-Datensatz für seine Kunden verwaltet. Andernfalls müssen Sie Ihren Datensatz jedes Mal ändern, wenn Ihr ISP einen Mailserver hinzufügt, entfernt oder den Name und / oder die Adresse ändert.
Das Überprüfen von HELO / EHLO-Namen wird vom SPF-RFC empfohlen. Das Veröffentlichen von Datensätzen für diese Hostnamen ist also ein wichtiger Bestandteil des SPF-Protokolls. HELO oder auch seine moderne Version EHLO wird verwendet, wenn eine Mail von ... ist, auch wenn ein Empfänger keine 100% HELO-Prüfung durchführt. Zum Veröffentlichen einer HELO-Regel wird für gewöhnlich ein SPF-Datensatz erstellt, der mit dem von Ihrem Mailserver verwendeten HELO-FQDN verknüpft ist (Beispiel: "mailserver.example.com").
Normalerweise sollte dies eine völlig andere SPF-Regel sein, als die, welche die Absenderadressen in Ihrer Domain überprüft, die möglicherweise mit "example.com" verknüpft sind. Ein einfaches Beispiel für zwei Richtlinien könnte sein: example.com. IN TXT "v=spf1 mx -all" mailserver.example.com. IN TXT "v=spf1 a -all" Die erste Regel würde von jeder Adresse aktiviert werden, die mit "@ example.com" endet, und würde eine solche E-Mail nur dann validieren, wenn sie von einer IP-Adresse stammt, die einem MX-Eintrag für "example.com" zugeordnet ist.
Die zweite Regel würde durch eine HELO-Identifikation von "mailserver.example.com" aktiviert werden und würde die E-Mail nur dann validieren, wenn sie von einer auf diesem Server zugeordneten IP-Adresse stammt. Ein weiterer Grund, um HELO-Namen zu berücksichtigen, liegt in der Veröffentlichung von Null-SPF-Einträgen für Ihre Domains, die keine E-Mails senden. Angenommen, Sie befolgen die Hinweise in dieser FAQ, denken jedoch nicht an die HELO-Namen. Dann könnten Sie Servern damit versehentlich das Recht verweigern, E-Mails zu senden.
Ein Beispiel dafür wäre eine Wolke von Webservern, welche E-Mail-Formulare sendet, mit "webform@example.com" als Absenderadresse. Jeder dieser Webserver verwendet (wie er es soll) seinen eigenen Namen als HELO-Parameter.
Wenn Sie Ihre E-Mail-Sendedomänen mit SPF geschützt haben und jemand versucht, sie zu fälschen, dann würde er als erstes versuchen, Ihre Nicht-E-Mail-Sendedomänen zu fälschen. Das Veröffentlichen von "v = spf1 -all" besagt, dass eine Domain keine Mail sendet. Als Beispiel könnten Sie veröffentlichen:
Verwenden Sie ein Testwerkzeug, um einen neuen SPF-Datensatz zu testen.
SPF basiert auf DNS-Lookups. Damit also die Welt Ihren SPF-Eintrag findet, müssen Sie ihn auch auf dem richtigen DNS-Server erstellen. Wenn Sie nicht genau wissen, welche/r (Haupt-) DNS-Server für Ihre Domain "maßgebend" sind, überprüfen Sie Ihre Domain einfach mit "whois" oder fragen Sie Ihr Webhosting-Unternehmen.
Denken Sie daran, dass Sie, wenn Sie ein Testdienstprogramm verwenden, um Ihren SPF-Eintrag in DNS nachzuschlagen, warten müssen, bis dessen TTL (Time to Live) abläuft und sich die Änderung in der Welt verbreitet, bevor das Dienstprogramm die Änderungen erkennt. Oft ist es aber einfacher, Ihren SPF-Datensatz in das Dienstprogramm einzufügen, um Ihre Änderungen sofort sichtbar werden zu lassen.
Vergessen Sie nicht, den Personen Anweisungen zu geben, die E-Mails mit der soeben geschützten Domain senden müssen. Möglicherweise müssen sie SMTP AUTH in ihrem E-Mail-Client konfigurieren und sie brauchen möglicherweise ein Login und ein Passwort. Wenn das Senden von Hotel-PCs (oder was auch immer) jetzt verboten ist, müssen sie darüber Bescheid wissen.