Häufig gestellte Fragen

Was ist hier die Idee?

Domains veröffentlichen bereits MX Einträge, um der Welt zu sagen, welche Maschinen für diese Domain Mails empfangen.

Domains können jetzt auch den "umgekehrten MX" Eintrag veröffentlichen, um bekanntzugeben, welche Maschinen im Internet aus dieser Domain Mails senden.

Jeder kann dann diese Einträge überprüfen, um sicherzustellen, dass eine Email nicht verfälscht ist.

Mit SPF sind diese "umgekehrten MX" Einträge sehr einfach zu veröffentlichen: Eine Zeile im DNS reicht aus.

Hm, eine Zeile? Wie schaut die denn aus?

Hier sind drei Beispiele.

    vanitydomain.com  IN TXT  "v=spf1   mx  -all"
         hotmail.com  IN TXT  "v=spf1  ptr  -all"
           pobox.com  IN TXT  "v=spf1 a mx  ?all"

Wie funktioniert das?

Nehmen wir an ein Spammer versucht dir ein Spam mit der gefälschten Absenderadresse von hotmail.com zu schicken.

Er verbindet sich mit deinem Mailserver von einer beliebigen IP Adresse aus.

Wenn er sich nun mit MAIL FROM: <gefaelschte_adresse@hotmail.com> vorstellt, musst du ihn nicht gleich glauben. Du kannst Hotmail fragen, ob diese IP Adresse von ihren Netz stammt.

Nehmen wir beispielhaft an, Hotmail veröffentlich bereits SPF Einträge im DNS. Der Eintrag sagt dir, wie man herausfinden kann, ob eine IP Adresse zu deren Netz gehört.

         hotmail.com  IN TXT  "v=spf1  ptr  -all"

Du rufst dabei den "ptr" Mechanismus auf, und der bedeutet: Finde den Hostnamen der IP Adresse raus; wenn er mit hotmail.com endet, ist er gültig.

Wenn der SPF-Test nicht bestanden wird, ist die Absenderadresse gefälscht. Damit kann man sagen, dass die Email vermutlich von einem Spammer stammt.

Aber verifizierst du die PTR Antwort?

Ja, der Hostname, der von PTR zurückgegeben wird muss auch zurück auf die IP Adresse verweisen. Das ist eine übliche Vorgehensweise.

Aber damit ist die Weiterleitung (Forwarding) kaputt!

Ja, das stimmt. Man muss dann von der Weiterleitung abkommen, wo der Absender (im SMTP-Dialog) bestehenbleibt, und stattdessen eine neue Weiterleitung, wo die Absenderinformation (Envelope-From) angepasst wird. Aber keine Sorge, wir arbeiten an SRS Fähigkeiten für die 4 grossen Opensource Mailserver, so dass das Problem mit einem Upgrade auf eine Version mit SPF Unterstützung das Problem lösen wird.

Wenn deine Weiterleitung über ein kommerziellen Anbieter wir pobox.com läuft, brauchst du wahrscheinlich gar nichts zu tun. Sie müssen mit der Zeit gehen und die obigen Umschreibungen automatisch für dich machen. SRS ist ein Standard der ihnen bei der Anpassung helfen soll.

Bis die SRS-Fähigkeiten da sind, können folgende provisorische Lösungen weiterhelfen:

Nehmen wir an, du hast eine .forward Datei mit den Inhalt foo@bar.com.

Wenn dein System Procmail verwendet, kannst du diese .forward Datei mit einer .procmailrc Datei ersetzten, die folgenden Inhalt hat:

    :0
    * !^FROM_DAEMON
    ! foo@bar.com

Der Teil !^FROM_DAEMON ist nur zur Sicherheit da --- wenn aus der Adresse foo@bar.com Mail abgewiesen wird (Bounce), wird diese Rückmeldung nicht eine Endlosschleife anstossen.

Wenn du kein Procmail hast, könnte die .forward Datei stattdessen sagen

    |/usr/sbin/sendmail -oi -f nobody@zwischen-domain.com foo@bar.com

Dieses würde die eventuellen Rückmeldungen (Bounces) zu "nobody" weiterleiten, und dort könnten sie dann vernichtet werden. Die Adresse "nobody@zwischen-domain.com" müsste natürlich existieren, und die Mails dorthin könnte man löschen.

