DMARC, SPF und DKIM: Warum Ihre Shop-Mails im Spam landen

SPF, DKIM und DMARC sind drei Einträge im DNS Ihrer Domain, die zusammen drei Fragen beantworten: Wer darf in Ihrem Namen senden (SPF), wurde die Nachricht unterwegs verändert (DKIM) und was soll passieren, wenn beides fehlschlägt (DMARC). Gmail und Yahoo verlangen sie seit Februar 2024 von Massenversendern, Outlook.com seit dem 5. Mai 2025. Fehlen sie oder sind sie unvollständig, landen Bestellbestätigungen und Newsletter im Spam-Ordner — oder werden gar nicht erst angenommen.

1. Warum es fast nie am Text der Mail liegt

Der Ablauf ist in jedem Handelsbetrieb derselbe. Ein Kunde ruft an, weil keine Bestellbestätigung angekommen ist. Der Kundenservice schaut ins Shop-Backend, dort steht die Mail als versendet. Also beginnt die Suche beim Text: zu viele Ausrufezeichen? Zu viele Links? Das Wort „gratis" im Betreff?

Diese Suche geht meist an der Ursache vorbei. Ein empfangender Mailserver prüft eine Nachricht in einer festen Reihenfolge, und der Inhaltsfilter kommt darin ziemlich spät. Zuerst wird geklärt, ob der einliefernde Server überhaupt berechtigt ist, unter Ihrer Domain zu schreiben. Fällt diese Prüfung durch, ist die Formulierung des Betreffs schon nicht mehr entscheidend.

Der Grund für die Verschärfung liegt auf der Hand: Die Absenderadresse einer E-Mail lässt sich frei eintragen. Ohne technische Absicherung kann jeder eine Rechnung im Namen Ihres Shops verschicken. Genau deshalb haben die großen Postfach-Anbieter ihre Anforderungen 2024 und 2025 deutlich angezogen — und das Bundesamt für Sicherheit in der Informationstechnik nennt in seiner Empfehlung vom 26. Mai 2025 als erforderliche Maßnahme ausdrücklich „eine sorgfältigere Umsetzung der Standards SPF, DKIM und DMARC" (Quelle: BSI).

Für Sie hat das zwei Seiten. Die eine ist Zustellbarkeit: Ihre eigenen Mails sollen ankommen. Die andere ist Markenschutz — wer Ihre Domain fälscht, schädigt Ihren Ruf, ohne dass Sie es merken. Wie sich dieser Baustein in ein Gesamtbild einfügt, zeigt unser Leitfaden zur IT-Sicherheit im Mittelstand; hier geht es um den Absender-Teil im Detail.

2. SPF, DKIM, DMARC: drei Fragen, drei Antworten

Die drei Verfahren werden oft als Paket genannt, lösen aber unterschiedliche Probleme. Am schnellsten versteht man sie, wenn man jedes auf die Frage reduziert, die es beantwortet:

SPF steht für „Sender Policy Framework" und ist eine Liste erlaubter Server. DKIM steht für „DomainKeys Identified Mail" und arbeitet mit einer digitalen Unterschrift: Der sendende Dienst signiert die Nachricht mit einem privaten Schlüssel, der passende öffentliche Schlüssel liegt im DNS. DMARC bindet beide zusammen und legt fest, wie der Empfänger reagieren soll.

Der Punkt, an dem die meisten Anleitungen zu kurz greifen, heißt Übereinstimmung — im Original „Alignment". SPF prüft nicht die Adresse, die Ihr Kunde im Postfach sieht, sondern die technische Rücksendeadresse im Briefumschlag. Bei einem externen Versanddienst gehört die häufig dem Anbieter, nicht Ihnen. Der SPF-Test kann also glatt bestehen, während die sichtbare Absenderdomain eine ganz andere ist. DMARC akzeptiert das nicht: Mindestens eine der beiden Prüfungen muss auf Ihre sichtbare Domain zutreffen.

Praktisch heißt das: Ein Dienst, bei dem Sie im Anbieter-Backend nur ein Häkchen bei „SPF eingerichtet" gesetzt haben, ist noch nicht DMARC-tauglich. Erst die eigene DKIM-Signatur unter Ihrer Domain oder eine eigene Rücksendeadresse macht daraus einen Absender, der die Prüfung wirklich besteht.

