Aktuelle Beiträge Zum Blog

Eine Bestellbestätigung, die nicht ankommt, erzeugt im Shop keinen Fehler. Der Auftrag steht in der Datenbank, die Zahlung ist gebucht, der eigene Mailserver protokolliert eine saubere Annahme – und zwei Tage später meldet sich der Kunde, weil er nichts erhalten hat. Der Ausfall entsteht hinter der eigenen Infrastruktur, bei den empfangenden Postfachanbietern, und er hinterlässt dort keine Spur, die im Shop sichtbar wäre. Wie hoch der Filterdruck ist, zeigt eine Zahl des Anbieters selbst: Gmail blockiert nach eigenen Angaben rund 15 Milliarden unerwünschte Nachrichten am Tag (Google, The Keyword). Gegen dieses Rauschen kommt eine Transaktionsmail nur mit einem belegbaren Absendernachweis durch. SPF, DKIM und DMARC liefern ihn – wenn sie zusammenpassen. Dieser Artikel zeigt, wie die drei Verfahren im Hosting eines Online-Shops ineinandergreifen, welche Grenzen die Normen setzen und woran ein gewachsener Eintrag typischerweise scheitert.

Wenn die Bestellbestätigung still verschwindet

Die Filter, gegen die eine Shop-Mail antritt, sind keine Vorsichtsmaßnahme, sondern eine Reaktion auf Masse. Das Bundesamt für Sicherheit in der Informationstechnik hat für die Regierungsnetze gezählt: Bei durchschnittlich 712.000 eingehenden Nachrichten am Tag lag das Monatsmittel der Spam-Quote bei 51 Prozent (BSI Lagebericht 2025). Entscheidend ist die Zusammensetzung dieser Hälfte. 73 Prozent der Spam-Mails waren Cyberangriffe: 58 Prozent betrügerische, 15 Prozent erpresserische Nachrichten (BSI Lagebericht 2025). Unter den betrügerischen Mails machte Phishing 93 Prozent aus, davon 49 Prozent Finance-Phishing (BSI Lagebericht 2025). Ein Postfachanbieter, der solche Verteilungen sieht, behandelt eine unsignierte Mail mit einem bekannten Handelsnamen im Absenderfeld nicht wohlwollend. Er behandelt sie als das, was sie statistisch meistens ist.

Im Berichtszeitraum gingen durchschnittlich täglich rund 712.000 E-Mails in den Regierungsnetzen ein. Das Monatsmittel der täglichen Spam-Quoten lag bei 51 Prozent.

BSI, Die Lage der IT-Sicherheit in Deutschland 2025

Die Angriffsfläche in Deutschland schätzt dieselbe Behörde auf mindestens 150 Millionen aktive E-Mail-Adressen (BSI Lagebericht 2025). Der Schaden ist messbar: Das Internet Crime Complaint Center des FBI verzeichnete für 2025 allein bei Angriffen auf den Geschäftsverkehr per E-Mail einen gemeldeten Schaden von 3.046.598.558 US-Dollar, und Phishing beziehungsweise Spoofing blieb mit 191.561 Meldungen die häufigste Deliktart (FBI IC3 2025). Die Anti-Phishing Working Group zählte 3,8 Millionen beobachtete Phishing-Angriffe im Jahr 2025, im vierten Quartal traten die Angreifer unter 866 verschiedenen Markennamen auf (APWG Q4 2025). Markenmissbrauch ist damit der Regelfall. Wer eine bekannte Shop-Domain betreibt, muss davon ausgehen, dass sie im Absenderfeld fremder Nachrichten auftaucht – und dass Filter diese Erfahrung auf die eigene Bestellbestätigung übertragen, solange nichts sie unterscheidbar macht.

Die drei Verfahren in einem Satz

