SPF, DKIM, DMARC: warum eure E-Mails im Spam landen
Drei DNS-Einträge entscheiden darüber, ob eure Mails ankommen. Was jeder von ihnen prüft, in welcher Reihenfolge Empfänger sie auswerten, und die fünf Fehler, die wir am häufigsten sehen.
E-Mails verschwinden nicht. Sie werden einsortiert. Wenn eure Nachrichten im Spamordner landen oder ganz abgelehnt werden, liegt das in den allermeisten Fällen nicht am Inhalt, sondern daran, dass der Empfänger nicht überprüfen kann, ob die Nachricht wirklich von euch stammt.
Dafür gibt es drei Einträge im DNS eurer Domain. Sie heißen SPF, DKIM und DMARC, sie haben unterschiedliche Aufgaben, und sie ergeben erst zusammen ein Bild. Dieser Text erklärt, was jeder von ihnen tatsächlich prüft und woran es in der Praxis scheitert.
Drei Einträge, drei Aufgaben
SPF beantwortet: Darf dieser Server für diese Domain senden? Ihr hinterlegt im DNS eine Liste der Server, die in eurem Namen Mails verschicken dürfen. Der Empfänger vergleicht die absendende IP-Adresse mit dieser Liste. SPF prüft dabei die Absenderadresse aus dem Umschlag, nicht die, die im Mailprogramm angezeigt wird. Das ist ein wichtiger Unterschied, denn beide können auseinanderfallen.
DKIM beantwortet: Ist die Nachricht unterwegs verändert worden, und stammt sie aus eurem System? Der versendende Server signiert jede Nachricht kryptografisch. Der öffentliche Schlüssel liegt im DNS, der private auf dem Mailserver. Der Empfänger prüft die Signatur. Anders als SPF überlebt DKIM eine Weiterleitung, weil die Signatur an der Nachricht hängt und nicht an der IP-Adresse.
DMARC beantwortet: Was soll passieren, wenn die Prüfung fehlschlägt, und wer erfährt davon? DMARC ist die Klammer. Es legt fest, ob eine nicht bestandene Prüfung zu Zustellung, Quarantäne oder Ablehnung führt, und es schickt euch Berichte darüber, wer in eurem Namen sendet.
Ausrichtung ist der Punkt, den alle übersehen
DMARC prüft nicht einfach, ob SPF oder DKIM bestanden haben. Es prüft zusätzlich, ob die dabei geprüfte Domain zu der Domain passt, die der Empfänger im Absenderfeld sieht. Das nennt sich Ausrichtung, englisch Alignment.
Der Grund ist naheliegend: Ein Angreifer kann eine eigene Domain mit tadellosem SPF betreiben und trotzdem in eurem Namen schreiben. Ohne Ausrichtung wäre die Prüfung bestanden und die Fälschung durchgewunken.
Für DMARC genügt es, wenn eine der beiden Prüfungen bestanden und ausgerichtet ist. In der Praxis ist das meistens DKIM, weil SPF bei Weiterleitungen bricht. Genau deshalb reicht SPF allein nicht aus, auch wenn es der Eintrag ist, den die meisten zuerst setzen.
; SPF: genau EIN Eintrag je Domain
beispiel.de. TXT "v=spf1 include:_spf.euer-anbieter.de -all"
; DKIM: je Selektor ein Eintrag, den Selektor gibt der Mailserver vor
selektor._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
; DMARC: Regel plus Berichtsadresse
_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:qznep@orvfcvry.qr; adkim=r; aspf=r"
Die fünf Fehler, die wir am häufigsten sehen
Erstens: zwei SPF-Einträge. Eine Domain darf genau einen haben. Kommt ein zweiter dazu, weil ein Newslettertool seinen eigenen Eintrag verlangt hat, ist das Ergebnis nicht etwa die Summe beider, sondern ein Fehler, und die Prüfung fällt durch. Zusätzliche Versender gehören per include: in den vorhandenen Eintrag.
Zweitens: zu viele DNS-Abfragen. SPF erlaubt höchstens zehn Auflösungen. Jedes include: zählt, und jedes davon kann selbst weitere enthalten. Wer drei Dienstleister einbindet, reißt die Grenze schneller als gedacht. Das Ergebnis ist ein PermError, und der zählt als nicht bestanden.
Drittens: DMARC steht seit zwei Jahren auf p=none. Das ist die Beobachtungsstellung. Sie richtet keinen Schaden an, sie schützt aber auch nicht. Sie ist als Zwischenschritt gedacht, nicht als Dauerzustand.
Viertens: der Newsletter ist vergessen. Mailings, Rechnungsversand aus der Warenwirtschaft, Formularmails aus der Website: Jedes System, das in eurem Namen sendet, braucht Berücksichtigung in SPF und möglichst eine eigene DKIM-Signatur. Sonst schaltet ihr mit einer schärferen DMARC-Regel den eigenen Rechnungsversand ab.
Fünftens: DKIM signiert eine andere Domain. Viele Dienstleister signieren standardmäßig mit ihrer eigenen Domain. Die Signatur ist dann gültig, aber nicht ausgerichtet, und DMARC schlägt trotzdem fehl. Die Lösung ist ein eigener Selektor auf eurer Domain, den praktisch jeder Anbieter unterstützt.
Weiterleitungen, Subdomains und geerbte Altlasten
Weiterleitungen brechen SPF, und zwar immer. Leitet ein Empfänger eure Nachricht an eine andere Adresse weiter, sendet ab diesem Moment sein Server, nicht eurer. Die IP-Adresse steht nicht in eurem SPF-Eintrag, die Prüfung fällt durch. Das ist kein Fehler in eurer Konfiguration, sondern die Bauart des Verfahrens. Es ist zugleich der beste Grund, DKIM nicht als Kür zu behandeln: Die Signatur überlebt den Umweg, und DMARC ist damit weiterhin zufrieden.
Subdomains erben nicht automatisch. Ein DMARC-Eintrag auf der Hauptdomain gilt zwar für Subdomains, ein SPF-Eintrag jedoch nicht. Versendet ihr aus shop.beispiel.de oder news.beispiel.de, brauchen diese Namen eigene Einträge. Für Subdomains, aus denen niemals gesendet wird, ist ein ausdrücklich leerer SPF-Eintrag die saubere Lösung.
Alte Einträge bleiben stehen. Wir sehen regelmäßig SPF-Einträge, in denen Dienstleister stehen, die seit Jahren nicht mehr im Einsatz sind. Jeder davon kostet eine der zehn Abfragen und erlaubt einem fremden System weiterhin, in eurem Namen zu senden. Ein Providerwechsel ist der richtige Moment, den Eintrag einmal komplett neu zu schreiben statt ihn zu ergänzen.
Aus Kür ist Pflicht geworden
Lange galt E-Mail-Authentifizierung als Fleißaufgabe. Das hat sich geändert.
Google und Yahoo verlangen seit Februar 2024 von Versendern mit größeren Mengen an Privatkundenpostfächer, dass SPF und DKIM bestehen und ein DMARC-Eintrag vorhanden ist. Microsoft hat am 5. Mai 2025 nachgezogen, mit denselben Grundanforderungen für Absender oberhalb von 5.000 Nachrichten pro Tag an Outlook.com und die verwandten Dienste.
Die genannten Schwellen betreffen den Massenversand. Die Richtung gilt aber für alle: Wer nicht authentifiziert, wird zunehmend aussortiert, und zwar unabhängig davon, wie harmlos die Nachricht ist. Für einen Betrieb, der Angebote und Rechnungen per Mail verschickt, ist das kein Randthema.
Praktisch heißt das: SPF und DKIM gehören eingerichtet, DMARC gehört gesetzt und nach einer Beobachtungsphase verschärft. In dieser Reihenfolge.
dig +short TXT beispiel.de
dig +short TXT _dmarc.beispiel.de
dig +short TXT selektor._domainkey.beispiel.de
Der Weg von p=none zu p=reject
Setzt DMARC zunächst auf p=none mit einer Berichtsadresse und lest die Berichte einige Wochen. Sie zeigen euch jedes System, das in eurem Namen sendet, auch die vergessenen.
Sind alle legitimen Absender abgedeckt, geht es auf p=quarantine. Bleibt es dabei ruhig, folgt p=reject. Wer diesen Weg abkürzt, schaltet zuverlässig etwas ab, das gebraucht wird.
Wenn eure Postfächer bei uns liegen, sind SPF und DKIM eingerichtet, sobald die Domain zeigt. Was wir nicht wissen können, sind eure zusätzlichen Versender. Sagt uns, welche es gibt, dann bauen wir den Eintrag gemeinsam so, dass er unter der Grenze von zehn Abfragen bleibt. Mehr zu den Postfächern steht auf der E-Mail-Seite.
Häufige Fragen zu SPF, DKIM und DMARC
Zustellung einmal richtig aufsetzen
Nennt uns eure Domain und alle Systeme, die in eurem Namen senden. Wir prüfen die Einträge, räumen Doppelungen auf und begleiten den Weg bis p=reject.