SPF -all oder ~all: Wo ist der Unterschied und was solltest du wählen

Am Ende fast jedes SPF-Eintrags steht ein kleiner Mechanismus, der alles verändert: -all, ~all, manchmal ?all oder — Katastrophe — +all. Das ist die abschließende Qualifizierung: Sie sagt dem Empfangsserver, was er mit einer Nachricht tun soll, deren IP in keinem Mechanismus deines Eintrags auftaucht. Die Wahl zwischen -all und ~all kommt immer wieder auf und ist von Missverständnissen umgeben. Dieser Leitfaden erklärt genau, was jeder Qualifizierer bedeutet, was die Empfänger damit tun, wie sie mit DMARC zusammenspielen und welchen du veröffentlichen solltest.

Die vier Qualifizierer, erklärt

Vor all (das alles „auffängt", was vorher nicht gematcht hat) steht ein Symbol, das dessen Bedeutung festlegt:

• -all (hardfail). „Jeder nicht gelistete Server ist NICHT berechtigt, für diese Domain zu versenden." Das ist die starke Aussage, die einer Domain, die alle ihre Quellen kennt und beherrscht.
• ~all (softfail). „Ein nicht gelisteter Server ist wahrscheinlich illegitim, weise ihn aber nicht klar ab — markiere ihn nur als verdächtig." Das ist eine vorsichtige, mittlere Position.
• ?all (neutral). „Ich äußere mich nicht zu nicht gelisteten Servern." Damit sagt dein SPF praktisch gar nichts aus. In der Produktion zu vermeiden.
• +all (pass). „JEDER Server ist berechtigt, für meine Domain zu versenden." Das ist ein schwerer Fehler (siehe unten): Du erklärst selbst, dass die ganze Welt dich usurpieren darf.

Was die Empfänger damit tun

Die Theorie zählt nur durch ihre praktische Wirkung. Gegenüber einer Nachricht, deren IP nicht autorisiert ist:

• mit -all hat der Empfänger ein klares Signal, um hart abzulehnen oder zu filtern;
• mit ~all hat er ein weiches Signal: Die meisten Server lehnen nicht allein wegen eines Softfails ab, sie nutzen es als einen Indikator unter mehreren (oft, um Richtung Junk-Ordner zu schieben, nicht um zu blockieren);
• mit ?all hat er kein verwertbares Signal;
• mit +all hat er ein Signal … das den Fälscher bestätigt. Katastrophal.

Merke dir das Wesentliche: -all ist die einzige Qualifizierung, die klar sagt „was nicht auf meiner Liste steht, bin nicht ich".

-all vs. ~all: die eigentliche Debatte

Warum bleiben so viele Domains bei ~all, obwohl -all das Ziel ist? Aus Angst, genau wie beim Hochfahren der DMARC-Policy. Solange ein Team nicht sicher ist, alle seine legitimen Versandquellen gelistet zu haben, fürchtet der Wechsel zu -all, die eigene Mail zu blockieren (eine vergessene Plattform, ein neues Tool). Das ~all ist dann ein Kompromiss: Es signalisiert Strenge, ohne die klare Ablehnung zu riskieren.

Dieser Kompromiss ist in der Übergangsphase akzeptabel, solange man seine Quellen inventarisiert und ausrichtet. Aber er darf kein Dauerzustand werden: Eine ewig bei ~all blockierte Domain gleicht einer bei p=none blockierten Domain — sie dokumentiert eine gute Absicht, ohne den Schutz zu Ende zu führen. Das Ziel bleibt -all.

Der fatale Fehler: +all

Ein klares Wort zu +all, weil man es öfter trifft, als man sollte — meist versehentlich, ein unglücklicher Copy-Paste oder ein Missverständnis. +all bedeutet „jede IP ist berechtigt, für meine Domain zu versenden". Du verwandelst dein SPF, das eigentlich einschränken soll, in eine universelle Erlaubnis. Jeder Spammer oder Fälscher besteht dann dein SPF. Das ist strikt schlimmer, als gar kein SPF zu haben, denn es gibt eine falsche Absicherung. Wenn du +all in einem Eintrag siehst, korrigiere es sofort — das ist eine weit offene Tür.

Das Zusammenspiel mit DMARC ändert alles

Hier die Nuance, die viele Artikel verpassen. Wenn DMARC eingerichtet und durchgesetzt ist, entscheidet die DMARC-Policy (p=quarantine, p=reject) über das Schicksal nicht authentifizierter Mail — nicht direkt der SPF-Qualifizierer. DMARC stützt sich auf das Alignment (SPF oder DKIM ausgerichtet mit deinem From:), und deine Policy verfügt.

Folge: Für eine Domain bei p=reject mit sauberem Alignment wird die Debatte -all vs. ~all weniger kritisch, weil DMARC ohnehin entscheidet. Aber das heißt nicht, dass der Qualifizierer keine Bedeutung mehr hat:

• nicht alle Empfänger setzen DMARC durch — ein SPF mit -all schützt auch bei diesen;
• ein striktes SPF ist ein Reputationssignal, das zu deiner DMARC-Policy passt;
• ~all zu behalten „weil DMARC die Arbeit macht" ist ein unnötiges Nachlassen: Wenn du deine Quellen kennst, dann sag es auch.

Gute Hygiene bedeutet also, -all und p=reject anzustreben: Die beiden Schichten verstärken sich, sie ersetzen sich nicht. Der Weg zu dieser doppelten Strenge ist in p=reject erreichen, ohne deine E-Mails zu zerbrechen beschrieben.

Ein konkretes Beispiel

Stell dir zwei quellenseitig identische Domains vor, aber eine bei ~all und die andere bei -all. Ein Angreifer usurpiert ihr From: von einem beliebigen Server aus.

• Bei der Domain ~all: Ein Empfänger ohne DMARC sieht einen Softfail und kann die Nachricht je nach seiner Anti-Spam-Policy trotzdem zustellen (in den Posteingang oder Junk). Die Usurpation hat eine Chance durchzukommen.
• Bei der Domain -all: Derselbe Empfänger hat ein klares SPF-Fehlsignal, und die Ablehnung ist deutlich wahrscheinlicher.

Füge auf beiden Seiten DMARC mit p=reject hinzu, und die Usurpation wird in beiden Fällen abgewiesen — aber die Domain -all bleibt bei den Empfängern, die DMARC nicht durchsetzen, besser geschützt. Das -all ist nie ein Nachteil; es hat nur dann einen Haken, wenn deine Quellen unvollständig sind.

Wie du risikofrei von ~all zu -all wechselst

Die Methode ist dieselbe wie beim Verschärfen von DMARC und stützt sich auf Daten:

1. Inventarisiere alle deine Versandquellen aus deinen aggregierten Berichten — sie zeigen jede IP, die in deinem Namen versendet.
2. Stelle sicher, dass sie alle in deinem SPF stehen (oder in DKIM ausgerichtet sind), ohne das Limit von zehn Lookups zu überschreiten.
3. Wechsle zu -all, sobald du sicher bist, dass nichts Legitimes außerhalb der Liste fällt.
4. Überwache einige Tage: Keine legitime Quelle darf plötzlich scheitern.

Solange Schritt 1 nicht in Ruhe erledigt ist, bleib bei ~all — aber mit dem klaren Ziel, zu wechseln.

Der Fall der Domains, die nicht versenden

Ein Fall verdient eine eigene Erwähnung: die Domains, von denen du keinerlei Mail versendest — geparkte Domains, defensive Markendomains, alte aufbewahrte Domains. Für sie ist die abschließende Qualifizierung kein Kompromiss, sondern eine Selbstverständlichkeit: Veröffentliche v=spf1 -all, ohne einen einzigen Mechanismus davor. Damit erklärst du, dass kein Server berechtigt ist, in ihrem Namen zu versenden — was genau zutrifft, da du nicht versendest. Gekoppelt mit einem DMARC p=reject (und, mit DMARCbis, mit np=reject für nicht existierende Subdomains) ist das die strengste und am einfachsten zu haltende Konfiguration, denn sie erfordert keinerlei Wartung: Es gibt keine Quelle zu verfolgen.

Das ist umso wichtiger, als schlafende Domains bevorzugte Usurpationsziele sind, gerade weil niemand sie überwacht. Ein Angreifer liebt eine Markendomain, die du besitzt, aber zu schützen vergessen hast. Das v=spf1 -all ist deine erste Verteidigungslinie, kostenlos und endgültig. Lass keine Domain, die du besitzt, ohne diese Zeile — das ist eine der Sicherheitsmaßnahmen mit dem besten Aufwand-Nutzen-Verhältnis überhaupt, und sie ist in einer Minute gesetzt.

Deinen Qualifizierer prüfen

Ein kurzer Blick genügt, um zu wissen, wo du stehst. Unser kostenloser Analyzer liest deinen Eintrag, zeigt dir deine abschließende Qualifizierung und meldet gefährliche Konfigurationen wie +all. Für die Details der Prüfungen siehe wie du deinen SPF-Eintrag prüfst. Und wenn dein SPF eher einen Fehler als ein einfaches Ergebnis zurückgibt, siehe den PermError, was er bedeutet.

Häufige Fragen

Kann -all legitime Mail blockieren? Nur wenn eine legitime Quelle nicht in deinem SPF gelistet ist (und nicht in DKIM ausgerichtet). Deshalb wechselt man zu -all nachdem man alle seine Quellen inventarisiert und gelistet hat, nicht davor.

Wenn ich DMARC mit p=reject habe, hat der Qualifizierer dann noch Bedeutung? Weniger, aber ja. DMARC entscheidet für die Empfänger, die es durchsetzen; -all schützt zusätzlich bei denen, die es nicht durchsetzen, und bleibt ein Signal der Strenge.

Ist ~all „sicherer" als -all? Sicherer für dich kurzfristig (weniger Risiko, deine eigene Mail zu blockieren, wenn dein Inventar unvollständig ist), aber weniger schützend gegen Usurpation. Es ist ein Übergangskompromiss, kein Ziel.

Warum empfiehlt mein Dienstleister ~all? Oft aus Vorsicht, um nicht die Mail von Kunden zu zerbrechen, deren Quelleninventar unsicher ist. Das ist zum Start vertretbar, hindert dich aber nicht daran, -all anzustreben, sobald du deinen Bestand beherrschst.

Was tun, wenn ich ?all finde? Betrachte es als nahezu gleichwertig mit keinem nützlichen SPF und ersetze es durch ~all (Übergang) und dann -all. ?all behauptet nichts und bringt keinen Schutz.

Der häufigste Konfigurationsfehler rund um all

Neben der Wahl zwischen -all und ~all gibt es einen technischen Fehler, der immer wieder auftaucht und den Effekt deiner Qualifizierung stillschweigend zunichtemacht: Mechanismen nach all zu platzieren. SPF wird von links nach rechts ausgewertet, und all ist per Definition ein Auffangmechanismus, der auf jede IP matcht. Alles, was du danach schreibst, wird schlicht nie erreicht — es ist toter Code in deinem Eintrag. Sieht dein SPF also aus wie v=spf1 -all include:spf.protection.outlook.com, dann matcht -all sofort und dein include wird nie ausgewertet: Deine eigenen legitimen Server scheitern an SPF. Der all-Mechanismus muss immer der letzte deines Eintrags sein, ausnahmslos. Wenn du deinen Eintrag prüfst, vergewissere dich, dass nichts hinter all steht.

Ein verwandter Fehler ist, mehrere all-Mechanismen mit unterschiedlichen Qualifizierern in denselben Eintrag zu setzen — etwa ein ~all in der Mitte und ein -all am Ende, weil man zwei Einträge zusammengeführt hat, ohne aufzuräumen. Auch hier gewinnt der erste all, und der zweite ist wirkungslos. Ein sauberer Eintrag hat genau einen all-Mechanismus, am Ende, mit dem gewünschten Qualifizierer davor.

Warum die Wahl weit über SPF hinausreicht

Die abschließende Qualifizierung ist auf den ersten Blick ein winziges Detail — ein einzelnes Zeichen —, aber sie ist in Wirklichkeit eine Aussage über deine gesamte Sicherheitshaltung. Ein Domaininhaber, der -all veröffentlicht, sagt der Welt: „Ich kenne alle meine Versandquellen und stehe für sie ein." Das ist genau die Haltung, die auch DMARC mit p=reject und, wo relevant, BIMI mit einem verifizierten Logo verkörpert. Diese Signale verstärken sich gegenseitig: Ein Domain, das bei SPF hart, bei DMARC durchsetzend und bei DKIM sauber ausgerichtet ist, baut über die Zeit eine kohärente Reputation auf, die von den großen Providern belohnt wird. Umgekehrt sendet ein ewiges ~all neben einem ewigen p=none das Signal einer Organisation, die die Absicht hatte, aber nie den Schritt zu Ende ging — und Angreifer lesen dieses Signal genauso gut wie legitime Provider.

Deshalb lohnt es sich, -all nicht als isolierte technische Einstellung zu betrachten, sondern als Teil eines Ganzen. Wenn du deine Quellen inventarisiert, dein DKIM ausgerichtet und deine DMARC-Policy auf reject gehoben hast, ist der Wechsel zu -all der natürliche, fast zwangsläufige letzte Schliff — nicht ein zusätzliches Risiko, sondern die logische Vollendung der Arbeit, die du ohnehin schon geleistet hast.

Lass Thomas deine Qualifizierung absichern

Zu wissen, ob du zu -all wechseln kannst, ohne deine Mail zu zerbrechen, setzt voraus, alle deine Quellen zu kennen. Thomas, dein virtueller CISO, benennt sie aus deinen Berichten, prüft, dass sie alle von SPF oder DKIM abgedeckt sind, und sagt dir den genauen Moment, an dem du risikofrei zu -all wechseln kannst — und warnt dich, wenn ein gefährliches +all oder ?all in deinem Eintrag herumliegt.

Analysiere deine Domain kostenlos → oder erstelle ein Konto, um mit Zuversicht zu -all zu wechseln.