E-Mail-Versand des Shops einrichten: SPF, DKIM, DMARC

Ein Shopsystem erzeugt Bestellbestätigung, Versandmeldung und Rechnung; ob die Nachricht im Postfach oder im Spam-Ordner landet, entscheidet der Empfänger anhand der Absender-Domain. Dafür veröffentlichen Sie drei DNS-Einträge, die zusammenwirken. Die Reihenfolge der folgenden Schritte ist kein Geschmack: Zuerst sammeln und autorisieren, dann erst verschärfen.

Was Sie vorab brauchen

• Zugriff auf die DNS-Zone Ihrer Absender-Domain, also auf die Verwaltung beim Registrar oder beim Hoster
• eine Liste aller Systeme, die in Ihrem Namen senden: Shopsystem, Warenwirtschaft, Newsletter-Dienst, Zahlungs- und Paketdienste
• je System die Absenderadresse (From), die Bounce-Adresse (Return-Path) und die IP-Adresse oder den Hostnamen des Ausgangsservers
• den Selector und den DKIM-Schlüssel, den Ihr Versanddienst bereitstellt
• zwei bis drei Testpostfächer bei verschiedenen Anbietern
• ein DNS-Abfragewerkzeug für TXT-, CNAME- und PTR-Abfragen; die Beispiele unten nutzen dig (Manpage im Quellenverzeichnis)
• ein Postfach für die DMARC-Berichte

Schritt für Schritt: Absender-Domain authentifizieren

Schritt 1: Senderquellen und Domains auflisten

Erfassen Sie, welche Systeme mit welcher Domain ausgehende Mail senden. Zwei Domain-Namen sind dabei zu trennen: die Adresse, die der Empfänger sieht (die From-Kopfzeile), und die Domain, die der Server im SMTP-Übergang nennt. SPF autorisiert Hosts für MAIL FROM und HELO (RFC 7208, Abschnitt 1); DMARC vergleicht dagegen die so authentifizierte Domain mit der From-Domain (RFC 9989, Abschnitt 4.4). Ein Blick auf die From-Adresse allein sagt deshalb nichts über den SPF-Record aus, den Sie brauchen.

Schritt 2: SPF-Record anlegen

Veröffentlichen Sie genau einen SPF-Record je Domain, und zwar als TXT-Record: der frühere Record-Typ SPF wird nicht mehr unterstützt (RFC 7208, Abschnitt 3.1). Ein Domainname darf keine mehreren Records haben, die eine Auswahl zwischen mehr als einem Record erzwingen (Abschnitt 3.2). Der Abschluss -all sagt, dass alle nicht genannten Server nicht autorisiert sind, ~all schwächt das zu einem Softfail ab (Abschnitt 2.6.4 und 2.6.5). Prüfen Sie die Zahl der ausgewerteten DNS-auslösenden Begriffe: include, a, mx, ptr, exists und redirect dürfen während der gesamten Auswertung zusammen zehn nicht überschreiten; gezählt wird auch, was eine verschachtelte include- oder redirect-Auswertung auslöst, sonst ergibt die Auswertung permerror (Abschnitt 4.6.4 und Abschnitt 4.1). Bleiben Record, Name und die übrigen TXT-Records derselben Domain zusammen unter 450 Oktett, sollte die Antwort in ein UDP-Paket passen (Abschnitt 3.4).

Schritt 3: DKIM-Selector einrichten

DKIM speichert den öffentlichen Schlüssel in einem Unterbereich _domainkey. Bei einer Signatur mit d=beispiel-shop.example und s=20261014 lautet die Abfrage 20261014._domainkey.beispiel-shop.example (RFC 6376, Abschnitt 3.6.2.1). Pflichtfeld ist der base64-kodierte Schlüssel in p=; wird v=DKIM1 verwendet, muss es das erste Tag im Record sein, und ein leerer p=-Wert widerruft den Schlüssel (Abschnitt 3.6.1). RSA-Schlüssel müssen mindestens 1024 Bit haben, empfohlen sind 2048 Bit, und RSA-SHA-1 darf nicht mehr verwendet werden (RFC 8301). Gibt Ihr Versanddienst nur CNAME-Ziele vor, die auf seine Schlüssel zeigen, ist der öffentliche Schlüssel trotzdem lesbar: Die Abfrage am Aliasnamen liefert den TXT-Record des Ziels zurück, weil der Name-Server die Abfrage beim kanonischen Namen neu startet (RFC 1034, Abschnitt 3.6.2). Rotieren können Sie den Schlüssel nur dort, wo der private Schlüssel liegt, also im Werkzeug des Dienstes. Die Einrichtungshilfe im Quellenverzeichnis führt zwei Selectoren; planen Sie die Rotation deshalb so, dass der zweite Selector zuerst aktiviert und der erste erst danach abgeschaltet wird.