3. Was Gmail, Yahoo und Outlook heute verlangen

Bis 2023 war E-Mail-Authentifizierung eine Empfehlung. Seit Februar 2024 ist sie für Massenversender eine Zugangsvoraussetzung — bei jedem der drei größten Privatkunden-Anbieter. Die Anforderungen ähneln sich, unterscheiden sich aber in Details, die im Alltag den Ausschlag geben:

Drei Beobachtungen dazu, die im Handel regelmäßig unterschätzt werden.

Erstens ist die Grenze niedriger, als sie klingt. 5.000 Nachrichten pro Tag klingen nach Großversender. In einem Shop mit ein paar hundert Bestellungen täglich summieren sich Bestellbestätigung, Zahlungseingang, Versandavis, Rechnung, Bewertungsanfrage und Newsletter aber schnell in diese Größenordnung — und der Zähler läuft je Anbieter, nicht über alle Postfächer zusammen.

Zweitens ist die Konsequenz bei Microsoft am härtesten. Microsoft hat angekündigt, nicht konforme Nachrichten zunächst in den Junk-Ordner zu leiten und sie anschließend abzuweisen — mit der Fehlermeldung „550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level" (Quelle: Microsoft Tech Community, 2. April 2025, aktualisiert am 30. April 2025). Eine abgewiesene Nachricht landet nirgendwo, auch nicht im Spam-Ordner.

Drittens zählt die Beschwerderate mit. Google verlangt eine in den Postmaster Tools gemessene Spamrate unter 0,30 Prozent und empfiehlt, unter 0,10 Prozent zu bleiben; Yahoo nennt ebenfalls 0,3 Prozent. Technisch saubere Authentifizierung schützt also nicht vor einem schlecht gepflegten Verteiler. Welche Werkzeuge dabei helfen, vergleichen wir im Newsletter-Tool-Vergleich; die inhaltliche Seite — Anmeldung, Willkommensstrecke, Frequenz — behandelt unser Beitrag zum Einstieg ins E-Mail-Marketing mit Automatisierung.

4. Die DNS-Einträge im Klartext

Alle drei Verfahren werden als TXT-Einträge im DNS Ihrer Domain veröffentlicht — dort, wo Sie auch Ihre Webserver-Adresse pflegen. Die folgenden Beispiele sind generisch, aber syntaktisch korrekt aufgebaut:

• SPF: Ein Eintrag pro Domain, nie zwei. Am Ende steht -all („alles andere ist nicht autorisiert") oder ~all („verdächtig, aber nicht ablehnen") — für den Einstieg ~all, dauerhaft -all.
• DKIM: Der Name vor ._domainkey ist der Selektor. Jeder sendende Dienst bekommt einen eigenen — so lässt sich ein einzelner Anbieter später abschalten, ohne die anderen zu berühren.
• DMARC (Beobachtung): Ändert nichts an der Zustellung. rua ist die Adresse für die Sammelberichte, adkim und aspf steuern, wie streng die Domains übereinstimmen müssen (r = relaxed ist der Standard).
• DMARC (scharf): sp gilt für Subdomains, np seit RFC 9989 für nicht existierende Subdomains. Diesen Stand erreichen Sie erst, wenn die Berichte über Wochen keine unbekannten Absender mehr zeigen.

Zwei technische Details lohnen die Aufmerksamkeit. Der DMARC-Eintrag muss mit v=DMARC1 beginnen; steht der Versionstag nicht an erster Stelle, ignorieren Empfänger laut RFC 9989 den kompletten Eintrag. Und für DKIM schreibt RFC 8301 seit 2018 Schlüssel mit mindestens 1.024 Bit vor und empfiehlt 2.048 Bit; der alte Signaturalgorithmus rsa-sha1 darf weder zum Signieren noch zum Prüfen verwendet werden. Wer noch einen sehr alten Selektor aus einer Migration mitschleppt, sollte ihn austauschen.