Eine erweiterte Lösung wäre die Rückmeldungen (Bounces) weiterzuleiten, es sei denn, sie enthalten den X-Loop Eintrag oder die Weiterleitungsadresse. Dies ist besser als die vorhergehende Variante, die ja alle Rückmeldungen löscht, auch wenn sie nicht eine Endlosschleife bilden würden.

    # Schutz vor Endlosschleifen
    :0 fw
    * !^X-Loop: foo@bar.com
    | /usr/bin/formail -A'X-Loop: foo@bar.com'

    :0 A
    {
        :0
        * !^FROM_DAEMON
        ! foo@bar.com

        :0 B
        * !foo@bar.com
        ! foo@bar.com
    }

Die kann sogar mit der Lösung mit "-f nobody" kombiniert werden. Allerdings macht es wenig Sinn, denn wenn die Weiterleitung einmal zurückkommt, bringt es nichts die resultierende Rückmeldung nochmal weiterzuleiten, also ist eine lokale Ablieferung besser (falls dieses möglich ist...).

Ich verwendet einen SMTP Server auf meinem Laptop.

Falls du eine persönliche Domain verwendest, brauchst du für sie gar keine SPF Einträge zu machen, oder du legst ein SPF-Eintrag der Form "v=spf1 +all" an. Damit kannst du von deinem Laptop Emails verschicken, egal wo du bist.

Wenn du ein Kunde eines Providers bist der SPF Einträge veröffentlicht, muss dir der Provider einen SMTP Server zur Verfügung stellen, wo du dich authentifizieren kannst (entweder mit SMTP-after-POP3 der mittels SASL AUTH). Oder du kannst ihn bitten dich von den SPF auszuschliessen, was er z.B. mittels den Benutzerspezifischen "exists" Mechanismus machen kann.

Ich kann meine DNS-Einträge nicht direkt verwalten.

Wenn du SPF-Einträge veröffentlichen willst, kenne ich folgende Dienstleister, die TXT-Einträge erlauben:

Twisted4life.com
DynDNS (unter CustomDNS)
UltraDNS
ZoneEdit.com
eNom.com
PairNIC.com

Diese Liste ist natürlich nicht vollständig. Dein Domain-Registrar erlaubt es ja eventuell auch. Frag ihn.

Aber es verhindert ja nicht wirklich Spam. Spammers können sich ja immer noch Wegwerf-Domains kaufen, usw.

Wegwerf-Domains ist der nächste Schritt in unserem Kampf. Wir können mit folgenden kontern:

Schnelle automatisierte scharze Listen mittels Spamfallen und Angriffserkenner
Einfache Reputationssysteme, die auf folgende Faktoren beruhen
- Alter der Domain (laut Whois-Eintrag)
- Profil der Domain, z.B. "zu viele unbekannte Empfänger"
- Rückruf-Tests um zu checken, ob die Senderdomain auch Emails empfangen kann.
Die Reputationssysteme können ein empfangenen Mailserver empfehlen, die Email zu verweisen oder abzulehnen.
Legale Methoden den bürokratischen Weg zu verfolgen, wie und wer für die Domain bezahlt hat.

Hier ist ein Beispiel wie so eine automatischen Eintragung in der schwarzen Liste aussehen könnte:

Ein Spammer verschickt Spam.
- Der Spam kommt von einer SPF-fähigen Domain.
  - Die Domain ist in einer bekannten schwarzen Liste
    - Der Mailserver lehnt die Email ab
  - Die Domain ist eine Wegwerf-Domain, wurde soeben registriert und ist noch nicht in den schwarzen Listen.
    1. Der Spam wird von einfachen Mailserver angenommen, die keine weiteren Checks an der Email machen, um die Reputation der Domain festzustellen.
    2. Der Spam wird aber auch bei automatischen Spamfallen angenommen.
    3. Die Spamfallen fügen die Domain in die scharze Listen hinzu.
    4. (fortgeschritten) Einige Zeit später checkt der Benutzer seine Emails. Kurz vor der Anzeige, checkt der Email-Client (MUA) nochmals die schwarze Listen und hat dann noch die Chance, sie abzulehnen.
    5. Dank einer grösseren Zuordnungsfähigkeit der Absender können gezielter rechtliche Schritte gegen Spammer vorgenommen werden, wobei Domain-Registrare dann auf rechtlicher Basis die Inhaberinformationen herausgeben müssen. SPF stärkt diese administrative und rechtliche Wege.
