Eigene Mails landen im Spam: Der SPF-Eintrag passt nicht
Der Empfänger lehnt ab oder sortiert als Spam aus, weil der sendende Server nicht im SPF-Eintrag steht. Was SPF wirklich prüft — und was nicht.
Aufwand:
ca. 30 Min.
Voraussetzung:
Zugriff auf die DNS-Zone der eigenen Domain, Terminal oder Eingabeaufforderung, Liste aller Systeme, die im Namen der Domain versenden
Gilt für:
SPF Version 1 nach RFC 7208
Das Symptom
Die Rundmail an die Mitglieder geht raus, und dann passieren drei Dinge
gleichzeitig: Ein Teil kommt an, ein Teil liegt im Spam-Ordner, und ein Teil
kommt als Rückläufer zurück — mit einer Zeile wie 550 5.7.1. Beim eigenen
Testversand an die eigene Adresse funktioniert selbstverständlich alles. Besonders
gern trifft es Post, die eine Weiterleitung passiert hat, oder Nachrichten aus
einem Programm, das erst kürzlich dazugekommen ist: das Newsletter-Werkzeug, die
Vereinsverwaltung, das Kontaktformular der Webseite.
Die „Layer 8“-Wahrheit
E-Mail wurde in einer Zeit entworfen, in der niemand log. Deshalb darf ein
sendender Rechner bis heute praktisch behaupten, wer er will. SPF ist der
nachträglich angebaute Türsteher: Der Inhaber einer Domain hinterlegt im DNS eine
Liste der Server, die in ihrem Namen versenden dürfen, und der Empfänger schlägt
sie nach. Der Denkfehler, an dem fast alle scheitern, steckt in der Frage, welche
Absenderangabe dabei geprüft wird. Es ist nicht die Adresse, die dein
Mailprogramm groß anzeigt. Geprüft wird der Briefumschlag — die Rückweg-Adresse
aus dem SMTP-Gespräch und die Kennung, mit der sich der sendende Server meldet.
Briefumschlag und Briefkopf können völlig verschiedene Domains nennen, und der
Empfänger sieht nur den Briefkopf.
Daraus folgen zwei Dinge, die ständig für Verwirrung sorgen. Erstens: Ein
bestandener SPF-Test beweist nicht, dass der angezeigte Absender echt ist. Der RFC
warnt selbst davor, dass ein Angreifer mit sauber autorisierter eigener Domain
versenden und im Briefkopf trotzdem jede beliebige Adresse eintragen kann.
Zweitens: SPF bricht bei Weiterleitungen, und zwar nicht aus Schlamperei, sondern
weil das Verfahren die IP-Adresse des zuletzt zustellenden Servers bewertet. Leitet
ein Postfach deine Mail weiter, kommt sie beim Ziel von einem Server, der in deinem
Eintrag nie stehen kann.
Der praktische Teil ist deshalb unspektakulär und langweilig, genau wie er sein
soll: Alle Systeme auflisten, die tatsächlich in eurem Namen versenden — auch die,
an die niemand denkt. Genau einen TXT-Eintrag pflegen, nicht zwei. Die Grenze von
zehn DNS-Nachschlägen nicht reißen, sonst kippt das Ergebnis in einen dauerhaften
Fehler, der bei vielen Empfängern schlechter dasteht als gar kein Eintrag. Und den
Eintrag klein halten, damit die Antwort ins DNS-Paket passt. Wer das erledigt hat,
hat nicht „das Spam-Problem gelöst“ — er hat den ersten von drei Bausteinen
gesetzt. Die anderen beiden heißen DKIM und DMARC.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den eigenen SPF-Eintrag überhaupt erst ansehen
Ein SPF-Eintrag ist ein ganz normaler TXT-Eintrag im DNS, direkt auf dem Domainnamen — nicht in einer Unterdomain darunter. RFC 7208 legt fest, dass SPF-Einträge ausschließlich als DNS-TXT-Eintrag (Typ 16) veröffentlicht werden MÜSSEN; die frühere Unterstützung eigener Eintragstypen wurde eingestellt. Ohne Ergebnis heißt: Es gibt keinen SPF-Eintrag, und der Empfänger weiß nichts über deine Versandwege.
Ein häufiger und leicht zu übersehender Fehler: zwei SPF-Einträge, weil beim Wechsel des Dienstleisters der alte stehen blieb. Der RFC lässt daran keinen Zweifel — mehrere SPF-Einträge für denselben Namen sind nicht zulässig, und ein Domainname DARF NICHT mehrere Einträge haben, die dazu führen würden, dass eine Autorisierungsprüfung mehr als einen Eintrag auswählt. In der Ausgabe des vorigen Schritts darf also nur eine einzige Zeile mit v=spf1 beginnen. Sind es zwei, ist das Ergebnis nicht etwa die Summe beider, sondern schlicht kaputt.
3.
Alle Versandwege zusammentragen, bevor du etwas änderst
Bevor eine Zeile geändert wird, muss die Liste stehen: der Mailserver des Providers, das Newsletter-Werkzeug, das Vereinsverwaltungsprogramm, die Webseite mit dem Kontaktformular, das Ticketsystem, der Kopierer im Flur, der Scans verschickt. Jedes System, das in eurem Namen versendet, gehört in den Eintrag — oder es fliegt raus. Genau an dieser Liste scheitert es in kleinen Organisationen fast immer, nicht an der Syntax.
4.
Den Eintrag aus den belegten Bestandteilen zusammensetzen
Der RFC führt als Beispiel den Eintrag `v=spf1 +mx a:colo.example.com/28 -all` an und erläutert ihn selbst: Der Eintrag hat die Version spf1 und drei Direktiven. Erlaubte Mechanismen sind laut Abschnitt 4.6.1 all, include, a, mx, ptr, ip4, ip6 und exists; davor darf ein Qualifikator stehen. Zu ptr trägt der RFC die Überschrift do not use und schreibt dazu, dieser Mechanismus SOLLTE NICHT veröffentlicht werden — er gehört in keinen neuen Eintrag. Die möglichen Qualifikatoren und die Ergebnisse, die sie auslösen, listet der RFC als Plus gleich pass, Minus gleich fail, Tilde gleich softfail und Fragezeichen gleich neutral — ohne Angabe gilt das Plus. Der Mechanismus all ist ein Test, der immer zutrifft, und wird als äußerst rechter Mechanismus verwendet, um einen ausdrücklichen Standardfall festzulegen. Der Eintrag steht als eine Zeile im DNS, in Anführungszeichen:
Zähle im fertigen Eintrag alle include-, a-, mx-, ptr- und exists-Mechanismen sowie ein etwaiges redirect zusammen — inklusive dessen, was die eingebundenen Domains ihrerseits nachschlagen. Mehr als zehn sind laut RFC ein permerror, und ein permerror wirkt bei vielen Empfängern schlimmer als gar kein Eintrag. Auflösen lässt sich das, indem man Verweise durch die konkreten Netze ersetzt: ip4 und ip6 prüfen, ob die Adresse in einem angegebenen IP-Netz enthalten ist, und lösen dabei keine DNS-Abfrage aus. Fehlt die Präfixlänge, gilt laut RFC /32 beziehungsweise /128.
6.
Den Eintrag kurz halten
Der veröffentlichte SPF-Eintrag SOLLTE klein genug bleiben, dass das Ergebnis einer Abfrage in 512 Oktetts passt, sonst droht laut RFC das Überschreiten einer DNS-Protokollgrenze. Als Faustregel nennt der Text: Bleibt die kombinierte Länge aus DNS-Name und dem Text aller Einträge dieses Typs unter 450 Oktetts, passen die Antworten in UDP-Pakete. Einträge, die zu lang für ein einzelnes UDP-Paket sind, könnten von SPF-Prüfern stillschweigend ignoriert werden — und stillschweigend ignoriert ist die unangenehmste Fehlerart überhaupt.
7.
Weiterleitungen einkalkulieren statt sich über sie zu ärgern
Wenn Mitglieder ihre Vereinsadresse auf ein privates Postfach weiterleiten, wird SPF dort fehlschlagen — konstruktionsbedingt. Der RFC nennt dafür im Anhang die Wege: Mediatoren können das Problem lösen, indem sie das MAIL FROM in ihre eigene Domain umschreiben. Auf der Empfängerseite können Prüfungen gegen andere Identitäten, etwa die HELO-Kennung, eine fehlgeschlagene Prüfung gegen die MAIL-FROM-Identität übersteuern. Beides liegt nicht in deiner Hand. In deiner Hand liegt: nicht überrascht zu sein und zusätzlich auf DKIM zu setzen, das eine Weiterleitung übersteht.
Häufige Fragen (FAQ)
?Was genau prüft SPF eigentlich — steht da nicht einfach meine Absenderadresse drin?
Nein, und das ist der wichtigste Satz zum Thema. SPF prüft zwei Angaben aus dem SMTP-Gespräch, nicht die Adresse, die dein Mailprogramm anzeigt. RFC 7208 nennt sie MAIL FROM (die Rückweg-Adresse, technisch RFC5321.MailFrom) und HELO/EHLO (die Kennung, die der sendende Server beim Verbindungsaufbau nennt). Beides gehört zum Briefumschlag, nicht zum Briefkopf. Der RFC ist da unmissverständlich: Die Autorisierungen von MAIL FROM und HELO liefern keine Zusicherung über die Echtheit anderer Identitäten in der Nachricht, und wenn der Benutzer nicht darauf achtet, dass die autorisierte Identität nicht mit den üblicherweise sichtbaren Identitäten übereinstimmt — etwa dem From-Kopffeld —, kann er in falscher Sicherheit gewiegt werden. Kurz: Ein sauberes SPF-Ergebnis sagt nichts darüber aus, wer im angezeigten Absender steht. Genau diese Lücke schließt erst DMARC.
?Warum landen Mails nur dann im Spam, wenn sie über eine Weiterleitung laufen?
Weil SPF sich immer die IP-Adresse des zuletzt zustellenden Servers ansieht. RFC 7208 beschreibt das für sogenannte Mediatoren, also Weiterleiter und Mailinglisten: Da die SPF-Auswertung auf der IP-Adresse des letzten sendenden SMTP-Servers beruht, wird die Adresse des Mediators verwendet und nicht die des Servers, der die Nachricht an den Mediator geschickt hat. Manche Mediatoren behalten die ursprüngliche Absenderadresse bei, andere setzen eine neue. Und dann kommt der entscheidende Satz: Ist die Adresse dieselbe wie bei der ursprünglichen Nachricht und hatte diese einen SPF-Eintrag, dann schlägt die SPF-Auswertung fehl, sofern keine Gegenmaßnahmen greifen. Das ist kein Fehler in deinem Eintrag. Das ist die eingebaute Grenze des Verfahrens: Der Weiterleiter versendet von seiner eigenen IP und behauptet dabei, deine Domain zu sein.
?Ich habe einen weiteren Dienstleister eingetragen, jetzt geht gar nichts mehr. Wie kann das sein?
Vermutlich hast du die Nachschlagegrenze gerissen. RFC 7208 zählt auf, welche Bestandteile eines Eintrags beim Auswerten eine DNS-Abfrage auslösen: die Mechanismen include, a, mx, ptr und exists sowie der Modifikator redirect. Für diese gilt: SPF-Implementierungen MÜSSEN die Gesamtzahl dieser Bestandteile während der SPF-Auswertung auf 10 begrenzen, um unangemessene Last für das DNS zu vermeiden — und wird die Grenze überschritten, MUSS die Implementierung permerror zurückgeben. Das Tückische daran: Jedes include kann selbst weitere includes enthalten, die mitzählen. Drei Dienstleister mit je vier Ebenen reichen. Die Mechanismen all, ip4 und ip6 lösen laut RFC keine Abfrage aus und zählen deshalb nicht mit — wer die Grenze reißt, ersetzt include-Verweise am besten durch konkrete ip4- und ip6-Angaben.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Der eigene Mailserver kann nicht senden, empfangen geht? Viele Anbieter sperren den ausgehenden Port 25 gegen Spam — der Versand braucht einen anderen Weg.