SPF beantwortet die Frage, welche Server für eine Domain versenden dürfen. DKIM hängt eine kryptografische Signatur an die Nachricht, deren öffentlicher Schlüssel im DNS steht. DMARC verbindet beide mit der sichtbaren Absenderadresse und sagt dem Empfänger, was bei einem Fehlschlag geschehen soll. Erst das Zusammenspiel ergibt einen Nachweis; einzeln bleibt jedes Verfahren eine Teilaussage.

Wie gut die Verfahren in der Fläche greifen, lässt sich an ausgewerteten Nachrichtenströmen ablesen. Über 93 Prozent der untersuchten Nachrichten bestanden die SPF-Prüfung, bei DMARC waren es 86,5 Prozent, während 4,2 Prozent durchfielen (Cloudflare Radar). Der Abstand zwischen beiden Werten geht größtenteils auf Nachrichten ohne DMARC-Richtlinie zurück, und dort fehlt die Bindung an die sichtbare Absenderadresse: SPF steht, DKIM steht vielleicht, aber die Ausrichtung darauf wird nicht geprüft. Im Jahr 2025 waren im Durchschnitt 5,6 Prozent der ausgewerteten Nachrichten bösartig, täuschende Links waren mit 52 Prozent die häufigste Angriffsform, nach 43 Prozent im Vorjahr (Cloudflare Radar 2025). Eine Mail mit Bestellnummer, Betragsangabe und Link auf eine Statusseite sieht formal genau so aus wie ein Angriff – der Unterschied liegt in der Authentifizierung, nicht im Text.

SPF: die Freigabeliste, die unbemerkt ungültig wird

SPF ist ein TXT-Eintrag im DNS der Absenderdomain. Er listet die Server auf, die im Namen dieser Domain versenden dürfen, und der empfangende Server gleicht die IP-Adresse der Verbindung dagegen ab. Geprüft wird dabei nicht die Adresse, die der Kunde im Postfach sieht, sondern der Umschlagabsender aus dem SMTP-Dialog. Diese Unterscheidung ist der Grund, warum ein Shop mit tadellosem SPF-Eintrag trotzdem an DMARC scheitern kann. Für den laufenden Betrieb heißt das: Der Eintrag muss jede Quelle abdecken, die im Namen der Domain versendet – Shopsystem, Warenwirtschaft, Newsletter-Strecke, Ticketsystem, Rechnungsversand. Wer eine Schnittstelle zu einem Drittsystem neu anbindet, erweitert damit fast zwangsläufig die Liste der versendenden Server.

  • ip4 und ip6 benennen einzelne Adressen oder Netze direkt und lösen keine weitere DNS-Abfrage aus – die günstigste Form, eine feste Versandstrecke aufzunehmen.
  • include verweist auf den SPF-Eintrag eines anderen Anbieters und übernimmt dessen Freigaben. Jeder dieser Verweise kostet mindestens eine Abfrage, verschachtelte Verweise kosten mehr.
  • a und mx lösen Namen zu Adressen auf und kosten ebenfalls je eine Abfrage. In gewachsenen Zonen stehen sie oft aus Gewohnheit da, ohne dass die Server noch versenden.
  • all schließt den Eintrag ab. -all weist alles Übrige hart ab, ~all markiert es weich; ohne Abschluss bleibt die Aussage unvollständig.
  • redirect verlagert die gesamte Auswertung auf eine andere Domain und wird in Shops häufig übersehen, wenn die Zielzone später umgebaut wird.