- Der Spam kommt von einer nicht-SPF-fähigen Domain.
  - Zunächst,
    1. fällt fast jede rechtmäßige Email in dieser Kategorie.
    2. Gängige Inhaltsfilter tun ihre Aufgabe.
    3. Die üblichen Ergebnisse an fälschliche Spamerkennung (false positive) und fehlende Spamerkennung (false negative) treffen ein.
  - Später sind
    - die meisten rechtmäßigen Emails SPF-konform,
    - einige rechtmäßige Emails nicht SPF-konform.
    - Ein SPF-konforme Empfänger SOLLTE nicht-SPF-konformen Emails empfangen, KANN sich aber dazu entscheiden, auf diese weitere Tests anzusetzen.
Letztendlich: je mehr SMTP gegen Spam immun ist, desto stärker werden Spammer entmutigt.

Wenn die Masse an Spam geringer wird, können administrative und rechtliche Mittel dagegen effektiver werden; momentan sind sie einfach überfordert. Wenn es nur 10 Spammer in der Welt gibt, kann sich das Rechtssystem damit befassen, jeden einzelnen zu erwischen. Bei 10.000en muss das Rechtssystem passen, es wird dann einfach zu ein gesellschaftliches Problem, wogegen man keine Resourcen hat.

Die Domain, die zum Spammen verwendet wird, muss bei irgendein Domain-Registrar registriert werden.
Wenn der Registrar kooperativ ist kann man von dieser Stelle rausfinden, wer der Spammer ist, und der Registrar kann aufhören dessen Domainwünsche zu erfüllen.
Wenn der Registrar nicht kooperativ ist, oder wenn der Spammer selbst ein Registrar besitzt, kann man auch gleich alle deren Domains in die schwarzen Liste tragen, was eine ähnliche politische Bewegung wie das SPEWS wäre.
Anderenfalls, da Spam mehr und mehr illegal wird, kann man mittels Zwangsvollstreckungen beim Registrar die Daten einholen und den Spammer direkt anklagen.
Wenn der Spammer eine Domain mit falschen Informationen registriert hat, kann man immer noch über die Kreditkartennummer gehen.
Falls die Kreditkarte gestolen ist, ist das dann schon ein Verbrechen, das auf üblicher Weise verfolgt werden muss.

Was bedeutet das Logo?

Ich schaue auf den Briefumschlag (Envelope). Die Absendeadresse besagt, der Brief kommt aus Schlaraffenland. Vergleichen wir die also mit der Briefmarke. Ja, die Briefmarke besagt tatsächlich, dass der Brief aus Schlaraffenland kommt. Das bedeutet, dass die Rückanschrift stimmt. Der Brief ist gut.

Bei Emails ist der Envelope-Sender, auch als "Return-Path" bekannt, die Adresse, wo Rückmeldungen hingehen müssen. Der SMTP-Client ist das Postamt der die Briefmarke abgestempelt hat. Schlaraffenland ist der Domainname. Falls diese nicht übereinstimmen, ist es gut möglich, dass die Absenderinformation gefälscht sind. Vielleicht hat ja ein Bösewicht eine falsche Absenderadresse auf den Brief geschrieben, damit du ihn öffnest. Vielleicht hat ein Spammer ja eine Paypal Absenderadresse gefälscht um an deine Kreditkartennummer zu kommen.

Du kannst das SPF-Logo auf deine Seite tun. Such dir einfach eins aus.

Warum sollte SPF erfolg haben, während ähnliche Vorschläge in der Vergangenheit fehlgeschlagen sind?

Das Spam-Problem war noch nie so schlimm wie jetzt.

Leute sind bereit viel mehr Mühe in die Sache zu stecken.

SPF wird von pobox.com unterstützt, die auch bereit sind die Entwicklung der SPF-Fähigkeit bei den gängigen Mailserver (MTAs) zu sponsorn. Sie sind auch bereit die Rückgriff-Nachschlage Domain für die Guerilla Einführung zu betreiben.

Interesse an die SPF-Entwicklung haben auch schon gezeigt: Qualcomm (die Macher von Eudora), Tim O'Reilly (Verleger von technischen Bücher), SpamAssassin, ActiveState (die Macher von PureMessage), MailArmory, Declude JunkMail, und weitere.

Was ist die "beste Schätzung" ("best guess") und wie funktioniert diese?

Mail::SPF::Query bietet eine "best_guess" Methode an, die einfach annimmt, dass eine Domain den Eintrag "a/24 mx/24 ptr" bekanntgibt. Und dies ist bemerkenswert effektiv um unerlaubte Emails von Domains, die noch nicht SPF-Einträge haben zu erkennen. Es hilft fälschliche Spamerkennung (false positive) zu verringern.