Schritt 4: DMARC im Monitoring-Modus veröffentlichen

Der DMARC-Record liegt als TXT-Record unter _dmarc.<Ihre Domain> (RFC 9989, Abschnitt 4.5). Beginnen Sie mit p=none und einer Berichtsadresse, wie im Beispiel von RFC 9989, Anhang B.2.1. p=none sagt dem Empfänger, dass Sie wegen dieses Eintrags keine andere Behandlung wünschen; Sie sammeln zunächst nur Berichte. Die Ausrichtung (Alignment) steuern adkim und aspf; beide sind standardmäßig r für relaxed, also gemeinsame Organizational Domain, und können auf s für strikte Gleichheit gestellt werden (Abschnitt 4.7 und 4.4). Diese Fassung ist seit Mai 2026 RFC 9989; das frühere RFC 7489 ist damit überholt. Neu ist unter anderem das Tag t: Der Wert t=y bittet den Empfänger, die Richtlinie nicht anzuwenden, sondern seine eigenen Sonderbehandlungen; der Domaininhaber erwartet dann eine Anwendung eine Stufe unterhalb der angegebenen Richtlinie (bei p=quarantine wie p=none, bei p=reject wie p=quarantine), und auf eine Richtlinie none wirkt das Tag nicht. Der Standardwert t=n verlangt die Anwendung der Richtlinie. Nach Anhang A.6 entsprechen die beiden Werte t=y und t=n in ihrer Anwendung den Werten pct=0 und pct=100 des entfernten Tags pct (Abschnitt 4.7 und Anhang A.6).

Schritt 5: Berichte auswerten und Alignment reparieren

Ohne rua dürfen Empfänger keine aggregierten Berichte erzeugen; nachrichtenbezogene Fehlerberichte fordern Sie mit dem davon unabhängigen Tag ruf an, und ohne ruf dürfen Empfänger sie nicht erzeugen (RFC 9989, Abschnitt 4.7; das Format der Fehlerberichte beschreibt RFC 9991). Auch mit ruf dürfen Empfänger Fehlerberichte nach eigenem Ermessen unterlassen (Abschnitt 5.3.9). Ein gesetztes rua garantiert noch keine Berichte: Empfänger sollen aggregierte Berichte mindestens alle 24 Stunden senden, dürfen aber aus Gründen wie knappen Ressourcen, einer lokalen Richtlinie gegen Datenweitergabe oder Bedenken zum Schutz der Nutzer darauf verzichten (Abschnitt 5.3.8). Hat die Berichtsadresse eine andere Organizational Domain als die Domain, bei der der Record gefunden wurde, muss deren Inhaber den Empfang mit einem TXT-Record der Form <Ihre Domain>._report._dmarc.<Zieldomain> und dem Wert v=DMARC1 freigeben (RFC 9990, Abschnitt 4). RFC 9989 empfiehlt, die Berichte maschinell auszuwerten (Abschnitt 5.1.5). Suchen Sie darin jede Quelle, die spf oder dkim besteht, aber nicht ausgerichtet ist. RFC 9989, Abschnitt 5.1.6 nennt zwei Arten solcher Quellen: legitime Nutzungen Ihrer Domain, deren Authentifizierung fehlt oder nicht ausgerichtet ist, und illegitime Nutzungen wie Spoofing oder andere Missbrauchsversuche. Eine bestehende Quelle ist damit nicht schon als legitim ausgewiesen. Ordnen Sie jede gemeldete Quelle zuerst Ihren eigenen Versandwegen zu, reparieren Sie nur die bestätigten legitimen Quellen (Alignment herstellen, Absender autorisieren) und autorisieren Sie keine Quelle, die Sie nicht Ihrem eigenen Versand zuordnen können.

Schritt 6: Richtlinie auf quarantine und dann auf reject stellen

