Zwei SPF-Einträge = Permerror: die Falle des doppelten Eintrags

Von Thomas · virtueller CISO · 23. August 2026

Es ist eine der verwirrendsten Pannen der E-Mail-Authentifizierung, weil sie gar nicht wie eine Panne aussieht. Nichts wurde gelöscht, kein Tippfehler hat sich eingeschlichen, kein Server ist ausgefallen: Ein Eintrag wurde hinzugefügt. Ein zweiter TXT-Eintrag, der mit v=spf1 beginnt, taucht in der DNS-Zone auf — meist auf Verlangen eines neuen Versanddienstleisters —, und von dieser Sekunde an gelingt keine einzige SPF-Prüfung der Domain mehr. Nicht nur für das neue Werkzeug: für sämtliche Mailflüsse, einschließlich derer, die am Vortag noch tadellos funktionierten.

Die Ursache passt in eine ebenso einfache wie brutale Regel, festgelegt in RFC 7208: Ein Domainname veröffentlicht einen einzigen SPF-Eintrag. Existieren zwei, wählt der Prüfer nicht den „richtigen" aus, führt sie nicht zusammen und nimmt auch nicht den neuesten: Er erklärt das Ganze für nicht interpretierbar und liefert permerror — einen permanenten Fehler, der in der Praxis dem völligen Fehlen einer SPF-Authentifizierung gleichkommt.

Diese Duplikat-Falle ist vermutlich der häufigste Weg, SPF zu zerstören, ohne den Inhalt irgendeines Eintrags anzurühren. Dieser Artikel entfaltet die Regel und ihren Grund, die Szenarien, die das Duplikat einschleusen, die genaue Konsequenz — bis hinein in die DMARC-Berichte —, die Diagnose in zwei Minuten, die korrekte Zusammenführung zu einem einzigen Eintrag und eine entscheidende Unterscheidung zu einem benachbarten, völlig gültigen Fall: mehrere Zeichenketten innerhalb eines einzigen TXT-Eintrags.

Eine Domain, ein einziges `v=spf1`: was RFC 7208 vorschreibt

Die Mechanik steht schwarz auf weiß in RFC 7208, dem SPF-Standard. Bei einer Prüfung fragt der empfangende Server die TXT-Einträge der beanspruchten Domain ab, verwirft alles, was nicht exakt mit v=spf1 beginnt, und untersucht den Rest. Enthält das Ergebnis genau einen Eintrag, beginnt die Auswertung. Enthält es mehrere, ist das Urteil unwiderruflich: Das Ergebnis lautet permerror, sofort, noch bevor der erste Mechanismus überhaupt gelesen wird.

Diese Entscheidung ist keine grundlose Strenge. Zwei Einträge können sich widersprechen — einer endet auf -all (hartes Scheitern), der andere auf ~all (weiches Scheitern): Welcher sollte gelten? Ein stilles Zusammenführen würde Autorisierungen erweitern, die niemand je beschlossen hat — genau die Art von Mehrdeutigkeit, die sich ein Authentifizierungsprotokoll nicht leisten kann. Der Standard zieht ein lautes, erkennbares Scheitern einer wohlwollenden Auslegung vor, die das Problem nur übertünchen würde.

Eine nützliche Präzisierung: Die Regel gilt pro abgefragtem DNS-Namen. beispiel.de und bounce.beispiel.de sind zwei verschiedene Namen, und jeder trägt völlig legitim seinen eigenen SPF-Eintrag. Das verbotene Duplikat bedeutet zwei v=spf1 auf dem selben Namen. Ein weiteres wissenswertes Relikt: der alte dedizierte DNS-Eintragstyp SPF (Typ 99), von RFC 7208 aufgegeben — heute zählt allein der TXT-Eintrag, und ein alter Typ 99, der noch in einer Zone herumliegt, löst zwar keinen Permerror aus, verdient aber das Aufräumen.

Wie das Duplikat entsteht — fast immer gleich

