Syntax von SPF-Einträgen: Bestandteile und Regeln für die Strukturierung

SPF erscheint oft einfach, bis man den Eintrag selbst erstellen oder Fehler beheben muss. Das Problem besteht nicht nur darin, zu wissen, welche Absender autorisiert werden sollen. Es geht darum, zu wissen, wie man diese im Domain Name System korrekt ausdrückt, damit die empfangenden Server die Richtlinie so auswerten können, wie Sie es beabsichtigt haben.

Was ist die Syntax eines SPF-Eintrags?

Die SPF-Eintragssyntax umfasst die Struktur und die Formatierungsregeln, die zur Erstellung eines gültigen SPF-TXT-Eintrags verwendet werden. Praktisch gesehen handelt es sich dabei um die Angabe, die eine Domain im DNS verwendet, um einem empfangenden Server mitzuteilen, welche E-Mail-Absender in ihrem Namen E-Mails versenden dürfen.

Dies ist von Bedeutung, da die SPF-Syntax festlegt, wie autorisierte Absenderquellen in einem DNS-TXT-Eintrag dargestellt werden. Sollte die Syntax fehlerhaft sein, kann die SPF-Authentifizierung fehlschlagen, selbst wenn die richtigen Absender aufgeführt sind. Zudem ist es hilfreich, die Syntax von der Strategie zu trennen: Die SPF-Syntax ist die Formatierungsebene, die eine Richtlinie für E-Mail-Systeme lesbar macht, während die Strategie festlegt, welche Absender autorisiert werden sollen und wie streng die Richtlinie sein soll.

Kernkomponenten der SPF-Eintragssyntax

Ein SPF-Eintrag setzt sich aus einer kleinen Anzahl von Kernelementen zusammen: dem Versionskennzeichen, den Mechanismen, den Qualifikatoren und den Modifikatoren. Gemeinsam legen sie dem empfangenden Server fest, was zu prüfen ist, wie das Ergebnis zu interpretieren ist und wie vorzugehen ist, wenn kein früherer Mechanismus zutrifft. In der Spezifikation werden Mechanismen und Modifikatoren unterschiedlich behandelt, obwohl beide innerhalb desselben TXT-Eintrags vorkommen.

SPF-Mechanismen

Mechanismen sind die übereinstimmenden Begriffe in einem SPF-Eintrag. Sie legen fest, welche Quellen zugelassen sind. In der Praxis sind die häufigsten davon:

• ip4 und ip6 für bestimmte IPv4- oder IPv6-Adressbereiche
• a) zur Autorisierung der von einem A- oder AAAA-Eintrag zurückgegebenen IP-Adresse
• mx, um die IP-Adressen der Hosts des MX-Eintrags der Domain zu autorisieren
• einbinden, um auf die SPF-Richtlinie einer anderen Domäne zu verweisen und diese auszuwerten
• all dies als abschließender Auffangmechanismus

Diese Mechanismen sind weit verbreitet, da sie die übliche Weiterleitung von Unternehmens-E-Mails widerspiegeln. „ip4“ und „ip6“ werden für bekannte Versandinfrastrukturen verwendet, „mx“ ist üblich, wenn der E-Mail-Server der Domain auch E-Mails versendet, und „include“ wird häufig für Cloud-Plattformen wie Microsoft 365 und Google Workspace verwendet.

Möglicherweise stoßen Sie auch auf „exists“ oder „ptr“, doch bei beiden ist Vorsicht geboten. Im SPF-RFC wird ausdrücklich darauf hingewiesen, dass „ptr“ nicht verwendet werden soll, und „exists“ ist komplexer und lässt sich leichter missbrauchen als die Mechanismen, auf die sich die meisten Organisationen stützen.

SPF-Qualifikationsrunden

Ein Qualifikator verändert die Bedeutung eines Mechanismus. Die praktischen Ergebnisse sind:

• + bestanden, wobei das Pluszeichen in der Regel stillschweigend vorausgesetzt wird
• - fehlschlagen
• ~ softfail
• ? neutral

Diese Qualifizierer beeinflussen, wie SPF-Prüfungen vom empfangenden Server interpretiert werden. Eine strengere Abschlussregel wie „-all“ teilt dem Empfänger mit, dass alles, was nicht übereinstimmt, den SPF-Test nicht bestehen sollte.

Ein toleranterer Ansatz beim Schließen, wie beispielsweise „~all“, signalisiert, dass nicht zugeordnete Quellen stattdessen einen Soft-Fail auslösen sollten; dies wird häufig während der Übergangsphase oder dann angewendet, wenn die Bestände der Absender noch bereinigt werden. In der Praxis wirkt sich diese Wahl auf die Durchsetzung, die Fehlerbehebung und mitunter auch auf die spätere Zustellung in den Posteingang aus.

SPF-Modifikatoren