Der teuerste Fallstrick steht in der Norm selbst. Eine SPF-Auswertung darf höchstens zehn Abfragen auslösen, die das DNS befragen; wer darüber liegt, bekommt kein schlechteres Ergebnis, sondern einen Auswertungsfehler (RFC 7208, Abschnitt 4.6.4). Ins Leere laufende Abfragen zählen mit: Zwei davon sind das zulässige Höchstmaß, erst ab der dritten soll die Auswertung mit einem permerror abbrechen (RFC 7208). Zusätzlich darf der Empfänger die Auswertung nach einer Zeitgrenze abbrechen, die mindestens 20 Sekunden betragen soll (RFC 7208). Das Tückische daran: Die Grenze wird nicht beim Anlegen des Eintrags überschritten, sondern Monate später, wenn ein Anbieter seinen eigenen include-Eintrag um eine Ebene erweitert. Der Shop hat nichts geändert und versendet trotzdem plötzlich unauthentifiziert. Auch Microsoft weist Versender ausdrücklich darauf hin, dass die SPF-Prüfung oberhalb von zehn Abfragen fehlschlagen kann (Microsoft Tech Community).

Klein halten ist Teil der Norm

Der veröffentlichte SPF-Eintrag soll so klein bleiben, dass die Antwort auf eine Abfrage in 512 Oktett passt (RFC 7208, Abschnitt 3.4). Wächst er darüber hinaus, wird die Antwort unterwegs anfälliger. Zusammen mit der Abfragegrenze ergibt sich eine einfache Betriebsregel: Jede Versandquelle, die nicht mehr genutzt wird, gehört aus dem Eintrag entfernt – und zwar bevor die nächste dazukommt.

zone-auszug.txt
; Absenderdomain des Shops
shop.example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.20 ip4:198.51.100.21 include:versand.example.net -all"

; Getrennte Subdomain fuer den Massenversand
mail.shop.example.com. 3600 IN TXT "v=spf1 include:newsletter.example.net -all"

; Domain ohne jeden Versand: ausdruecklich sperren
static.example.com. 3600 IN TXT "v=spf1 -all"

Zwei Handgriffe entschärfen die Abfragegrenze dauerhaft. Erstens: bekannte, feste Adressen als ip4 oder ip6 aufnehmen statt über einen Verweis; das spart je Quelle eine Abfrage. Zweitens: Domains, die überhaupt nicht versenden, mit einem eigenen Eintrag hart sperren, statt sie ungeregelt zu lassen. Parkdomains, alte Kampagnenadressen und Bilddomains eines Shops sind beliebte Absender für gefälschte Rechnungsmails. Wer das Zusammenspiel mit dem übrigen Betrieb sauber halten will, plant die Zonenpflege wie jede andere Wartungsaufgabe am Shopsystem – mit festem Termin und dokumentiertem Stand, nicht als Reaktion auf eine Beschwerde.

DKIM: Signatur, Schlüssellänge und Rotation

DKIM arbeitet anders als SPF: Statt eine Absenderadresse freizugeben, signiert der versendende Server ausgewählte Kopfzeilen und den Nachrichtenrumpf mit einem privaten Schlüssel. Der zugehörige öffentliche Schlüssel liegt als TXT-Eintrag unter einem Selektor im DNS, etwa unter sw1._domainkey.shop.example.com. Der Empfänger holt ihn ab und rechnet die Signatur nach. Weil die Signatur an der Nachricht hängt und nicht an der Verbindung, übersteht sie eine Weiterleitung, solange kein Zwischensystem den Text verändert. Genau das macht DKIM für Shops wertvoll: Bestellbestätigungen werden häufig automatisch weitergeleitet, in Sammelpostfächer, an die Buchhaltung, an ein angebundenes Kassensystem oder an das Steuerbüro.

MerkmalVorgabe der NormVorgabe des BSI
Minimale RSA-SchlüssellängeMindestens 1024 Bit für alle Schlüssel (RFC 8301)Nicht kürzer als 1024 Bit (BSI TR-03182)
Empfohlene SchlüssellängeMindestens 2048 Bit als Soll-Vorgabe (RFC 8301)Aus Gründen der Interoperabilität nicht länger als 2048 Bit
Erneuerung des SchlüsselsOhne feste Frist geregeltAlle sechs Monate, sonst dokumentierte Begründung
SelektorführungFrei wählbarWechsel setzt zwei parallele Selektoren voraus