Ist jede legitime Quelle ausgerichtet, verschärfen Sie stufenweise: zuerst p=quarantine, dann p=reject (redaktionelle Empfehlung). RFC 9989, Abschnitt 7.4 empfiehlt vor p=reject mindestens einen Monat p=none und danach eine ebenso lange Phase mit p=quarantine, wenn Nutzer der Domain an Mailinglisten schreiben. Denken Sie an Subdomains: sp setzt die Richtlinie für bestehende Subdomains, np für nicht existierende, und fehlt ein anwendbares sp oder np, gilt p (Abschnitt 4.7). Für eine registrierte Domain, aus der nie jemand senden soll, ist v=DMARC1; p=reject; der passende Record (Einrichtungshilfe für DMARC im Quellenverzeichnis).

Schritt 7: Reverse DNS und Transport prüfen

Der PTR-Eintrag Ihrer Sende-IP steht unter der Kontrolle des Inhabers dieser IP-Adresse (RFC 7208, Abschnitt 4.6.4); bei einem gemieteten Server ist das Ihr Hoster. Verlangen Sie dort einen Eintrag, der vorwärts und rückwärts zusammenpasst: Der PTR-Name soll auf dieselbe IP-Adresse auflösen (RFC 8601, Abschnitt 2.7.3, Methode iprev). Die Versandrichtlinie im Quellenverzeichnis nennt diese Übereinstimmung für Nachrichten an die Postfächer des dort genannten Dienstes als Pflicht für alle Absender. Verschlüsseln Sie den Versand per TLS. Für den Empfang von Mail an Ihre eigene Domain können Sie zusätzlich MTA-STS veröffentlichen: Ein TXT-Record unter _mta-sts Ihrer Domain und eine Richtliniendatei auf einem HTTPS-Endpunkt verlangen von sendenden Servern, verschlüsselt mit gültigem Zertifikat an Ihre Domain zuzustellen (RFC 8461, Abstract und Abschnitt 3.1). Ebenso können Sie TLS-Berichte anfordern: Ein TXT-Record unter _smtp._tls Ihrer Domain lässt sendende Systeme Ihnen TLS-Fehler beim Empfang melden (RFC 8460, Abstract und Abschnitt 3). Beide Einträge regeln den Mailempfang bei Ihrer Domain; den Versand Ihrer Bestellbestätigungen an fremde Postfächer sichern sie nicht.

Schritt 8: Regeln der Postfachanbieter prüfen

Die Versandrichtlinie im Quellenverzeichnis verlangt von Absendern an die Postfächer des dort genannten Dienstes SPF oder DKIM, einen passenden PTR-Eintrag, TLS und eine im Werkzeug des Dienstes gemessene Spamrate unter 0,3 Prozent. Ab mehr als 5.000 Nachrichten pro Tag an dessen Postfächer kommen SPF, DKIM und DMARC dazu, die Ausrichtung der From-Domain sowie das Abmelden mit einem Klick für Marketing- und Abo-Nachrichten (RFC 8058); diese Stufe gilt seit 1. Februar 2024. Als Folge nicht authentifizierter Nachrichten nennt die Richtlinie unter anderem die Ablehnung mit dem Fehler 5.7.26. Für Dienste, die eine Nachricht unterwegs verändern und dabei die Ergebnisse der Authentifizierung erhalten sollen, beschreibt die Dokumentation im Quellenverzeichnis mit ARC (Authenticated Received Chain) einen Baustein.

Schritt 9: Nach jeder Änderung erneut prüfen

Arbeiten Sie die Prüfliste unten nach jedem Eingriff durch und halten Sie Ergebnis, Datum und Bearbeiter fest. Senken Sie vor einer Änderung die TTL des betroffenen Eintrags (redaktionelle Empfehlung), sonst sehen Empfänger den alten Wert bis zum Ablauf des Zwischenspeichers.

Die DNS-Einträge im Überblick

Die Tabelle zeigt die Einträge, die ein Shop für den Versand braucht; die beiden letzten Zeilen sind optional und betreffen den Empfang von Mail bei Ihrer Domain. beispiel-shop.example steht für Ihre Domain, 203.0.113.10 für die IP-Adresse Ihres Ausgangsservers; beide sind Platzhalter, die IP-Adresse stammt aus dem für Beispiele reservierten Block (RFC 5737). Der Selector 20261014 ist ein erfundenes Beispiel für ein Rotationsdatum.