Das dominierende Szenario ist von entwaffnender Banalität. Jeder Versanddienstleister — Marketingplattform, Rechnungswerkzeug, Transaktionsdienst — liefert eine Einrichtungsdokumentation, die sinngemäß sagt: „diesen TXT-Eintrag hinzufügen: v=spf1 include:dienstleister.example ~all". Die Dokumentation präsentiert „ihren" Eintrag, als wäre er allein auf der Welt; ein eiliger Administrator befolgt die Anweisung wortwörtlich, klickt in der DNS-Konsole auf „Eintrag hinzufügen" … und erzeugt das Duplikat, wo doch der bestehende Eintrag hätte geändert werden müssen.

Die Migrationen erledigen den Rest. Ein Wechsel des E-Mail-Hosters findet statt, und der alte Eintrag wird „sicherheitshalber" nie gelöscht; sechs Monate später weiß niemand mehr, welcher maßgeblich ist. Hinzu kommen die Hosting-Panels, die beim Anlegen einer Zone automatisch einen Standard-SPF erzeugen, die bei einer Übernahme zusammengelegten Zonen und der große Organisationsklassiker: mehrere Hände am selben DNS. Das Marketing schließt auf seiner Seite Brevo oder Mailchimp an, während die IT auf ihrer Seite Microsoft 365 verwaltet; jedes Team fügt „seinen" TXT-Eintrag hinzu, und die Zone endet mit zwei v=spf1, ohne dass eines der beiden Teams aus eigener Sicht einen Fehler gemacht hätte.

Die genaue Strafe: Permerror, und was DMARC daraus macht

Ein permerror ist kein gewöhnliches Scheitern: Es ist das Urteil „nicht interpretierbare Konfiguration", reserviert für permanente Fehler, die auch ein erneuter Versuch nie beheben wird — im Gegensatz zum temperror eines vorübergehend unerreichbaren DNS-Servers. Was dieses Urteil genau umfasst, samt seinen anderen möglichen Ursachen, verdient einen eigenen Artikel; hier zählt die operative Übersetzung: SPF erzeugt für die Domain nie wieder ein „pass", ganz gleich, welche Quelle sendet.

Auf der DMARC-Seite ist die Konsequenz mechanisch. DMARC validiert eine Nachricht, wenn SPF oder DKIM ein positives, mit der sichtbaren Absenderdomain ausgerichtetes Ergebnis liefert. Da ein Permerror kein Pass ist, verschwindet das SPF-Standbein von DMARC schlicht und einfach: Die gesamte Authentifizierung ruht fortan allein auf DKIM. Flüsse, die DKIM mit einer ausgerichteten Domain signieren, überleben; alle anderen — ein unsigniertes Transaktionswerkzeug, ein Anwendungsserver, ein Multifunktionsdrucker — kippen in ein vollständiges DMARC-Scheitern. Unter p=quarantine oder p=reject bedeutet das Spamordner oder glatte Abweisung, und manche Empfänger bestrafen den Permerror zusätzlich für sich genommen, unabhängig von DMARC.

Das Heimtückischste: Das Duplikat zerstört rückwirkend. Der zweite Eintrag ergänzt den ersten nicht, er hebt ihn mit auf — die historischen Autorisierungen hören im selben Moment auf, gelesen zu werden, wie die neuen. Bei p=none passiert nichts Sichtbares, und nur die Berichte verraten das Problem; bei p=reject ist es ein sofortiger Produktionsvorfall für jeden Fluss, der allein an SPF hing.

Die Diagnose in zwei Minuten: dig, dann die Berichte

Die Erstkontrolle passt in einen Befehl:

dig +short TXT beispiel.de
"v=spf1 include:spf.protection.outlook.com -all"
"v=spf1 include:sendgrid.net ~all"