Die Zahlen sind eindeutig und lassen wenig Spielraum. Für RSA gilt: Schlüssel unter 1024 Bit sind unzulässig, mindestens 2048 Bit sind vorgesehen (RFC 8301). Das BSI zieht die Grenze zusätzlich nach oben und begrenzt die Länge aus Gründen der Interoperabilität auf 2048 Bit (BSI TR-03182). Der Grund dafür ist praktischer Natur: Sehr lange Schlüssel sprengen die Antwortgröße im DNS und werden von manchen Empfängern nicht mehr sauber ausgewertet. Ein Shop, der zwischen 1024 und 2048 Bit wählen kann, nimmt 2048 – und prüft nach dem Einspielen, ob der Eintrag als eine Zeichenkette ausgeliefert wird oder in mehrere Teile zerfällt.

Der zweite Punkt wird in der Praxis regelmäßig übersehen: Ein DKIM-Schlüssel ist kein Dauerzustand. Das BSI verlangt eine Erneuerung alle sechs Monate; wer das nicht tut, muss die Abweichung dokumentieren (BSI TR-03182). Sauber wird der Wechsel nur mit zwei Selektoren. Der neue Schlüssel wird veröffentlicht, während der alte noch signiert; nach einer Übergangszeit stellt der Versand auf den neuen Selektor um; erst wenn keine unterwegs befindliche Nachricht mehr den alten Schlüssel braucht, verschwindet der alte Eintrag. Wer den Selektor in einem Schritt austauscht, macht jede Nachricht ungültig, die zu diesem Zeitpunkt noch in einer Warteschlange steht. Diese Reihenfolge gehört in dieselbe Betriebsdokumentation wie das Löschkonzept mit seinen Aufbewahrungsfristen.

DMARC: von der Beobachtung zur Richtlinie

DMARC schließt die Lücke, die SPF und DKIM offenlassen. Beide Verfahren prüfen Angaben, die der Kunde im Postfach nicht sieht: den Umschlagabsender und die signierende Domain. DMARC verlangt, dass mindestens eine dieser Angaben zur sichtbaren Absenderadresse passt – das ist die Ausrichtung – und teilt dem Empfänger mit, wie er mit Nachrichten verfahren soll, bei denen das misslingt. Seit Mai 2026 ist das kein informationeller Text mehr: RFC 9989 löst die bisherigen Fassungen RFC 7489 und RFC 9091 ab und führt DMARC als Standard (RFC 9989). Für Shops ändert sich dadurch weniger im Eintrag als in der Verbindlichkeit der Aussage.

dmarc-eintrag.txt
; Einstieg: beobachten, ohne den Versand zu gefaehrden
_dmarc.shop.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@shop.example.com; adkim=r; aspf=r"

; Zwischenstand: Verdaechtiges in den Spam-Ordner
_dmarc.shop.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@shop.example.com; adkim=s; aspf=r"

; Zielbild: Abweisung, Berichte weiter aktiv
_dmarc.shop.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@shop.example.com; adkim=s; aspf=s"

