E-Mail-Authentifizierung sind drei DNS-Records, veröffentlicht auf deiner eigenen Domain, mit denen ein empfangender Mailserver entscheiden kann, ob eine Nachricht wirklich von dir stammt. SPF nennt die Server, die senden dürfen. DKIM signiert jede Nachricht, sodass Manipulation auffällt. DMARC sagt, was zu tun ist, wenn die ersten beiden nicht zur Adresse im From-Header passen, und bittet um Berichte darüber.
Alle drei zu veröffentlichen war früher gute Praxis. Seit Februar 2024 ist es bei den größten Mailbox-Providern eine Zustellbedingung, und die meisten Domains sind noch nicht fertig. Über die Domains, die wir für den Unspam 2026 Email Deliverability Benchmark testen, veröffentlichen 93 % einen gültigen SPF-Record und 90 % signieren mit einem funktionierenden DKIM-Key, aber nur 48 % veröffentlichen eine DMARC-Policy. Die Lücke zwischen 90 und 48 ist dieser ganze Artikel.
Wo deine eigene Domain steht, siehst du in etwa dreißig Sekunden mit einem kostenlosen E-Mail-Health-Check, der alle drei Records auf einmal liest und dir sagt, auf welche davon ein Empfänger tatsächlich reagieren würde.
Die drei Records beantworten drei verschiedene Fragen
Ein empfangender Server stellt nicht eine Frage zu deiner Mail. Er stellt drei, und jeder Record beantwortet genau eine davon.
| Record | Die Frage, die er beantwortet | Was er ist |
|---|---|---|
| SPF | Durfte dieser Server für diese Domain senden? | Ein TXT-Record mit den erlaubten Absendern |
| DKIM | Wurde diese Nachricht verändert, und wer hat sie signiert? | Ein öffentlicher Schlüssel im DNS, plus eine Signatur im Header |
| DMARC | Was tue ich, wenn die Antworten nicht zur From-Adresse passen? | Ein TXT-Record mit einer Policy und einer Reporting-Adresse |
Die Reihenfolge zählt, weil DMARC nicht eigenständig ist. Es ist eine Entscheidungsschicht über den anderen beiden und hat nichts, worauf es reagieren könnte, bis mindestens einer davon besteht. Eine Domain mit DMARC, aber ohne funktionierendes SPF oder DKIM, hat eine Anweisung veröffentlicht, der nie gefolgt werden kann.
SPF veröffentlicht, welche Server für deine Domain senden dürfen
SPF ist eine Liste der Server, die du autorisiert hast, veröffentlicht als DNS-TXT-Record auf deiner eigenen Domain. Wenn ein Server eine Verbindung aufbaut, um Mail zuzustellen, die angeblich von dir kommt, schlägt der Empfänger diese Liste nach und prüft, ob die verbindende IP-Adresse darauf steht.
Ein Record sieht so aus: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Jedes include delegiert an die Liste einer anderen Organisation, und genau so autorisierst du Google Workspace und deine Marketingplattform gleichzeitig, ohne deren IP-Adressen selbst zu pflegen.
Zwei Grenzen erwischen viele. Die erste: SPF erlaubt höchstens zehn DNS-Lookups pro Prüfung, und jedes include verbraucht mindestens einen. Wer darüber liegt, bekommt einen permanenten Fehler, und die meisten Empfänger behandeln einen permanenten Fehler als Fehlschlag und nicht als fehlenden Record. Die zweite: SPF bricht beim Weiterleiten. Wenn eine Mailingliste oder eine Weiterleitungsadresse deine Nachricht weitergibt, ist der verbindende Server ihrer und nicht deiner, und SPF scheitert ohne dein Zutun. Genau diese zweite Grenze ist der Grund, warum es DKIM gibt. Unser Leitfaden zu SPF-Records behandelt die Syntax und das Lookup-Budget vollständig. Dass SPF beim Weiterleiten bricht, ist auch das Problem, für das ARC gebaut wurde, und unser Leitfaden zu ARC behandelt, warum dieses Experiment eingestellt wird.
DKIM signiert die Nachricht selbst, deshalb überlebt sie die Weiterleitung
DKIM hängt an jede ausgehende Nachricht eine kryptografische Signatur, erzeugt mit einem privaten Schlüssel, den deine Versandplattform hält. Du veröffentlichst den passenden öffentlichen Schlüssel im DNS, und der Empfänger prüft damit die Signatur.
Weil die Signatur die Header und den Body abdeckt und nicht die Verbindung, übersteht DKIM das Weiterleiten. Sie beweist außerdem, dass die Nachricht unterwegs nicht verändert wurde, was SPF überhaupt nicht kann. Diese Kombination macht sie zum stärkeren der beiden Signale und zu dem, auf das sich DMARC am ehesten stützt, wenn deine Mail besteht.
Jede seriöse Versandplattform rotiert Schlüssel nach Plan, und der Selector im Header ist das, was einer Domain mehrere Schlüssel gleichzeitig erlaubt: s1._domainkey.example.com und s2._domainkey.example.com können beide aktiv sein, und so passiert eine Rotation ohne Lücke. Ein Empfänger liest den Selector aus der Signatur und schlägt nur diesen Schlüssel nach. Verwende 2048-Bit-Schlüssel statt 1024-Bit; die kürzere Länge validiert zwar noch, gilt aber nicht mehr als ausreichend. Das vollständige Record-Format steht in unserem Leitfaden zu DKIM-Signaturen. Wie lang ein Schlüssel sein sollte und wie eine Aufrüstung ihn still verkürzt, steht in unserem Leitfaden zur DKIM-Schlüssellänge.
DMARC funktioniert nur, wenn SPF oder DKIM zu deiner From-Domain passt
Alignment ist der Teil, den die meisten Einführungen auslassen, und dort scheitern funktionierende Records. DMARC fragt nicht, ob SPF oder DKIM bestanden hat. Es fragt, ob eines von beiden für dieselbe Domain bestanden hat, die dein Leser im From-Header sieht.
Deine Marketingplattform kann jede Nachricht einwandfrei mit ihrer eigenen Domain signieren und SPF auf ihrer eigenen Versanddomain bestehen, und DMARC scheitert trotzdem, weil keiner der beiden Identifier deiner ist. Die Lösung ist, diese Plattform so zu konfigurieren, dass sie als deine Domain signiert, was jede ernstzunehmende Versandplattform unterstützt und viele Kunden nie einschalten. Die Adresse, die SPF authentifiziert, ist der Umschlagabsender und nicht die, die deine Leser sehen, was unser Leitfaden zum Return-Path vollständig behandelt.
Sobald ein Empfänger ein Alignment-Ergebnis hat, sagt ihm deine Policy, was zu tun ist:
p=noneheißt tu nichts und schick mir Berichte. Das ist die Startposition, nicht das Ziel.p=quarantineheißt leg scheiternde Mail in den Spam-Ordner.p=rejectheißt weise sie an der Tür ab.
Zwei Dinge an DMARC haben sich im Mai 2026 geändert, und die meiste Dokumentation ist noch nicht nachgezogen. RFC 9989 hat RFC 7489 ersetzt und macht DMARC zu einer Spezifikation auf dem Standards Track statt zu einem informationellen Dokument, und er hat die Tags pct, ri und rf zurückgezogen. Trägt dein Record pct unter 100 neben quarantine oder reject, ist deine Durchsetzung jetzt strenger als konfiguriert, ohne dass jemand das DNS angefasst hat. Unser Leitfaden zu DMARC-Records geht jedes Tag durch.
Mailbox-Provider behandeln DMARC seit 2024 nicht mehr als optional
Jeder Leitfaden, der dir sagt, DMARC sei empfohlen, aber nicht erforderlich, beschreibt die Welt vor Februar 2024. In diesem Monat begannen Google und Yahoo beide, von Massenversendern an ihre eigenen Postfächer eine DMARC-Policy zu verlangen. Apple folgte im Februar 2025 und Outlook.com im Mai 2025.
Vier Details lohnen sich genau, weil sie oft falsch wiedergegeben werden:
- Googles Schwelle liegt bei 5.000 Nachrichten pro Tag an persönliche Gmail-Adressen. Outlook.com nutzt dieselbe Zahl für seine Consumer-Postfächer. Yahoo hat es öffentlich abgelehnt, überhaupt eine zu nennen, behandle jede Zahl, die Yahoo zugeschrieben wird, also mit Misstrauen.
p=noneerfüllt die Anforderung. Die Provider verlangen eine veröffentlichte Policy, keine Durchsetzung. Bei none anzufangen ist konform und außerdem der richtige Weg zu beginnen.- Microsofts Regel gilt für Outlook.com-Consumer-Mail, nicht für Microsoft-365-Tenants. Wenn du an Unternehmen sendest, beschreibt diese Anforderung deine Empfänger nicht.
- Für Spam-Beschwerderaten gilt eine eigene Schwelle, 0,3 % bei Google und Yahoo, und eine Rate unter 0,1 % ist das, was Google empfiehlt statt fordert.
Authentifizierung ist notwendig, aber nicht hinreichend. Eine perfekt authentifizierte Nachricht landet trotzdem im Spam, wenn der Inhalt einen Filter auslöst, was separat bewertet wird und das Thema unseres Leitfadens zu SpamAssassin-Scores ist.
Fünf Arten, wie diese Records scheitern und dabei korrekt aussehen
Jeder Fehler unten erzeugt einen Record, der für einen Menschen in Ordnung aussieht und bei einem Empfänger nichts tut. Es sind die, um die herum unser eigener Analyzer gebaut wurde, grob nach Häufigkeit geordnet.
Zwei SPF-Records auf einer Domain. Einen zweiten TXT-Record zu veröffentlichen, statt den ersten zu bearbeiten, führt sie nicht zusammen. Das Ergebnis ist ein permanenter Fehler, und die meisten Empfänger behandeln einen permanenten Fehler als Fehlschlag und nicht als fehlenden Record. Eine Domain, ein SPF-Record, immer.
Mehr als zehn DNS-Lookups in der SPF-Kette. Jedes include kostet mindestens einen Lookup, und der Anbieter dahinter kann in seinem eigenen Record mehrere weitere verbrauchen. Vier oder fünf Anbieter reichen, um das Budget zu sprengen. Der Record sieht weiterhin kurz und lesbar aus; er hört schlicht mittendrin auf, ausgewertet zu werden.
Ein Tippfehler im DMARC-Tag sp oder np. Das ist der gemeinste. Eine ungültige Subdomain-Policy verwirft den gesamten Record, samt einem einwandfreien p=reject. v=DMARC1; p=reject; sp=quarintine schützt überhaupt nichts, und ein Checker, der das p meldet, das er lesen konnte, sagt dir, die Domain sei dicht.
Nichts passt zur From-Domain. SPF besteht auf der Domain der Plattform, DKIM signiert mit der Domain der Plattform, beide Prüfungen melden ein Bestehen, und DMARC scheitert trotzdem. Jedes Ergebnis in deinen Logs sieht grün aus. Das ist mit Abstand der häufigste Grund, warum eine sorgfältig konfigurierte Domain ein Jahr lang auf p=none sitzt.
Eine Policy p=none mit Schutz verwechseln. None ist die Anweisung, nichts zu tun. Es ist der richtige Ort zum Anfangen und der falsche zum Bleiben, und eine Domain, die seit zwei Jahren dort steht, veröffentlicht eine Bitte um Berichte, die niemand liest.
Veröffentliche sie der Reihe nach, weil DMARC von den anderen beiden abhängt
Die folgende Reihenfolge ist keine Vorliebe. Wer sie umdreht, veröffentlicht eine Policy, unter der nichts liegt.
- Veröffentliche SPF und bestätige, dass es besteht. Ein Record pro Domain, unter zehn Lookups, endend auf
~alloder-all. Zwei SPF-Records auf einer Domain sind ein permanenter Fehler, keine Zusammenführung. - Schalte DKIM-Signierung bei jeder Plattform ein, die in deinem Namen sendet. Dein ESP, dein CRM, dein Helpdesk, dein Rechnungstool. Jede veröffentlicht ihren eigenen Selector.
- Prüfe, dass mindestens eines davon zu deiner From-Domain passt. Das ist der Schritt, der übersprungen wird, und ihn zu überspringen macht alles danach dekorativ.
- Veröffentliche DMARC mit
p=noneund einer Reporting-Adresse. Du sammelst Belege, du setzt noch nichts durch. - Lies die Berichte zwei bis vier Wochen lang. Du suchst legitime Absender, die du vergessen hattest, denn genau die würde eine durchsetzende Policy blockieren.
- Geh auf
p=quarantine, dann aufp=reject. Erst wenn jede legitime Quelle besteht und passt.
Bei Schritt fünf zählt das Werkzeug, denn rohe DMARC-Berichte kommen als XML und sind von Hand kaum lesbar. Wir haben die Optionen in unserer Übersicht zu DMARC-Monitoring-Tools verglichen, die kostenlosen eingeschlossen. Wenn du nur bestätigen willst, dass dein Record veröffentlicht ist und korrekt geparst wird, genügt ein kostenloser DMARC-Checker.
BIMI zeigt dein Logo im Postfach, und fast niemand erfüllt bisher die Bedingungen
BIMI zeigt das Logo deiner Marke neben deinen Nachrichten in unterstützenden Postfächern, und es ist der einzige dieser Standards, den deine Empfänger sehen können. Es ist auch der einzige, der die anderen zuerst verlangt: Eine Domain muss bereits auf p=quarantine oder p=reject stehen, bevor ein Empfänger das Logo anzeigt.
Die Verbreitung ist wirklich gering. 99 % der Domains, die wir testen, veröffentlichen überhaupt keinen BIMI-Record, was es zu einer der wenigen verbliebenen Möglichkeiten macht, in einem vollen Postfach anders auszusehen. Gmail verlangt zusätzlich ein Verified Mark Certificate, eine kostenpflichtige Bestätigung, dass dir die Marke am Logo gehört, und das ist der Hauptgrund, warum die Zahl bleibt, wo sie ist.
Behandle BIMI als Belohnung dafür, DMARC fertig gemacht zu haben, und nicht als eigenes Projekt. Wenn du nicht in der Durchsetzung bist, gibt es noch nichts zu konfigurieren.
Was du nach dem Veröffentlichen prüfen solltest
Records driften. Eine Plattform kommt dazu, ohne dass SPF aktualisiert wird, ein Schlüssel wird schlecht rotiert, jemand bearbeitet einen Record von Hand und lässt ein Semikolon weg. Der Fehler ist still, denn nichts in deinem eigenen Mailfluss sagt dir, dass ein Empfänger angefangen hat abzuweisen.
Vier Prüfungen lohnen sich regelmäßig:
- Alle drei Records parsen und sagen, was du denkst. Ein ungültiges
sp- odernp-Tag verwirft einen ansonsten perfekten DMARC-Record vollständig, und ein Checker, der daspmeldet, das er lesen kann, gibt dir ein grünes Siegel für eine offene Domain. - Jede Versandplattform passt weiterhin. Es werden neue Werkzeuge gekauft, und die authentifizieren sich nicht von selbst.
- Deine DMARC-Berichte kommen weiterhin an. Fällt deine Reporting-Adresse aus dem Record, hören die Berichte auf, und nichts kündigt das an.
- Die Nachricht selbst besteht weiterhin. Nur 89 % der Nachrichten, die wir testen, bestehen eine vollständige Zustellbarkeitsprüfung, 9 % holen sich eine Warnung und 2 % fallen ganz durch, und Authentifizierung ist nur ein Teil dieser Bewertung.
Die drei Records richtig hinzubekommen ist die Arbeit mit der größten Hebelwirkung in der Zustellbarkeit, denn es ist der einzige Teil, den ein Empfänger prüft, bevor er ein einziges Wort von dir liest. Wenn die Records mehr sind, als du im Haus behalten willst, kann ein Zustellbarkeits-Consultant den Rollout übernehmen. Sonst mach einen kostenlosen Spam-Test mit einer echten Nachricht und lies die Authentifizierungsergebnisse neben den inhaltlichen, was der schnellste Weg ist zu sehen, was ein Empfänger sieht.