Das Zählen ist die Diagnose: Zwei Zeilen, die mit v=spf1 beginnen, bedeuten das Duplikat, und jede Prüfung der Domain liefert Permerror. Eine einzige Zeile: Die Ursache liegt woanders. Unter Windows leistet nslookup -type=TXT beispiel.de denselben Dienst. Die vollständige Methode zur Prüfung eines SPF-Eintrags behandelt die Befehlsvarianten und die Lesefallen.

Die aggregierten DMARC-Berichte liefern den zweiten Blickwinkel, unbezahlbar, wenn das Duplikat kommt und geht oder bereits behoben wurde: Ein SPF-Permerror, der alle Quellen gleichzeitig trifft, ist die Signatur eines Domain-Problems, nicht die eines bestimmten Absenders. Die Historie liefert sogar das genaue Datum des Umschlagens — der Tag, an dem sämtliche Zeilen von pass auf permerror wechseln, ist der Tag, an dem der zweite Eintrag veröffentlicht wurde. Zuletzt ein Detail der Geduld: Nach der Korrektur servieren die DNS-Caches beide Einträge weiter, bis die TTL abläuft; eine unmittelbar nach der Änderung gestartete Diagnose kann einige Stunden lang lügen.

Die richtige Zusammenführung: ein Eintrag, ein einziges `all`

Die Reparatur besteht nicht darin, einen Eintrag auszuwählen und den anderen zu löschen — beide enthalten in der Regel legitime Autorisierungen —, sondern darin, sie zu einem einzigen zu verschmelzen. Die Methode: die Mechanismen beider Einträge inventarisieren (include:, ip4:, ip6:, a, mx), sie hinter einem einzigen führenden v=spf1 versammeln, Dubletten entfernen und mit einem einzigen all abschließen. Auf dem obigen Beispiel wird der konsolidierte Eintrag zu:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Drei Zusammenführungsregeln wehren böse Überraschungen ab. Erstens: Das abschließende all ist einmalig und beendet die Auswertung — alles, was nach dem ersten angetroffenen all steht, wird von den Prüfern ignoriert; ein dahinter platziertes include wäre toter Buchstabe. Zweitens: Endeten die beiden Einträge unterschiedlich (-all auf der einen, ~all auf der anderen Seite), muss die Wahl des Qualifizierers bewusst getroffen werden — ~all während einer Beobachtungsphase, -all, sobald das Quelleninventar gereift ist. Drittens: Die Mechanismen werden von links nach rechts gelesen; die volumenstärksten Quellen an den Anfang zu stellen erspart bei jeder einzelnen Prüfung ein paar unnötige Auflösungen.

Die Zusammenführung ist auch der richtige Moment zum Aufräumen: Ein include eines vor zwei Jahren verlassenen Dienstleisters hat im konsolidierten Eintrag nichts verloren. Und eine zwingende Wachsamkeit: Zwei Einträge zu addieren addiert auch ihre DNS-Auflösungen, und die Obergrenze von zehn DNS-Abfragen gilt für den verschmolzenen Eintrag — dieses Limit zu reißen würde einen Permerror auf einem anderen Weg neu erschaffen, ausgerechnet dem, den die Zusammenführung gerade geschlossen hatte.

Mehrere Zeichenketten in einem TXT: das falsche Duplikat, das gültig ist

Eine dig-Ausgabe kann zu Unrecht beunruhigen:

"v=spf1 include:spf.protection.outlook.com " "include:sendgrid.net -all"

Zwei Blöcke in Anführungszeichen, aber auf derselben Zeile: Es handelt sich um einen einzigen TXT-Eintrag, zusammengesetzt aus mehreren Zeichenketten. Das DNS begrenzt jede Zeichenkette auf 255 Bytes; RFC 7208 sieht ausdrücklich vor, dass ein Eintrag mehrere davon enthalten darf, die der Prüfer vor der Auswertung aneinanderfügt — ohne ein Leerzeichen einzufügen. Es ist der Standardmechanismus, um über die 255 Zeichen hinauszukommen, im Detail behandelt in dem Artikel zur Längenbegrenzung eines SPF-Eintrags.