Zwei Details der neuen Fassung sind für Shops mit vielen Subdomains wichtig. Die Richtlinie wird über einen Baumdurchlauf gesucht, der bei acht DNS-Abfragen gedeckelt ist (RFC 9989, Abschnitt 4.10). Wer Versandadressen tief verschachtelt, sollte die Richtlinie deshalb weit oben setzen und nicht darauf bauen, dass sie aus fünf Ebenen Tiefe noch gefunden wird. Und die Berichtsadresse ist keine Kür: Nach der Vorgabe des BSI muss eine DMARC-Richtlinie mindestens eine RUA-Adresse benennen (BSI TR-03182). Ohne diese Adresse arbeitet der Shop blind – er erfährt nicht, welche Systeme in seinem Namen versenden und welche davon durchfallen.

  1. Bestand aufnehmen. Jede Quelle notieren, die im Namen der Domain versendet: Shopsystem, Warenwirtschaft, Zahlungsdienst, Ticketsystem, Rechnungsstelle, Marketingstrecke.
  2. Mit p=none starten und Berichte einsammeln. Vier bis sechs Wochen genügen meistens, um saisonale Strecken wie Retourenlabel oder Jahresabrechnung mitzunehmen.
  3. Lücken schließen. Jede Quelle bekommt entweder eine SPF-Freigabe oder eine DKIM-Signatur, besser beides, und in jedem Fall eine Ausrichtung auf die sichtbare Absenderdomain.
  4. Auf p=quarantine wechseln. Ab hier landet Nicht-Ausgerichtetes im Spam-Ordner statt im Posteingang; die Berichte zeigen sofort, was übersehen wurde.
  5. Auf p=reject gehen. Erst wenn die Berichte über mehrere Wochen keine legitimen Fehlschläge mehr zeigen. Das BSI erkennt ausschließlich quarantine und reject als schützende Richtlinie an (BSI TR-03182).
Der pct-Wert ist entfallen

Wer einen Einführungsplan aus älteren Anleitungen übernimmt, findet dort ein schrittweises Hochfahren über den pct-Tag mit einem Wertebereich von 0 bis 100. Diesen Tag gibt es in der neuen Fassung nicht mehr: Die Betriebserfahrung zeigte, dass er außerhalb der Werte 0 und 100 kaum korrekt angewendet wurde und sich die Abweichungen zwischen den Umsetzungen stark unterschieden (RFC 9989, Anhang A.6). Der Übergang läuft heute über die Stufen der Richtlinie selbst, nicht über einen Prozentsatz.

Was die großen Postfachanbieter verlangen

Die Normen sagen, wie die Verfahren funktionieren. Was ein Shop tatsächlich erfüllen muss, sagen die Empfänger. Seit dem 1. Februar 2024 gelten für Absender, die mehr als 5.000 Nachrichten am Tag an Gmail-Konten schicken, verschärfte Anforderungen (Google Workspace Admin Help). Die Schwelle klingt hoch, ist es für einen laufenden Shop aber nicht: Bestellbestätigung, Zahlungsbeleg, Versandavis, Retourenlabel und Bewertungsanfrage summieren sich pro Bestellung schnell auf fünf Nachrichten. Bei tausend Bestellungen am Tag ist die Grenze erreicht, ohne dass eine einzige Werbemail versendet wurde.

Gmail: Authentifizierung und Beschwerderate

Nicht authentifizierte Nachrichten werden aussortiert oder mit dem Fehlercode 5.7.26 abgewiesen (Google Workspace Admin Help). Für die in den Postmaster Tools gemeldete Beschwerderate gilt: unter 0,10 Prozent bleiben und 0,30 Prozent nicht erreichen (Google Workspace Admin Help).

Outlook: dieselbe Schwelle, eigener Fehlercode

Für Domains mit mehr als 5.000 Nachrichten am Tag gelten SPF, DKIM und DMARC als Anforderung (Microsoft Tech Community). Seit dem 5. Mai 2025 werden nicht konforme Massenversender mit der Meldung 550 5.7.515 abgewiesen (Microsoft Tech Community).

Yahoo: Grenze für Beschwerden

Massenversender sollen ihre Beschwerderate unter 0,3 Prozent halten (Yahoo Senders). Der Wert ist kein Richtwert für den Monatsdurchschnitt, sondern eine Grenze, an der Zustellentscheidungen hängen.

Apple: Richtlinie auf der Empfängerseite

Alle iCloud-Mail-Domains fahren seit dem 2. Juli 2018 eine DMARC-Richtlinie mit p=quarantine (Apple Support). Wer diese Adressen als Absender in Formularen zulässt, muss mit Zustellproblemen rechnen.