Ich habe nun die SPF-Einträge gemacht. Wie kann ich sie testen?

Sobald du die Einträge hast, kannst du sie hier ausprobieren.

Du kannst du auch eine Email an spfenabled@pobox.com schicken, und abwarten, was passiert. Wenn du von einen ungelisteten Rechner aus verschickst, wird sie abgelehnt. Bitte erfinde keine ungültigen Adressen, die eventuell komische Rückmeldungen an Unbeteiligte zukommen lassen würden.

Gibt es eine Mailingliste?

Sogar vier. Die Grossen sind zur Besprechung (discussion) und für wichtige Bekanntgebungen (announce). Die kleinen sind zur Hilfestellung um SPF einzurichten (help) und für Entwickler, die SPF in ihren Produkten einbinden wollen (devel)
In den Listen wird nur Englisch gesprochen. Falls der Bedarf besteht, kann in Zukunft eine deutsche Gruppe gebildet werden.

Ich hoffe, dass die Mailing Liste nicht zu aktiv ist.

Zwischen 5 und 50 Mails am Tag.

Die Demon-Frage: Was ist mit Subdomains?

Wenn ich Emails von pielovers.demon.co.uk bekommt, und es keine SPF-Informationen zu pielovers gibt, soll ich dann eine Ebene höher gehen und die SPF-Einträge für demon.co.uk checken?

Nein. Jede Subdomain bei Demon ist ein anderer Kunde und jeder Kunde kann seine eigene Politik haben. Es würde eventuell Sinn machen, dass Demon's SPF-Strategie sich auch auf allen ihren Kunden widerspiegelt; falls Demon das will, können sie SPF Einträge für alle Subdomains einrichten.

Der Hinweis für SPF Herausgeber ist also: Du musst SPF Einträge für alle Subdomains und Hostnamen die auch einen A oder MX Eintrag haben tätigen.

Domains mit Joker MX Einträge sollten auch Joker SPF Einträge machen in der Form: * IN TXT "v=spf1 -all"

(Danke an Stuart Cheshire.)

Quell-IP Fälschung (source IP spoofing)?

Spammers können ganze TCP Sequenzen fälschen, um seine Emails rauszubekommen.

On Fri, Oct 24, 2003 at 09:33:29PM -0400, Bill Cole wrote:

Keine Zweifen, dass es für eine kurze Zeit Anfangs der 90er das Risiko solcher Angriffe gab, weil geswitchte Netze grosse Teile der Broadcast Segmente noch nicht ersetzt hatten (z.B. in Firmen und Provider), die Voraussage der Sequenznummern war einfach und Sicherheit war im allgemein einfach scheußlich, so dass ein Angreifer mit einiger Erfahrung es relativ einfach hatte, Geräte in den erforderlichen Stellen zu cracken, um diese Angriffe zu starten.

Es ist nicht mehr diese Zeit. Ein Jahrzehnt des Cracken ist vorbei, Switches haben den komplette Einzug gemacht, sogar in mini-Netzen wie bei mir zu Hause, und die Säuberung mit der Y2K-Problematik haben die Fälschung einer ganzen TCP Sitzung zu einem Trick verwandelt, der ein derartiges Setup voraussetzt, dass es einfach sinnlos ist, diese Täuschung im klassischen Sinn der Voraussage der Sequenznummern zu betreiben.

Und auch wenn jemand es herausfindet, wie man TCP-Fälschung gegen beliebige Ziele im Internet fährt, ohne dazu zur Vorbereitung hochwertigere Maschinen als die des Ziels aufs Spiel zu setzen, ist diese Möglichkeit schon so viel Wert, dass es albern erscheint, diese dann zum Spammen zu verwenden. Damit zu Spammen würde direkt einen Beweis dieser Fähigkeit in die Öffentlichkeit bringen, und die Person, die dieses ausnutzt, aufdecken. Man muss sich natürlich fragen ob man rechtzeitig diesen Beweis aufbringen kann, wenn man den Spammer verfolgt, jedoch kann der Gewinn mit Spam nicht so groß sein, dass es sinnvoll wäre, diese Fähigkeit zu veröffentlichen, wenn man sich vor Augen hält, welche rentable und praktisch unsichtbare Möglichkeiten sich damit eröffnen.

Ich bin immer noch gespannt, ob jemand echte Beweise zeigen kann, dass TCP spoofing praktikabel im heutigen Internet ist.