Die visuelle Unterscheidung ist also einfach: Zwei Zeilen, die mit v=spf1 beginnen, sind zwei Einträge, also Permerror; zwei Zeichenketten in Anführungszeichen auf einer Zeile sind ein Eintrag, also völlig gültig. Der zweite Fall birgt eine einzige eigene Falle: Da die Verkettung ohne Trennzeichen erfolgt, klebt ein fehlendes Leerzeichen am Kettenende zwei Mechanismen zu einem absurden Token zusammen (…outlook.cominclude:…) — ein Syntaxfehler, der seinerseits ebenfalls im Permerror enden würde.

Die Prävention: eine Prüfung bei jedem neuen Werkzeug

Da das Duplikat fast immer prozeduralen Ursprungs ist, ist es die Gegenmaßnahme auch. Die goldene Regel passt in einen Satz: „einen Versanddienstleister hinzufügen" heißt niemals „einen Eintrag hinzufügen", sondern immer „den bestehenden Eintrag ändern". In die Einführungsprozedur jedes neuen Werkzeugs geschrieben, beseitigt dieser eine Satz die Ursache Nummer eins des Duplikat-Permerrors.

Drei Gewohnheiten vervollständigen das Dispositiv. Ein einziger Eigentümer der DNS-Zone — oder mindestens eine systematische Überprüfung der Änderungen —, damit Marketing und IT nicht länger jeder in seiner Ecke veröffentlichen. Eine dig-Kontrolle nach jeder Zonenänderung, zum Preis von zehn Sekunden. Und eine kontinuierliche Überwachung der DMARC-Berichte: Ein Permerror, der gleichzeitig auf allen Quellen auftaucht, ist ein Duplikat-Alarm, erkennbar noch am selben Tag statt erst in dem Moment, in dem die Zustellbarkeit einbricht. Organisationen, die ein Inventar ihrer autorisierten Versender pflegen — das Fundament jeder ernsthaften DMARC-Remediation —, fangen das Duplikat übrigens schon vor seiner Veröffentlichung ab: Das neue Werkzeug läuft über das Inventar, und das Inventar läuft über den einen einzigen Eintrag.

Fazit

RFC 7208 duldet einen SPF-Eintrag pro Domainname und keinen mehr: Ab dem zweiten v=spf1 liefert jede Prüfung Permerror, SPF hört für die Domain auf zu existieren, und DMARC ruht allein auf DKIM — unter p=reject mit glatter Abweisung jedes unsignierten Flusses. Das Duplikat entsteht fast immer aus einer wortwörtlich befolgten Dienstleister-Dokumentation, aus einer unvollendeten Migration oder aus zwei Teams, die veröffentlichen, ohne sich abzustimmen. Die Diagnose passt in ein dig TXT — die v=spf1-Zeilen zählen — und in die Berichte, in denen ein gleichzeitiger Permerror über alle Quellen das Problem signiert. Die Reparatur ist eine Verschmelzung: ein einziger Eintrag, deduplizierte Mechanismen, ein einziges abschließendes all und ein Auge auf der Obergrenze der zehn DNS-Auflösungen. Mehrere Zeichenketten innerhalb eines TXT-Eintrags wiederum sind gültig — was eine Domain verurteilt, ist das Duplikat von Einträgen, nicht die Aufteilung in Zeichenketten.

Ob eine Domain ein Duplikat trägt — oder irgendeinen anderen SPF-, DKIM- oder DMARC-Defekt —, zeigt in dreißig Sekunden die kostenlose DMARC-Analyse, mit sofortigem Urteil und dekodierten Einträgen als Beleg. Und damit das nächste vom Marketing angeschlossene Werkzeug die Domain nicht unbemerkt zurück in den Permerror kippt, richtet das Anlegen eines Kontos die kontinuierliche Überwachung der Berichte ein: Das Duplikat von morgen wird noch am selben Tag entdeckt, nicht erst beim nächsten Einbruch der Zustellbarkeit.