SPF, DKIM und DMARC: Zustellbarkeit von Newslettern erklärt

Zuletzt geprüft: 18.10.2026

Eine E-Mail kann technisch verschickt sein und trotzdem nie gelesen werden – weil sie im Spam-Ordner landet oder abgelehnt wird. Große Postfachanbieter entscheiden das anhand vieler Signale. Zwei davon können Absender selbst steuern: ob die E-Mail nachweislich von ihnen stammt und ob die Empfänger sie haben wollen.

Drei Prüfungen, kurz erklärt

Verfahren	prüft	wo es steht	Norm
SPF (Sender Policy Framework)	Darf dieser Server für diese Domain E-Mails senden?	TXT-Eintrag im DNS der Absenderdomain mit der Liste erlaubter Server	RFC 7208¹
DKIM (DomainKeys Identified Mail)	Ist die E-Mail unterwegs unverändert geblieben, und steht eine Domain mit ihrer Signatur dafür ein?	digitale Signatur im E-Mail-Kopf; öffentlicher Schlüssel im DNS	RFC 6376²
DMARC	Passt die sichtbare Absenderadresse (From) zu einer bestandenen SPF- oder DKIM-Prüfung – und was soll der Empfänger tun, wenn nicht?	TXT-Eintrag `_dmarc.` im DNS	RFC 9989 (Mai 2026, ersetzt RFC 7489 und RFC 9091)³

DMARC-Richtlinien: p=none (keine Vorgabe, nur beobachten), p=quarantine (verdächtig, z. B. in den Spam-Ordner) und p=reject (ablehnen). Mit Berichten (rua=) erfahren Sie, wer in Ihrem Namen E-Mails verschickt – auch, ob Ihr Newsletter-System richtig eingerichtet ist. Der frühere Prozent-Schalter pct ist in der aktuellen Fassung (RFC 9989) entfallen; an seine Stelle tritt der Testmodus t=y bzw. t=n. In Anleitungen nach der älteren Fassung RFC 7489⁴ finden Sie pct noch. Wie die Berichte aufgebaut sind, beschreiben die begleitenden RFC 9990 (Sammelberichte) und RFC 9991 (Fehlerberichte).³

Quellen

RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, IETF / RFC Editor, Abschnitte 2.1, 3.2, 4.5, 4.6.2, 4.6.4, 5.5 und Beispiele in Abschnitt 3 und Anhang (Abruf rfc-editor.org/rfc/rfc7208.txt, 18.10.2026); Abschnitte 2.6, 10.1.1, 10.1.2, Anhang D (Begriffsseite SPF) (abgerufen am 02.11.2026)
RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures, IETF / RFC Editor, Abschnitt 1 (Einleitung); Abschnitte 3.3.3, 3.6.2.1, 4, 5.2, Anhang A.2, A.3, C.1 (abgerufen am 02.11.2026)
RFC 9989 – Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF / RFC Editor, Abschnitt 4.7 (Tags np, sp, t, fo, ruf), 4.10 (mehrere DMARC-Einträge werden verworfen), 5.1.4–5.1.7 (Einführung: p=none mit rua, Berichte auswerten, dann über Enforcement entscheiden), 11.6 (externe Berichtsadressen), 9.3 (Registry), Anhang A.6 (Wegfall pct); Abschnitte 4.4, 4.5, 7.1, Anhang A.6 und B.2 (Begriffsseiten) (abgerufen am 02.11.2026)
RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC), IETF / RFC Editor, Abschnitt 6.3 (Tag pct) (abgerufen am 18.10.2026)

SPF-Eintrag erstellen und prüfen

Ein SPF-Eintrag ist ein TXT-Eintrag im DNS der Absenderdomain. Er beginnt immer mit v=spf1; danach folgen Bausteine, die erlaubte Absender beschreiben, und am Ende eine Regel für alle übrigen Server.

Baustein	Bedeutung
`ip4:192.0.2.10`, `ip6:2001:db8::/32`	eine einzelne Adresse oder ein ganzes Netz darf senden
`a`, `mx`	die Server, auf die der A- bzw. AAAA-Eintrag (`a`) oder der MX-Eintrag (`mx`) der Domain zeigt, dürfen senden
`include:_spf.example.net`	übernimmt die erlaubten Server einer anderen Domain – typisch für das Versandsystem, das Ihren Newsletter verschickt
`-all`	alle anderen Server sind nicht berechtigt (Ergebnis „fail“)
`~all`	alle anderen sind „wahrscheinlich nicht berechtigt“ (Ergebnis „softfail“, eine schwächere Aussage)

Ein Beispiel aus RFC 7208 selbst lautet v=spf1 ip4:192.0.2.0/24 mx -all: Das Netz 192.0.2.0/24 und die Mailserver der Domain dürfen senden, sonst niemand. Die Adressen und example.net oben sind Beispielwerte; was Ihr Versandsystem eintragen lässt, steht in dessen Anleitung.

Fünf Prüfpunkte nach RFC 7208:

Nur ein Eintrag je Domain. Findet der Empfänger mehr als einen Eintrag mit v=spf1, ist das Ergebnis ein Fehler („permerror“, Abschnitt 4.5).¹ Ein neues Versandsystem kommt deshalb in den bestehenden Eintrag, nicht in einen zweiten.
Höchstens zehn DNS-Abfragen. include, a, mx, ptr, exists und redirect lösen Abfragen aus; mehr als zehn führen ebenfalls zu „permerror“ (Abschnitt 4.6.4).¹ ip4, ip6 und all zählen nicht. Ein include zählt mit allem, was im eingebundenen Eintrag steht. Daneben sollen Prüfer höchstens zwei Abfragen ohne Ergebnis („void lookups“) zulassen, und ein mx darf höchstens zehn Adressabfragen auslösen (ebenfalls Abschnitt 4.6.4).
Kein ptr. Der Baustein soll laut RFC 7208 nicht mehr veröffentlicht werden (Abschnitt 5.5).¹
Ein klares Ende. Wer will, dass Empfänger nicht berechtigte Absender eindeutig erkennen können, muss den Eintrag mit -all abschließen (Abschnitt 2.1).¹ Ohne Abschluss ist keine eindeutige Aussage möglich.
SPF allein reicht nicht für DMARC. SPF prüft den Absender im Umschlag der E-Mail („MAIL FROM“) und den Namen des sendenden Servers („HELO“), nicht die sichtbare Absenderzeile. DMARC verlangt zusätzlich, dass diese Domain zur sichtbaren Absenderadresse passt (Ausrichtung, siehe Tabelle oben).

Zusammenstellen lässt sich der Eintrag mit dem SPF-Baukasten: Er zählt die DNS-Abfragen der Bausteine, die Sie eintragen, prüft aber nichts live. Ob der Eintrag richtig veröffentlicht ist, zeigen die DMARC-Berichte oder Ihr DNS-Anbieter.

Was die großen Postfachanbieter verlangen

Anbieter	gilt für	Anforderungen (Auszug)	seit
Gmail	alle Absender an Gmail-Konten; strengere Regeln ab 5.000 Nachrichten pro Tag	alle: SPF oder DKIM; ab 5.000 pro Tag: SPF, DKIM, DMARC, Abmeldung mit einem Klick; Spamrate in den Postmaster Tools unter 0,3 % (empfohlen: unter 0,1 %)	beides 1. Februar 2024⁵
Yahoo	Massenversender (Yahoo nennt keine feste Zahl)	SPF und DKIM, DMARC mindestens `p=none`, From-Domain passend zu SPF oder DKIM; funktionierender List-Unsubscribe-Kopf (Ein-Klick-Verfahren nach RFC 8058 dringend empfohlen); Abmeldungen innerhalb von 2 Tagen umsetzen; Spamrate unter 0,3 %⁶	Februar 2024
Outlook.com (Microsoft)	Domains mit mehr als 5.000 E-Mails pro Tag an Outlook.com-Konten	SPF und DKIM bestehen, DMARC mindestens `p=none` (empfohlen `p=reject`), ausgerichtet an SPF oder DKIM; sonst Junk-Ordner; bleiben die Probleme bestehen, kann Microsoft die E-Mails ablehnen (Fehler 550 5.7.515)⁷	5. Mai 2025⁷

Auch wer weniger verschickt, sollte SPF, DKIM und DMARC einrichten: Gmail verlangt von allen Absendern mindestens SPF oder DKIM, und Microsoft empfiehlt allen Absendern alle drei Verfahren.⁵,⁷ Laut Google schützt die Authentifizierung Empfänger vor Spoofing und Phishing und den Absender vor Identitätsdiebstahl.⁵

Abmeldung mit einem Klick

RFC 8058 beschreibt, wie ein E-Mail-Kopf (List-Unsubscribe und List-Unsubscribe-Post) signalisiert, dass sich Empfänger mit einem einzigen Klick abmelden können⁸ – ohne Webseite und ohne Bestätigungsschritt. Das Postfachprogramm zeigt dann z. B. einen Link „Abbestellen“ neben dem Absender. Den Abmeldelink im Text der E-Mail ersetzt das nicht.

Häufige Ursachen für Spam-Ordner

Absenderdomain ohne SPF/DKIM/DMARC oder Versand über einen Dienst, der nicht im SPF-Eintrag steht.
Gekaufte oder alte Adresslisten: viele Rückläufer und Spam-Meldungen.
Abmeldung versteckt oder langsam – Empfänger klicken dann auf „Spam“.
Plötzlich stark steigende Versandmengen: Google nennt als Beispiel, dass schon eine sofortige Verdoppelung zu einer Begrenzung der Versandrate oder zu einem schlechteren Ruf führen kann.⁵

Werkzeug

Den passenden DMARC-Eintrag können Sie mit unserem DMARC-Baukasten zusammenstellen, einen SPF-Eintrag mit dem SPF-Baukasten – beide laufen im Browser und erklären jede Option (Werkzeuge).