Und selbst wenn man doch durchkommt, kann ESMPT zum Beispiel ein Token bei EHLO einführen, den der Client dann einfach zurückgeben muss. Wenn das nicht passiert, kann die Verbindung z.B. dann mit einer höherer Spamwahrscheinlichkeit versehen werden. Wenn dies ein grösseres Problem werden sollte, müsste man es auf Netzwerkeben anpacken, wobei dann alle Grenzrouter die Quell-IP filtern müssten. Wenn böse Menschen rausfinden, wie man komplette TCP-Sequenzen fälscht, haben wir sicher grössere Sorgen als Spam.

Hopla, da ist ja ein Unterstrich in _spf.

Ich dachte es sind nur Buchstaben, Zahlen und der Bindestrich in Domainnamen erlaubt, kein Unterstrich.

Anscheinend sind Unterstriche jetzt in Ordnung. Siehe RFC2181 Sektion 11.

Unterstriche erlauben eine geheime neue Dimension: So kann man sicherstellen, dass man keiner weiteren Subdomain in die Quere kommt. SRV-Einträge benutzen schon Unterstriche aus genau diesem Grund.

Was ist mit den einfachen Fällen?

Wenn eine Domain kein MX-Eintrag hat, nehmen wir an, dass ein A-Eintrag genügt.

SPF folgt die gleiche intuitive Idee. Mail::SPF::Query stellt die "best_guess" Methode zur Verfügung, die annimmt, dass eine Domain den SPF-Eintrag "a mx ptr" hat. Auch wenn keine SPF-Daten für eine Domain zugrundeliegen, können wir empfehlen, dass eine Verbindung legitim ist (wobei wir aber nicht sagen können, dass sie nicht legitim ist, nur dass man dann nicht sicher ist). Und solche Empfehlungen können dann andere Antispam Techniken helfen, fälschliche Spamerkennung (false positives) zu verringern.

Wie wärs damit: Ein Schritt weitergehen und nicht nur Domainnamen, sondern auch die Absender zu validieren?

Genau dafür gibts den "exists" Mechanismus.

Solltest du nicht SRV oder EDNS0 Einträge verwendet haben?

SRV records waren, grob gesagt, dazu gedacht solche Art von Erweiterungen im DNS einzubringen, ohne dass neue Record-Typen eingeführt werden müssten. Siehe auch RFC2761, "Extension Mechanisms for DNS".

Ja. aber SRV-Einträge sind schwer verständlich für Menschen, TXT-Einträge sind einfach. Schnelle weltweite Verbreitung ist unser Ziel. Die richtige Vorgehensweise ist es ein eigenen RR-Typ zu beantragen, und wir werden es tun. Aber nicht in einer nahen Zukunft.