Ihre DNS-Zone trägt künftig einen weiteren, sich ständig ändernden Eintrag. Wer Zertifikate über den DNS-Weg validieren lässt — bei Wildcard-Zertifikaten ist das der einzige mögliche Weg —, setzt dafür einen TXT-Eintrag unter dem Namen _acme-challenge, und dieser Eintrag wechselt bei jeder Ausstellung. Da eine Domainprüfung seit dem 15. März 2026 nur noch 200 Tage wiederverwendet werden darf und ab 2029 nur noch zehn, wird daraus eine laufende Aufgabe für Ihre DNS-Schnittstelle. Was dahintersteckt, erklären wir im Beitrag zu den neuen SSL-Zertifikatslaufzeiten.

5. Der blinde Fleck im Handel: Ihre Absenderliste

Hier trennt sich der Onlineshop vom Standardfall aus den Anleitungen. Die üblichen Ratgeber gehen von einer Domain mit einem Mailserver aus. Ein Handelsbetrieb hat statt eines Absenders sieben oder acht — und jeder einzelne muss autorisiert sein, sonst kippt später genau seine Sorte Mail.

In unseren Projekten ist diese Liste fast nie vollständig dokumentiert, und das Muster wiederholt sich: Das Newsletter-Tool ist sauber eingerichtet, weil der Anbieter die DNS-Einträge beim Onboarding erzwingt. Die Rechnungsmails aus der Warenwirtschaft laufen dagegen seit Jahren über einen Relay-Server, den einmal jemand eingerichtet hat, der längst nicht mehr im Haus ist. Vier Befunde begegnen uns dabei besonders oft:

• Der vergessene Zweitversender. Ein Dienst wurde vom Marketing angebunden, ohne dass die IT davon erfuhr. Er taucht erst auf, wenn die DMARC-Berichte laufen — oder wenn nach dem Scharfschalten plötzlich die Bewertungsanfragen ausbleiben.
• Zwei SPF-Einträge auf derselben Domain. Beim Anbinden eines neuen Dienstes wird ein zweiter v=spf1-Eintrag angelegt, statt den bestehenden zu erweitern. Das Ergebnis ist kein doppelter Schutz, sondern ein ungültiger Zustand — SPF fällt für alle Absender aus.
• DKIM eingerichtet, aber nie geprüft. Der Selektor steht im DNS, der Dienst signiert trotzdem nicht, weil im Anbieter-Backend der letzte Bestätigungsschritt fehlt. Sichtbar wird das erst im Bericht.
• Der Domainumzug ohne Nachzug. Nach einem Wechsel des DNS-Anbieters oder einem Shop-Relaunch fehlen einzelne TXT-Einträge. Die Website läuft, die Mails laufen — bis Gmail die Zustellung zurückstuft. Ein typischer Auslöser ist der Umzug der Nameserver zu Cloudflare als Schutzschicht vor dem Shop: Dort gehören SPF-, DKIM- und DMARC-Einträge zur Umzugs-Checkliste.

Deshalb steht am Anfang jedes Projekts bei uns nicht der DNS-Eintrag, sondern die Inventur. Erst wenn feststeht, wer alles unter Ihrer Domain schreibt, ist eine scharfe Richtlinie überhaupt verantwortbar.

6. Das SPF-Limit: wenn der zehnte Dienst alle anderen mitreißt

Es gibt eine technische Grenze, die im E-Commerce häufiger reißt als anderswo — und deren Wirkung unangenehm ist. RFC 7208 legt fest: Bei der Auswertung eines SPF-Eintrags dürfen höchstens zehn Abfragen ans DNS gestellt werden, „to avoid unreasonable load on the DNS". Wird die Grenze überschritten, muss der prüfende Server das Ergebnis permerror zurückgeben.

permerror heißt: SPF gilt als nicht bestanden. Nicht für den zuletzt hinzugefügten Dienst, sondern für alle Absender dieser Domain. Der siebte Dienst, den Sie anbinden, kann also die sechs davor mit umbringen — und niemand bemerkt es, weil im DNS alles korrekt aussieht.

Mitgezählt werden die Mechanismen include, a, mx, ptr und exists sowie der Modifier redirect. Nicht mitgezählt werden ip4, ip6 und all, weil sie keine DNS-Abfrage auslösen. Entscheidend ist außerdem: Ein einzelnes include kann intern weitere Abfragen erzeugen. Ein Anbieter, der in Ihrem Eintrag wie ein Posten aussieht, verbraucht in der Praxis oft drei oder vier.