Eintrag	Name in der Zone	Typ	Beispielwert	Zweck
SPF	beispiel-shop.example	TXT	v=spf1 include:spf.versanddienst.example ip4:203.0.113.10 -all	autorisiert die genannten Server (RFC 7208, Abschnitt 5)
SPF ohne Versand	beispiel-shop.example	TXT	v=spf1 -all	kein Server darf die Domain nutzen (Einrichtungshilfe für SPF im Quellenverzeichnis)
DKIM	20261014._domainkey.beispiel-shop.example	TXT	v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...	veröffentlicht den öffentlichen Signaturschlüssel (RFC 6376, Abschnitt 3.6.1)
DKIM beim Dienst	selector1._domainkey.beispiel-shop.example	CNAME	Ziel, das der Versanddienst nennt	Alias auf den TXT-Record des Dienstes; der private Schlüssel bleibt dort, die Rotation steuert das Werkzeug des Dienstes (Einrichtungshilfe für DKIM im Quellenverzeichnis)
DMARC Monitoring	_dmarc.beispiel-shop.example	TXT	v=DMARC1; p=none; rua=mailto:dmarc@beispiel-shop.example	Berichte sammeln, Zustellung unverändert (RFC 9989, Anhang B.2.1)
DMARC verschärft	_dmarc.beispiel-shop.example	TXT	v=DMARC1; p=reject; rua=mailto:dmarc@beispiel-shop.example	fehlgeschlagene Nachrichten abweisen (RFC 9989, Abschnitt 4.7)
DMARC im Testlauf	_dmarc.test.beispiel-shop.example	TXT	v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel-shop.example; t=y	Richtlinie ankündigen, im Testlauf aber eine Stufe darunter anwenden, hier p=quarantine also wie p=none (RFC 9989, Abschnitt 4.7 und Anhang B.2.5)
Berichte an Dritte	beispiel-shop.example._report._dmarc.auswerter.example	TXT	v=DMARC1	erlaubt einer fremden Domain, Ihre Berichte zu empfangen (RFC 9990, Abschnitt 4)
MTA-STS, optional	_mta-sts.beispiel-shop.example	TXT	v=STSv1; id=20261014085700Z	verlangt von Sendern verschlüsselte Zustellung an Ihre Domain (Empfangsschutz, nicht Versand; RFC 8461, Abschnitt 3.1)
TLS-Berichte, optional	_smtp._tls.beispiel-shop.example	TXT	v=TLSRPTv1; rua=mailto:tls@beispiel-shop.example	Sender melden Ihnen fehlgeschlagene TLS-Verbindungen beim Empfang (Empfangsschutz, nicht Versand; RFC 8460, Abschnitt 3)

So prüfen Sie das Ergebnis

Fragen Sie jeden Eintrag selbst ab, statt sich auf die Anzeige im Shopsystem zu verlassen. dig gibt mit +short nur den Inhalt aus (Manpage im Quellenverzeichnis).

1. dig +short TXT beispiel-shop.example gibt genau einen SPF-Record aus, der mit v=spf1 beginnt; zwei solche Records bei einer Domain sind ein Fehler (RFC 7208, Abschnitt 3.2).
2. dig +short TXT 20261014._domainkey.beispiel-shop.example gibt einen Wert mit v=DKIM1 und gefülltem p= aus. Ist der Name als CNAME auf den Dienst geführt, folgt die Abfrage dem Alias und gibt den TXT-Record des Ziels aus (RFC 1034, Abschnitt 3.6.2); dig +short CNAME <Name> zeigt den Aliasnamen.
3. dig +short TXT _dmarc.beispiel-shop.example beginnt mit v=DMARC1; und enthält die gewählte Richtlinie und rua.
4. Zählen Sie die DNS-auslösenden Begriffe, die Ihr SPF-Record auswertet: include, a, mx, ptr, exists und redirect zusammen höchstens zehn, verschachtelte include- und redirect-Auswertungen eingerechnet (RFC 7208, Abschnitt 4.6.4 und 4.1).
5. Prüfen Sie die Länge: SPF-Record, Name und übrige TXT-Records derselben Domain sollen zusammen unter 450 Oktett bleiben (RFC 7208, Abschnitt 3.4).
6. dig -x 203.0.113.10 gibt einen PTR-Namen aus, und dig +short A <dieser Name> gibt dieselbe IP-Adresse zurück (RFC 8601, Abschnitt 2.7.3).
7. Senden Sie eine Testbestellung an jedes Testpostfach und lesen Sie dort den Nachrichtenkopf: DKIM-Signature mit d= und s=, dazu Authentication-Results mit den Ergebnissen der Methoden spf, dkim und dmarc (RFC 8601, Abschnitt 2.7; die Methode dmarc mit ihren Ergebniscodes führt RFC 9989, Abschnitt 9.2).
8. Vergleichen Sie s= aus der Signatur mit dem abgefragten DNS-Namen; nur der dort genannte Selector wird ausgewertet.
9. Werten Sie die ersten DMARC-Berichte aus: Jede Quelle, die Sie Ihrem eigenen Versand zuordnen, soll spf oder dkim bestehen und ausgerichtet sein; nicht zuordenbare Quellen sind möglicher Missbrauch Ihrer Domain (RFC 9989, Abschnitt 5.1.6).
10. Wiederholen Sie die Prüfung nach jeder Änderung an Zone, Versanddienst oder Shopsystem und protokollieren Sie das Ergebnis mit Datum.