Zwei weitere Anforderungen betreffen weniger die Technik als den Ablauf. Große Absender müssen eine Abmeldung mit einem Klick anbieten und Abmeldewünsche binnen zwei Tagen verarbeiten (Google, The Keyword). Wie stark solche Vorgaben wirken, zeigt bereits der Schritt davor: Nachdem Gmail 2022 überhaupt eine Form der Authentifizierung zur Anforderung gemacht hatte, ging die Zahl der nicht authentifizierten Nachrichten, die bei den Empfängern ankamen, um 75 Prozent zurück (Google, The Keyword, Oktober 2023). Wer heute ohne Authentifizierung versendet, gehört damit zu einer schrumpfenden Minderheit – und genau das macht ihn auffällig. Die Abmeldelogik gehört sauber getrennt von der Transaktionsstrecke; wie das im Zusammenspiel mit einer Marketing-Automation aussieht, entscheidet über die Beschwerderate.

Ausrichtung, Subdomains und der Sonderfall Versanddienst

Die Ausrichtung ist der Punkt, an dem die meisten Shops scheitern, obwohl SPF und DKIM technisch bestehen. DMARC kennt zwei Strenge-Grade. Bei entspannter Ausrichtung genügt es, wenn die geprüfte Domain und die sichtbare Absenderdomain dieselbe organisatorische Wurzel teilen; bei strenger Ausrichtung müssen sie identisch sein. Wer über einen Versanddienstleister verschickt, dessen Umschlagabsender auf einer fremden Domain liegt, besteht SPF – und fällt bei DMARC durch, weil die geprüfte Domain nicht zur sichtbaren passt. Der Ausweg ist eine eigene Versand-Subdomain, deren Umschlagabsender und DKIM-Signatur beide unter der Shop-Domain liegen.

Eine getrennte Subdomain hat einen zweiten Vorteil, der im Alltag mehr wiegt als die Technik: Sie trennt die Reputation. Transaktionsmails und Werbestrecken bewerten Empfänger unterschiedlich, und eine Kampagne mit schlechter Beschwerderate soll nicht die Bestellbestätigung mit nach unten ziehen. Üblich ist deshalb eine Aufteilung in eine Subdomain für den transaktionalen Versand und eine zweite für Werbung, beide mit eigenem SPF-Eintrag, eigenem DKIM-Selektor und einer DMARC-Richtlinie, die von der Hauptdomain geerbt oder eigenständig gesetzt wird. Wer den Bestand vorher unabhängig aufnehmen lassen möchte, findet im Shop-Check den passenden Rahmen.

Terminal
$ dig +short TXT shop.example.com
"v=spf1 ip4:198.51.100.20 include:versand.example.net -all"
$ dig +short TXT _dmarc.shop.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@shop.example.com; adkim=s; aspf=r"
$ dig +short TXT sw1._domainkey.shop.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
$ dig +short TXT _mta-sts.shop.example.com
"v=STSv1; id=20260901T120000"

Diese vier Abfragen dauern zusammen keine halbe Minute und beantworten die wichtigsten Fragen. Steht der SPF-Eintrag genau einmal, oder liegen zwei Fassungen nebeneinander? Zwei SPF-Einträge auf derselben Domain sind ein Auswertungsfehler, kein Kompromiss. Endet der Eintrag mit einem Abschluss? Ist die DMARC-Richtlinie noch auf Beobachtung, obwohl der Einführungsplan längst abgeschlossen sein sollte? Und liefert der DKIM-Selektor überhaupt noch einen Schlüssel, oder wurde er beim letzten Anbieterwechsel entfernt? Wer diese Abfragen in die regelmäßige Logfile-Auswertung einreiht, bemerkt einen stillen Ausfall in Tagen statt in Quartalen.

Transportverschlüsselung und die Berichte, die niemand liest