Vier Auswege, die in dieser Reihenfolge sinnvoll sind:

• Aufräumen. Prüfen Sie, welche include-Einträge noch aktiv genutzt werden. Reste alter Marketing-Tools, abgelöster Hoster und gekündigter Dienste stehen erstaunlich oft noch drin.
• Auf DKIM ausweichen. DKIM kennt kein Lookup-Limit. Wenn ein Dienst DKIM-Signierung unter Ihrer Domain anbietet, brauchen Sie ihn für DMARC nicht zusätzlich im SPF-Eintrag — die Übereinstimmung über DKIM genügt.
• Feste IP-Adressen eintragen. Dienste mit stabilen Versandservern lassen sich als ip4 hinterlegen. Das kostet keinen Lookup.
• Subdomains trennen. Newsletter über news.ihredomain.de, Transaktionsmails über die Hauptdomain: Jede Subdomain hat ihr eigenes Lookup-Budget — und eine Beschwerdewelle beim Newsletter belastet dann nicht den Ruf der Bestellbestätigungen.

Von automatisiertem „SPF-Flattening", das alle include-Verweise in feste IP-Listen auflöst, raten wir ohne laufende Pflege ab: Ändert der Anbieter seine Versandserver, ist Ihr Eintrag am nächsten Tag falsch — und der Fehler ist von außen nicht sichtbar.

7. In sechs Schritten zu p=reject

DMARC kennt drei Richtlinien: none (nur beobachten), quarantine (in den Spam-Ordner) und reject (abweisen). Der Reiz von reject ist groß, denn erst dort greift der Schutz gegen gefälschte Absender wirklich. Der Weg dorthin führt aber zwingend über die beiden anderen Stufen — sonst schalten Sie Ihren eigenen Versand ab, bevor Sie Fälscher stoppen.

Der Zeitplan ist der Teil, den Projekte am häufigsten unterschätzen. RFC 9989 formuliert selbst, dass es viele Monate dauern kann, bis ein Domaininhaber sicher ist, seinen gesamten Versand korrekt zu authentifizieren. Für einen mittelgroßen Shop mit überschaubarer Systemlandschaft sind aus unserer Erfahrung sechs bis zwölf Wochen realistisch — der Großteil davon ist Wartezeit auf aussagekräftige Berichte, nicht Arbeit an den Einträgen.

8. DMARC-Berichte lesen — und was nicht darin steht

Der Reporting-Teil ist der eigentliche Mehrwert von DMARC und der Grund, warum sich der Eintrag auch für kleinere Versender lohnt. Sobald Sie eine Adresse im rua-Feld hinterlegen, schicken Ihnen die teilnehmenden Empfänger regelmäßig Sammelberichte.

Darin steht: die IP-Adresse des einliefernden Servers, die Zahl der von dort eingegangenen Nachrichten, die verwendete Absenderdomain sowie das Ergebnis der SPF- und DKIM-Prüfung samt Übereinstimmung. Sie sehen also erstmals vollständig, wer weltweit unter Ihrem Namen sendet — legitime Dienste, vergessene Altsysteme und Fälscher in derselben Übersicht.

Darin steht nicht: der Inhalt Ihrer Nachrichten, die Betreffzeilen oder die Adressen Ihrer Empfänger. Die Sammelberichte sind reine Zählungen. Detaillierte Einzelfallberichte gibt es nur über das separate ruf-Feld — und ohne dieses Feld dürfen Empfänger laut RFC 9989 gar keine Fehlerberichte erzeugen. In der Praxis liefern die großen Anbieter sie ohnehin selten.

Ein praktischer Hinweis: Die Berichte kommen als gepackte XML-Dateien, je Anbieter einzeln, oft täglich. Ein Postfach, in dem sich diese Dateien sammeln, wird nach zwei Wochen unlesbar. Richten Sie deshalb von Anfang an einen Auswertungsdienst ein oder lassen Sie die Berichte in ein Werkzeug laufen, das sie zusammenführt — sonst bleibt der aufschlussreichste Teil der Einführung ungelesen liegen.