Wenn etwas nicht klappt

Symptom	Ursache	Behebung
Kein SPF-Record zu finden	Der Name liefert nach der Aliasauflösung kein gültiges TXT-Ergebnis: Der Eintrag liegt unter einem anderen Namen, ein CNAME zeigt auf ein Ziel ohne SPF-TXT-Record, oder der Record wurde als anderer Typ angelegt; SPF wird nur als TXT ausgewertet (RFC 7208, Abschnitte 3.1 und 4.4; RFC 1034, Abschnitt 3.6.2)	TXT-Record mit v=spf1 bei genau dieser Domain anlegen, den Namen abfragen und bei einem CNAME zusätzlich das Aliasziel prüfen
Auswertung endet mit permerror	Mehr als zehn ausgewertete DNS-auslösende Mechanismen und Modifier, verschachtelte include- und redirect-Auswertungen eingerechnet; zusätzlich sollen Implementierungen höchstens zwei leere DNS-Antworten zulassen (RFC 7208, Abschnitt 4.6.4)	include-Ketten zusammenfassen, Adressen mit ip4 und ip6 statt include eintragen
DKIM schlägt fehl, obwohl der Record steht	Der Selector aus s= und der abgefragte DNS-Name stimmen nicht überein; der Name ist ein CNAME und das Ziel antwortet nicht, oder ein Zwischensystem hat signierte Kopfzeilen geändert	Selector aus der Testnachricht auslesen und genau diesen Namen abfragen, bei einem CNAME zusätzlich das Aliasziel; Signatur auf die Kopfzeilen ausdehnen, die unverändert bleiben
dmarc=fail trotz spf=pass und dkim=pass	Authentifizierte Domain und From-Domain haben keine gemeinsame Organizational Domain (RFC 9989, Abschnitt 4.4)	Versand auf eine Subdomain der From-Domain legen oder die Signatur-Domain anpassen, statt sofort zu verschärfen
Authentifizierung besteht, Nachricht landet trotzdem im Spam	Beschwerden, Empfängerliste oder Inhalt; die Versandrichtlinie im Quellenverzeichnis nennt eine im Werkzeug des Dienstes gemessene Spamrate unter 0,3 Prozent als Anforderung	Beschwerderate im Werkzeug des Anbieters messen, ungültige Adressen entfernen, Inhalt und Anzeigename prüfen
Nach einer Änderung gilt weiter der alte Wert	TTL des Eintrags im Zwischenspeicher der Empfänger	Vor der Änderung die TTL senken und nach Ablauf erneut abfragen

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung, wenn mehrere Versanddienste dieselbe Domain nutzen und die Summe ihrer include-Verweise die Grenze von zehn ausgewerteten DNS-auslösenden Begriffen überschreitet, wenn Sie DMARC auf p=reject stellen wollen, ohne alle legitimen Quellen zu kennen, oder wenn Ihr Mailserver beim Hoster steht und Sie PTR-Eintrag und TLS nicht selbst ändern können. Ob und wie Sie DMARC-Berichte auswerten dürfen, die Angaben zu empfangenden Postfächern enthalten, ist eine Datenschutzfrage; klären Sie sie mit Ihrer Datenschutzberatung. Wie Domain, Zertifikat und Absenderadresse zusammenpassen, behandelt Domain wählen und absichern.