(Für SRV Einträge, siehe http://dqd.com/~mayoff/tools/djbdns/make-record.adp)

Was ist mit den kompromittierten Maschinen an DSL-Leitungen mit offenen Proxy die heutzutage als Spam-Quellen verwendet werden?

Spammer verwenden vermehrt gecrackte Maschinen, die schnell angebunden sind, um Spam zu verschicken.

Breitband Provider müssen darauf achten, dass Port 25 über ihre eigenen Server gehen, so dass sie diesen Datenverkehr im Auge behalten können, oder sie tragen die Konsequenzen eines Reputationssystems, dass ihre gefälschte Domain im Envelope-Sender auftaucht. Ich kenne Leute die einfach Hotmail, Yahoo und AOL komplett blocken, einfach weil dies die meistgefälchten Adressen sind. Dieses schädigt den rechtmässigen Nutzer dieser Dienste, und letztendlich den Provider selbst.

Bei einem grossen Spamlauf könnte SPF dadurch zu einen DDOS ("verteilter Dienstverweigerungsangriff") gegen die gefälschte Domain sein!

Jeder SMTP-Server im Spamverlauf kann eine DNS-Abfrage zu der gefälschten Domain starten. Bei einer Million an SMTP-Server wären das ja 100 Mb an Datenverkehr!

DNS Abfragen sind trotzdem noch wesentlich kleiner als die Zustellungsnachrichten (bounce messages). Und die meisten SPF-Anfragen können gecacht werden. Einzige Ausnahme ist das relativ seltene "exists" Mechanismus, das nicht vom DNS-Caching profitiert.

Was ist mit MAILER-DAEMON Nachrichten, die als Absenderadresse <> verwenden?

Wenn die Absenderadresse <> ist, gibt es gar keine Domain, die man überprüfen könnte!

Dazu gibt es zwei Lösungen, eine stark, die andere schwach.

Die schwache Lösung ist die Domain, die im HELO/EHLO Befehl gegeben worden ist statdessen zu verwenden. Damit kann man schon nachlässige Spammer abfangen.

Sorgfältige Spammer finden ein Weg darum: Stell dir ein kompromittierten Rechner mit Breitband-Zugang vor. Die starke Lösung nimmt die Nachricht an, nimmt sie auseinander, stellt fest, ob es tatsächlich eine Zustellungsantwort ist (bounce), entnimmt die Message-ID der Ursprünglichen Nachricht, und wenn sicher steht, dass diese Message-ID nicht von dem System stammt, wird die Nachricht abgewiesen. Dies erfordert mehr Aufwand, aber in einer Welt wo automatische Spamfallen die meiste Arbeit erledigen, würde die Absendeadresse sowieso schon in schwarzen Listen der "bekannten Spammer" stehen, und der Spammer kann dann auch genausogut nicht-leere Absender verwenden.

Auf jeden Fall sollte ein Mailserver jedoch Mails mit leeren Absender die aber an mehreren Empfänger gehen, ablehnen.

Welche weiteren Strategien ausser SPF sollte ich bei meinem Mailserver anwenden?

Der SPF Entwurf meint, die SPF Checks sind nur in bestimmten Situationen sinnvoll.

Mailserver können eine Menge Spam schon vor den SPF Checks abblocken.

Hier sind einige Vorschläge, die vieles an Spam abblocken. Nur Nachrichten, die dann noch durchkommen, müssen dann mittels SPF überprüft werden.

Die Domain des Envelope-Senders muss ein A oder MX-Eintrag besitzen.
Der A oder MX-Eintrag dieser Domain darf nicht in folgenden Bereichen sein:
- 0.0.0.0/8
- 10.0.0.0/8
- 127.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
Die IP Adresse des verbindenden Clients muss ein PTR-Eintrag haben.
Der Hostname in der HELO Anweisung muss ein gültiger vollqualifizierter Domainname sein und ein A-Record besitzen.

Beachte, dass die Regeln 3 und 4 auch oft von legitimen aber ahnungslosen Domains missachtet werden, die dieser Art von Details keine Achtung schenken.

Wie man diese Einstellungen beim Postfix erledigen kann steht unter http://www.postfix.org/uce.html

Ich bin ein Provider (ISP). Was soll ich beachten?

Inhaber von "schönklingende" Domains (vanity domains) werden eventuell auf dich mittels der "include" Anweisung verweisen.
Du solltest SASL AUTH auf den ports 25 und 587 unterstützen. Wenn deine Benutzer aus einem Internet Cafe eine Email verschicken wollen, ist eventuell die port 25 gesperrt, aber nicht port 587.
Du kannst in den Anfangsmonaten die Standardantwort auf "unbekannt" setzen, indem du "?all" statt "-all" schreibst. So können sich dann nach und nach deine Benutzer umstellen, die eventuell über fremde Mailserver ihre Emails verschicken.
Du kannst sogar herausfinden welche Benutzer das sind, indem du den Eintrag exists:%{l}.%{i}._spf.ISP.COM in deiner Regel einfügst. In dein DNS-Query-Log findest du dann diese Anfragen wieder. So kannst mit noch nicht umgestellte Benutzer in Kontakt treten und denen anweisen, welche SMTP-Server sie benutzen müssen.

Wie kann ich mein Eintrag testen/validieren/checken?

Es gibt schon eine mehrzahl von SPF checker. Versuche:

Steht SPF für "Sender Permitted From"?

Das war einmal, aber der Name erwies sich als schwer einzuprägen, so entschieden wir in Februar 2004 den Namen in den genaueren "Sender Policy Framework" zu ändern.

Zu Marketingzwecke wählten wir zuerst die Abkürzung, dann den dazu passenden Namen. Wir haben im Google geschaut, ob SPF schon etwas ausserhalb der Sonnenschutz-Welt ("Sun Protection Factor") bedeutete. Es ist der Name eines Netzwerkkonzeptes --- "Shortest Path First" --- aber das ist in Ordnung; Jede gute Abkürzung braucht wenigstens zwei passende Namen. So haben wir diesen Namen für die Marke ausgesucht und sind heute schon Nummer 1 im Google für "SPF".