Quellen: RFC 7208, RFC 6376, RFC 9989 sowie die Absenderrichtlinien von Google, Yahoo und Microsoft. Stand: August 2026. Die vollständige Quellenliste finden Sie am Ende des Beitrags.

9. Was sich 2026 geändert hat: RFC 9989

Ein Detail, das noch kaum eine deutschsprachige Anleitung berücksichtigt: DMARC wurde neu spezifiziert. Elf Jahre lang war die Grundlage RFC 7489 aus dem Jahr 2015 — ein Dokument mit dem Status „Informational", das gar nicht von der IETF selbst herausgegeben wurde. Seit Mai 2026 gilt RFC 9989, ein Standards-Track-Dokument, das RFC 7489 ausdrücklich ablöst.

Für den Alltag sind drei Änderungen relevant:

• Der pct-Tag ist entfernt. Bisher ließ sich eine Richtlinie prozentual ausrollen (pct=10 für zehn Prozent der Nachrichten). Anhang A.6 von RFC 9989 streicht diese Möglichkeit. Jede Anleitung, die einen schrittweisen Rollout über pct empfiehlt, ist damit überholt.
• Neu ist t für den Testmodus. Mit t=y signalisieren Sie, dass die veröffentlichte Richtlinie noch nicht angewendet werden soll. Das ersetzt pct als Sicherheitsnetz beim Scharfschalten.
• Neu ist np für nicht existierende Subdomains. Damit lässt sich getrennt regeln, wie Empfänger mit erfundenen Subdomains umgehen sollen — ein beliebter Trick bei gefälschten Rechnungen.

Wer heute neu einsteigt, sollte direkt gegen RFC 9989 arbeiten. Wer schon einen Eintrag hat, prüft ihn auf einen verbliebenen pct-Wert und ergänzt np.

10. Fazit: Der schwierige Teil ist die Liste, nicht der Eintrag

SPF, DKIM und DMARC sind technisch überschaubar — drei TXT-Einträge, in einer Stunde gesetzt. Anspruchsvoll wird es durch die Voraussetzung, die niemand mitliefert: zu wissen, welche Systeme im Namen Ihrer Domain schreiben. Genau daran scheitern Einführungen, und genau deshalb beginnt die Arbeit mit der Bestandsaufnahme und einer Phase mit p=none, in der Sie nichts riskieren, aber alles sehen.

Wenn Sie ohnehin gerade Ihre E-Mail-Infrastruktur anfassen, lohnt der Blick auf die angrenzenden Bausteine: eine sauber aufgesetzte Microsoft-365-Umgebung bringt DKIM für die tägliche Geschäftskorrespondenz mit, und die Server- und Webhosting-Seite entscheidet darüber, ob Ihr Shop überhaupt über einen sauber identifizierbaren Versandweg verfügt. Für den Marketing-Versand richten wir in unserer Klaviyo-Beratung die Authentifizierung als festen Teil des Setups ein — ein Versandtool, das nicht durchkommt, bringt keine Umsätze, egal wie gut die Strecke aufgebaut ist.

11. Häufige Fragen zu DMARC, SPF und DKIM

Wie funktioniert DMARC?

DMARC verknüpft die Ergebnisse von SPF und DKIM mit der Domain, die Ihre Empfänger im Absenderfeld sehen. Besteht keine der beiden Prüfungen zu dieser sichtbaren Domain, greift die im DNS hinterlegte Richtlinie: nichts tun, in den Spam-Ordner verschieben oder abweisen. Zusätzlich fordert DMARC Berichte über alle Zustellversuche an (Quelle: RFC 9989).

Was ist der Unterschied zwischen DKIM und DMARC?

DKIM signiert jede ausgehende Nachricht kryptografisch, damit der Empfänger erkennt, ob sie unterwegs verändert wurde. DMARC entscheidet erst danach: Es prüft, ob die signierende oder die per SPF autorisierte Domain zur sichtbaren Absenderadresse passt, legt die Reaktion bei Fehlschlag fest und liefert Berichte. DKIM ist der Nachweis, DMARC die Regel darüber.