Authentifizierung sagt, wer versendet hat. Sie sagt nichts darüber, ob der Transport verschlüsselt war. Diese Lücke schließt MTA-STS: Die Domain veröffentlicht eine Richtlinie, die dem sendenden Server vorschreibt, nur über eine geprüfte TLS-Verbindung zuzustellen. Die Richtlinie wird zwischengespeichert, und die Norm setzt dafür eine Obergrenze von 31.557.600 Sekunden, also etwa einem Jahr (RFC 8461). Für den Betrieb bedeutet das zweierlei: Ein Zertifikatswechsel muss die Richtlinie berücksichtigen, und eine fehlerhafte Richtlinie wirkt so lange nach, wie die Zwischenspeicher sie halten. Deshalb wird zuerst mit einem Testmodus veröffentlicht und erst nach ausgewerteten Berichten scharf geschaltet.

Die DMARC-Berichte an die RUA-Adresse sind der eigentliche Betriebswert des Verfahrens. Sie kommen als komprimierte XML-Dateien und enthalten je Empfängerorganisation, welche IP-Adressen im Namen der Domain versendet haben, wie viele Nachrichten das waren und ob SPF, DKIM und die Ausrichtung bestanden haben. Wer sie liest, sieht drei Dinge sofort: vergessene Versandquellen, gefälschte Absender und Ausrichtungsfehler nach einem Systemwechsel. Wer sie nicht liest, hat einen DMARC-Eintrag, aber keine Kontrolle. Eine wöchentliche Sichtung von zehn Minuten genügt in ruhigen Zeiten; nach jedem Eingriff in die Cloud-Infrastruktur oder an einer Versandstrecke gehört ein zusätzlicher Blick in die nächsten Berichte.

Werbung und Transaktionsmail sauber trennen

Zustellbarkeit ist nicht nur eine technische Frage. Eine Bestellbestätigung ist eine Vertragsinformation und darf ohne gesonderte Einwilligung versendet werden. Sobald in derselben Nachricht Produktempfehlungen, Rabattaktionen oder eine Bewertungsaufforderung stehen, verschiebt sich die Einordnung. Werbung per elektronischer Post ohne ausdrückliche Einwilligung ist nur dann keine unzumutbare Belästigung, wenn vier Voraussetzungen zusammen erfüllt sind: Die Adresse stammt aus dem Verkauf einer Ware oder Dienstleistung, sie wird für eigene ähnliche Waren genutzt, der Kunde hat nicht widersprochen, und er wird bei Erhebung und bei jeder Verwendung klar auf sein Widerspruchsrecht hingewiesen (Gesetze im Internet, UWG).

  • Transaktionsmails und Werbestrecken laufen über getrennte Subdomains mit eigener Reputation.
  • Der Hinweis auf das Widerspruchsrecht steht bei der Erhebung der Adresse und in jeder Werbenachricht, nicht ausschließlich in der Datenschutzerklärung.
  • Eine Abmeldung wirkt mit einem Klick und wird binnen zwei Tagen verarbeitet (Google, The Keyword).
  • Der Widerspruch wird technisch dort gespeichert, wo alle versendenden Systeme ihn lesen – nicht nur in der Marketingstrecke.
  • Die Bestellbestätigung bleibt frei von Werbeelementen; die Gestaltung der Transaktionsmail folgt einer anderen Logik als eine Kampagne.

Zustellbarkeit als Betriebsaufgabe

Der wirtschaftliche Rahmen macht deutlich, worum es geht. Der deutsche Onlinehandel setzte zuletzt 92,3 Milliarden Euro um, der Onlineanteil am gesamten Einzelhandel lag bei 13,5 Prozent (HDE Online-Monitor 2026). Jede Bestellbestätigung, die im Spam-Ordner landet, erzeugt in diesem Markt eine Rückfrage im Service, eine unnötige Stornierung oder eine Zahlungsverzögerung. Der Aufwand für SPF, DKIM und DMARC fällt einmalig für die Einrichtung an und danach als kleine, wiederkehrende Pflegeaufgabe: Selektor wechseln, Berichte sichten, neue Versandquellen aufnehmen, alte entfernen. Wer das in den regelmäßigen Betrieb einbindet – zusammen mit Patchstand, Sicherungen und IT-Sicherheit im E-Commerce – hat den Ausfall abgeschafft, den man im Shop nicht sehen kann. Wir richten diese Kette im Rahmen des Shop-Hostings ein und übernehmen die laufende Pflege; ein erstes Gespräch klärt, welche Versandquellen bereits vorhanden sind.