Modifikatoren sind spezielle Syntaxelemente, die das Verhalten von SPF erweitern, anstatt Absender direkt abzugleichen. Für die meisten Leser aus dem Unternehmensbereich sind „redirect“ und „exp“ am relevantesten. Der SPF-RFC definiert „redirect“ für die Delegierung der Auswertung an die SPF-Richtlinie einer anderen Domäne und „exp“ für die Rückgabe einer benutzerdefinierten Erklärung im Falle eines Fehlers.

Dies unterscheidet sich von Mechanismen. Mechanismen sind direkt am Abgleich beteiligt, während Modifikatoren die Art und Weise beeinflussen, wie der Datensatz verarbeitet wird. In komplexeren Umgebungen kann die Umleitung nützlich sein, wenn sich mehrere Domänen dasselbe E-Mail-System teilen und eine Richtlinie mehrere miteinander verbundene Domänen steuern soll. Der RFC empfiehlt zudem, die Umleitung aus Gründen der Übersichtlichkeit an das Ende des Datensatzes zu setzen.

SPF-Versionskennzeichnungen

Jeder SPF-Eintrag muss mit „v=spf1“ beginnen. Dies ist das erforderliche Eröffnungs-Tag, das den DNS-TXT-Eintrag als SPF-Richtlinie kennzeichnet. Empfangsserver nutzen dieses Tag, um zu erkennen, dass der Datensatz anhand der SPF-Regeln ausgewertet werden soll. Fehlt das Versionskennzeichen, ist es doppelt vorhanden oder fehlerhaft, kann der Datensatz als ungültig betrachtet werden.

Wie sieht ein gültiger SPF-Eintrag aus?

Die Standardform eines gültigen SPF-Eintrags ist unkompliziert: Er beginnt mit dem Versions-Tag, gefolgt von einem oder mehreren Mechanismen, optionalen Modifikatoren und endet schließlich mit einer abschließenden Richtlinie. Einfacher ausgedrückt: Ein gültiges SPF-Eintragsformat folgt einer klaren Struktur, die empfangende Server ohne Verwirrung auswerten können.

Ein einfaches Beispiel für einen SPF-Eintrag lautet:

v=spf1 include:_spf.google.com ~all

Warum dies zutrifft:

• „v=spf1“ kennzeichnet den Eintrag als SPF
• „include:_spf.google.com“ autorisiert die Versandinfrastruktur von Google Workspace
• ~„all“ legt eine Softfail-Richtlinie für nicht übereinstimmende Quellen fest

Ein Beispiel für einen komplexeren SPF-Eintrag lautet wie folgt:

v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

Warum dies zutrifft:

• „v=spf1“ ist das erforderliche Versionskennzeichen
• ip4:192.168.0.10 autorisiert eine bestimmte IP-Adresse
• include:spf.protection.outlook.com autorisiert die Absender von Microsoft 365
• -all legt für alle anderen Fälle eine strenge Ablehnung fest

In beiden Beispielen ist die SPF-Syntax korrekt, da der Eintrag korrekt beginnt, anerkannte Mechanismen verwendet und mit einer eindeutigen Richtlinie endet. Die Strategie unterscheidet sich, doch die Struktur bleibt unverändert.

Regeln und Überprüfung des korrekten SPF-Formats

Ein gültiger SPF-Eintrag hängt von der exakten Formatierung ab. Der Eintrag sollte korrekt beginnen, den anerkannten SPF-Konventionen entsprechen und in logischer Reihenfolge angeordnet sein, da DNS- und E-Mail-Systeme fehlerhafte Einträge nicht tolerieren.

Beginnen Sie mit dem richtigen Versions-Tag

Jeder SPF-Eintrag sollte mit „v=spf1“ beginnen. Falls das Versionskennzeichen fehlt, doppelt vorhanden oder fehlerhaft ist, wird der Datensatz möglicherweise als ungültig behandelt. SPF verwendet nur ein gültiges Versionskennzeichen; es gibt daher keine alternative SPF-Versionszeichenfolge, die Sie an dessen Stelle verwenden sollten.

Verwenden Sie ausschließlich anerkannte SPF-Begriffe

Mechanismen, Qualifizierer und Modifikatoren müssen der gültigen SPF-Syntax entsprechen. Nicht erkannte oder falsch platzierte Begriffe können die Auswertung beeinträchtigen. Die ausschließliche Verwendung unterstützter SPF-Begriffe trägt zudem dazu bei, dass die Richtlinie für empfangende Server vorhersehbar bleibt und sich bei Änderungen an den sendenden Diensten leichter pflegen lässt.

Sorgen Sie für eine logische Reihenfolge der Datensätze

SPF-Einträge sollten klar strukturiert sein, damit Mechanismen, Qualifizierer und Modifikatoren leicht zu bewerten und zu pflegen sind. Eine übersichtlichere Struktur erleichtert zudem die Fehlersuche, wenn sich ein sendender Dienst ändert oder ein Authentifizierungsproblem auftritt.

Achten Sie auf häufige Syntaxfehler

Zu den häufigsten Syntaxproblemen zählen:

• Fehlt v=spf1
• Doppelte oder fehlerhafte Qualifizierer
• Unbekannte Begriffe
• Zu viele verschachtelte Abfragen über „include“, „a“ oder „mx“
• Falsche Versuche, mehrere SPF-Einträge zu kombinieren
• Begriffe in einer verwirrenden oder ungültigen Reihenfolge anordnen

Selbst kleine Formatierungsfehler können dazu führen, dass die SPF-Validierung fehlschlägt, was Ihre allgemeine E-Mail-Authentifizierungsstrategie untergraben kann, noch bevor DMARC und das Berichtswesen ihre Aufgabe erfüllen können. Aus diesem Grund sollten Syntaxprüfungen bei jeder Aktualisierung von Datensätzen durchgeführt werden, nicht nur bei der Ersteinrichtung.

Veröffentlichen Sie nur eine SPF-Richtlinie pro Hostnamen

Eine Domain sollte nicht mehrere SPF-Einträge für denselben Hostnamen veröffentlichen. Eine fehlerhafte Kombination mehrerer SPF-Einträge kann zu Problemen bei der SPF-Validierung und zu Authentifizierungsfehlern führen.

Befolgen Sie die grundlegenden SPF-Best-Practices

Beginnen Sie stets mit „v=spf1“, achten Sie auf eine saubere Syntax und überprüfen Sie den Eintrag regelmäßig, da sich die versendenden Dienste ändern können. Geringfügige Syntaxfehler können die SPF-Authentifizierung beeinträchtigen; daher sind regelmäßige Überprüfungen ein wesentlicher Bestandteil einer guten langfristigen Verwaltung Ihrer Datensätze.

Das Ziel besteht nicht lediglich darin, die Aufzeichnung technisch gültig zu machen. Damit soll sichergestellt werden, dass die SPF-Konfiguration so übersichtlich bleibt, dass durch Änderungen im Laufe der Zeit keine neuen Syntaxprobleme entstehen; aus diesem Grund ist es sinnvoll, Aktualisierungen durch eine Überprüfung des SPF-Eintrags zu validieren.

Wie sollten Sie SPF-Einträge für mehrere Absender strukturieren?

Moderne Unternehmen versenden E-Mails selten von einem einzigen Standort aus. Möglicherweise muss eine single Domain interne Server, Microsoft Exchange, Google Workspace, Support-Plattformen und andere Dienste von Drittanbietern in einem single SPF-Eintrag autorisieren.

Um dies überschaubar zu halten:

• Achten Sie auf eine klare Struktur, damit jeder Mechanismus einen eindeutigen Zweck erfüllt
• Verwenden Sie nur die Absender, die Sie tatsächlich benötigen, um veraltete oder unnötige Einbindungen zu vermeiden.
• Begrenzen Sie die Komplexität, da lange, vielschichtige Datensätze schwieriger zu überprüfen sind und häufiger zu Fehlern führen.
• Überprüfen Sie die Richtlinie regelmäßig, da sich die Versanddienste im Laufe der Zeit ändern

Das Ziel ist nicht nur Korrektheit, sondern auch Wartbarkeit. Eine gute SPF-Verwaltung fördert sowohl die SPF-Authentifizierung als auch die Zustellbarkeit von E-Mails auf lange Sicht.

Es ist zudem hilfreich, sich vor Augen zu halten, dass SPF nur ein Bestandteil der E-Mail-Authentifizierung ist. Es funktioniert in Verbindung mit DomainKeys Identified Mail und einer DMARC-Richtlinie. Selbst ein gültiger SPF-TXT-Eintrag löst für sich genommen nicht jedes Problem im Bereich der E-Mail-Sicherheit, doch eine korrekte Syntax des SPF-Eintrags ist dennoch ein notwendiger Kontrollpunkt, da ein fehlerhafter Eintrag die Authentifizierung schwächt, bevor übergeordnete Richtlinien ihre Wirkung entfalten können.

Richtige SPF-Einträge implementieren

Die wichtigste Erkenntnis für den praktischen Einsatz ist einfach: Bei der Syntax von SPF-Einträgen geht es nicht nur um die Formatierung. Die Kontrollschicht teilt einem empfangenden Server mit, wie er beurteilen soll, welche Absender Ihre Domain nutzen dürfen. Sollte die Syntax fehlerhaft sein, kann die SPF-Authentifizierung fehlschlagen, selbst wenn Ihre autorisierten Absender korrekt sind.

Aus diesem Grund sollte bei der Gestaltung von SPF-Einträgen ein Gleichgewicht zwischen Korrektheit und Wartbarkeit angestrebt werden. Achten Sie auf eine klare Struktur, vermeiden Sie mehrere SPF-Einträge, gestalten Sie die Mechanismen zweckmäßig und überprüfen Sie die Einträge regelmäßig, da sich die versendenden Dienste ändern. Ein einheitliches SPF-Datensatzformat erleichtert die Verwaltung dieses Prozesses auf lange Sicht.