Was sind DMARC-DNS-Einträge?

Ein DMARC-Eintrag ist ein TXT-Eintrag im DNS Ihrer Domain, der unter dem Namen _dmarc veröffentlicht wird. Er beginnt immer mit v=DMARC1, nennt mit p die gewünschte Reaktion auf fehlgeschlagene Prüfungen und mit rua die Adresse für die Sammelberichte. Ohne führendes v=DMARC1 ignorieren Empfänger den gesamten Eintrag.

Wie kann ich DMARC-Fehler beheben?

Setzen Sie die Richtlinie zunächst auf p=none und werten Sie die Sammelberichte aus. Sie zeigen je sendender IP-Adresse, welcher Dienst SPF oder DKIM nicht besteht. Meist fehlt ein Eintrag für einen legitimen Absender, oder die Absenderdomain passt nicht zur signierenden Domain. Erst wenn alle Dienste sauber sind, verschärfen Sie die Richtlinie.

Warum landen meine Bestellbestätigungen im Spam?

Häufigste Ursache ist ein nicht autorisierter Absender: Der Shop verschickt über einen Dienst, der weder im SPF-Eintrag steht noch mit DKIM signiert. Dazu kommen abgelaufene Schlüssel, ein überschrittenes SPF-Lookup-Limit und fehlende Reverse-DNS-Einträge. Der Text der Mail ist selten das Problem — die Prüfung scheitert vor dem Inhaltsfilter.

Brauche ich DMARC auch unter 5.000 E-Mails pro Tag?

Die Schwelle von Google und Microsoft betrifft nur die zusätzlichen Pflichten für Massenversender. Alle Absender müssen ohnehin mindestens SPF oder DKIM einrichten. DMARC bleibt darunter freiwillig, ist aber der einzige Weg, Missbrauch Ihrer Domain überhaupt zu bemerken. Das BSI empfiehlt Unternehmen ausdrücklich eine sorgfältigere Umsetzung der drei Standards.

Muss ich DMARC auch für Domains einrichten, von denen ich nichts versende?

Ja. Gerade Parkdomains und alte Shop-Domains sind beliebte Absender für gefälschte Rechnungen, weil dort niemand hinschaut. Für solche Domains veröffentlichen Sie einen DMARC-Eintrag mit p=reject und einen SPF-Eintrag, der jeden Versand ausschließt. Seit RFC 9989 regelt zusätzlich das Feld np nicht existierende Subdomains.

12. Quellen

Die technischen Angaben in diesem Beitrag stützen sich auf die folgenden Spezifikationen und Anbieter-Dokumentationen (Stand August 2026). Externe Quellen öffnen in einem neuen Tab.

• RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — Standards Track, Mai 2026; löst RFC 7489 und RFC 9091 ab. Grundlage für Tags, Richtlinien, Berichte und die Entfernung von pct.
• RFC 7208 — Sender Policy Framework (SPF), Version 1 — Standards Track, April 2014; Abschnitt 4.6.4 zum Limit von zehn DNS-Abfragen und zum Ergebnis permerror.
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures — Internet Standard STD 76, September 2011.
• RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM — Januar 2018; Mindestschlüssellänge 1.024 Bit, Empfehlung 2.048 Bit, Verbot von rsa-sha1.
• Google Workspace-Admin-Hilfe — E-Mail-Absenderrichtlinien — Anforderungen für alle Absender und für mehr als 5.000 Nachrichten pro Tag an persönliche Gmail-Konten, inklusive Spamraten.
• Yahoo Sender Hub — Best Practices — Anforderungen an Massenversender seit Februar 2024, Übereinstimmungs- und Abmelderegeln.
• Microsoft Tech Community — Outlook's New Requirements for High-Volume Senders — Blogbeitrag vom 2. April 2025, aktualisiert am 30. April 2025; Schwelle, betroffene Domains, Durchsetzung ab 5. Mai 2025 und Fehlercode 550 5.7.515.
• BSI — Empfehlungen zur Verbesserung der E-Mail-Sicherheit in Unternehmen — Meldung vom 26. Mai 2025 zur Cyber-Sicherheitsempfehlung „Upgrade für die E-Mail-Sicherheit".