Quellen und Studien

Dieser Artikel stützt sich auf RFC 7208, RFC 8301, RFC 8461 und RFC 9989 des RFC Editor, auf die Technische Richtlinie BSI TR-03182 und den Lagebericht 2025 des BSI, auf die Absenderrichtlinien von Google, Microsoft, Yahoo und Apple, auf Auswertungen von Cloudflare Radar, den Internet Crime Report 2025 des FBI IC3, den Phishing Activity Trends Report der APWG, den HDE Online-Monitor 2026 sowie auf den Wortlaut des UWG bei Gesetze im Internet. Die genannten Zahlen beziehen sich auf den Stand der jeweiligen Veröffentlichung.

In der Regel nicht. SPF prüft den Umschlagabsender, nicht die Adresse, die der Kunde sieht. Ohne DKIM und eine DMARC-Ausrichtung fehlt die Verbindung zur sichtbaren Absenderdomain. In ausgewerteten Nachrichtenströmen bestanden über 93 Prozent die SPF-Prüfung, bei DMARC waren es 86,5 Prozent, während 4,2 Prozent durchfielen (Cloudflare Radar). Der Abstand entfällt überwiegend auf Nachrichten ohne DMARC-Richtlinie – und ohne Richtlinie gibt es auch keine Bindung an die sichtbare Absenderadresse.

Höchstens zehn Abfragen, die das DNS befragen; darüber endet die Auswertung mit einem Fehler (RFC 7208, Abschnitt 4.6.4). Ins Leere laufende Abfragen zählen mit: Zwei davon sind das zulässige Höchstmaß, erst ab der dritten soll die Auswertung mit einem permerror abbrechen (RFC 7208). Feste Adressen als ip4 oder ip6 aufzunehmen spart je Quelle eine Abfrage.

Schlüssel unter 1024 Bit sind unzulässig, mindestens 2048 Bit sind vorgesehen (RFC 8301). Das BSI begrenzt die Länge aus Gründen der Interoperabilität zugleich auf 2048 Bit (BSI TR-03182). Für Shops ist 2048 Bit damit der praktikable Wert; entscheidend ist zusätzlich, dass der Eintrag im DNS unbeschädigt ausgeliefert wird.

Das BSI verlangt eine Erneuerung alle sechs Monate oder eine dokumentierte Begründung für die Abweichung (BSI TR-03182). Der Wechsel läuft über zwei parallele Selektoren: neuen Schlüssel veröffentlichen, Versand umstellen, alten Eintrag erst entfernen, wenn keine Nachricht in einer Warteschlange ihn mehr benötigt.

Ab mehr als 5.000 Nachrichten am Tag an Gmail-Konten (Google Workspace Admin Help); Outlook zieht dieselbe Grenze für Domains mit mehr als 5.000 Nachrichten täglich (Microsoft Tech Community). Nicht authentifizierte Nachrichten werden aussortiert oder mit dem Fehlercode 5.7.26 abgewiesen, bei Outlook mit der Meldung 550 5.7.515.

Sobald Werbeelemente enthalten sind, wird aus der Vertragsinformation eine Werbenachricht. Ohne ausdrückliche Einwilligung ist sie nur zulässig, wenn vier Voraussetzungen zusammen erfüllt sind, darunter der klare Hinweis auf das Widerspruchsrecht bei Erhebung und bei jeder Verwendung (Gesetze im Internet, UWG). Für die Zustellbarkeit ist die Trennung ohnehin sinnvoll.