SPF, DKIM & DMARC einrichten: E-Mail-Versanddomain korrekt authentifizieren

mailwissen.de · Aktualisiert am 26. September 2026

Eine zuverlässige E-Mail-Authentifizierung beginnt nicht mit dem Kopieren einzelner DNS-Einträge. Sie müssen zunächst alle legitimen Versandquellen erfassen, SPF und DKIM passend konfigurieren und das für DMARC erforderliche Alignment herstellen. Dieser Artikel führt Sie durch den gesamten Ablauf bis zur Kontrolle realer Testmails und zeigt, welche typischen Konfigurationsfehler Sie vermeiden sollten.

Wer E-Mails über eine eigene Domain versendet, muss heute mehr beachten als einen einzelnen DNS-Eintrag. Mailboxen, Newsletter-Dienste, CRM-Systeme, Shops, Helpdesks und Website-Formulare können jeweils eigene technische Absender verwenden. Damit empfangende Mailserver diese Nachrichten Ihrer Domain zuverlässig zuordnen können, greifen SPF, DKIM und DMARC ineinander.

Gerade für Bulk-Sender sind die Anforderungen hoch: Google und Yahoo verlangen SPF und DKIM sowie DMARC mit passendem Identifier Alignment. Eine korrekte Authentifizierung schützt außerdem davor, dass Dritte Ihre Domain ohne Weiteres als sichtbaren Absender für gefälschte Nachrichten verwenden.

Wichtig ist allerdings die Abgrenzung: Eine technisch korrekt authentifizierte E-Mail hat dadurch keine Garantie auf einen Platz im Posteingang. Reputation, Inhalt und die Bewertung durch Spamfilter spielen weiterhin eine Rolle.

Der richtige Weg besteht deshalb nicht darin, drei DNS-Einträge aus einer Anleitung zu kopieren. Zuerst müssen Sie wissen, welche Systeme tatsächlich über Ihre Domain versenden und welche Domains diese technisch verwenden. Anschließend richten Sie SPF und DKIM ein, stellen das für DMARC notwendige Alignment her und prüfen das Ergebnis an real versendeten Nachrichten.

Die vier E-Mail-Identitäten: Was wird eigentlich authentifiziert?

Um SPF, DKIM und DMARC richtig einzurichten, müssen Sie zunächst vier unterschiedliche Identitäten auseinanderhalten.

Eine einfache Analogie hilft: Stellen Sie sich eine E-Mail wie einen Brief vor. Auf dem Briefkopf steht der für den Empfänger sichtbare Absender. Auf dem Umschlag können dagegen technische Angaben für Transport und Rücksendung stehen. Bei E-Mails können diese Domains voneinander abweichen.

1. Header-From: die sichtbare Absenderdomain

Das Header-From ist die Absenderadresse, die der Empfänger normalerweise in seinem E-Mail-Programm sieht. Bei [email protected] ist beispiel.de die sichtbare Absenderdomain.

Genau diese sichtbare Domain steht bei DMARC im Mittelpunkt: DMARC soll die Domain schützen, die gegenüber dem Empfänger als Absender auftritt.

2. Envelope-From beziehungsweise Return-Path

Beim SMTP-Transport existiert zusätzlich eine technische Absenderidentität, die MAIL-FROM-Domain. Sie begegnet Ihnen bei empfangenen Nachrichten häufig als Return-Path.

SPF prüft primär diese technische Domain. Sie muss nicht zwangsläufig mit der sichtbaren Header-From-Domain identisch sein.

Das ist besonders bei externen Versanddiensten wichtig: Ein Anbieter kann Ihre Domain im sichtbaren From verwenden, während für den technischen Rückkanal eine andere Domain eingesetzt wird.

3. DKIM Signing Domain

DKIM versieht eine Nachricht mit einer kryptografischen Signatur. Zu dieser Signatur gehört das d=-Tag, das die für die Signatur verwendete Domain bezeichnet.

Diese DKIM-Domain ist für DMARC ebenfalls wichtig, weil geprüft werden kann, ob sie zur sichtbaren Absenderdomain passt.

4. DMARC Policy Domain

Die DMARC-Richtlinie Ihrer Domain wird unter dem DNS-Namen

_dmarc.<domain>

veröffentlicht. Für beispiel.de wäre das entsprechend _dmarc.beispiel.de.

Entscheidend für die weitere Einrichtung ist damit nicht nur die Frage, ob SPF und DKIM technisch funktionieren. Sie müssen auch prüfen, welche Domains SPF und DKIM tatsächlich authentifizieren und wie diese zur sichtbaren Header-From-Domain stehen.

Schritt 1: Alle legitimen Versandquellen inventarisieren

Beginnen Sie nicht mit Änderungen am DNS.

Erfassen Sie zuerst jedes System, das legitime E-Mails mit Ihrer Domain als Absender verschickt. Dieser Schritt ist besonders wichtig, bevor Sie DMARC später von einer reinen Beobachtungsrichtlinie auf p=quarantine oder p=reject verschärfen.

Zur Inventur können beispielsweise gehören:

• die primäre Mailbox-Plattform wie Google Workspace oder Microsoft 365
• Newsletter- und andere E-Mail-Marketing-Dienste
• CRM-Systeme
• Shop- und ERP-Systeme
• Helpdesk- oder Support-Systeme
• Kontaktformulare und andere Versandfunktionen Ihrer Website

Prüfen Sie dabei auch organisatorisch, wer Zugriff auf das DNS Ihrer Domain hat und wer die jeweiligen Versanddienste verwaltet. Sie benötigen beide Seiten: Die Authentifizierungsdaten werden häufig vom Versanddienst vorgegeben, veröffentlicht werden müssen sie jedoch im DNS der Domain.

Der aktuelle DMARC-Standard sieht ausdrücklich vor, legitime, noch nicht korrekt authentifizierte Versandströme zu identifizieren und zu beheben, bevor eine durchsetzende DMARC-Policy aktiviert wird.

Schritt 2: SPF richtig konfigurieren

SPF legt fest, welche Systeme für die betreffende Domain E-Mails versenden dürfen. Die Richtlinie wird als TXT-Record im DNS veröffentlicht.

Ein SPF-Eintrag kann beispielsweise mit

v=spf1

beginnen, anschließend zulässige Versandquellen enthalten und mit einem Mechanismus wie ~all enden.

Welche Quellen konkret in Ihren SPF-Record gehören, hängt von Ihren tatsächlichen Versanddiensten ab. Anbieterwerte dürfen deshalb nicht ungeprüft von einem anderen Dienst übernommen werden.

Google Workspace gibt beispielsweise für den Versand über seinen Dienst den Wert

v=spf1 include:_spf.google.com ~all

vor. Das ist eine anbieterspezifische Vorgabe für Google Workspace und keine allgemeine SPF-Konfiguration für jede Domain.

Pro Domain darf nur ein SPF-Record existieren

Wenn bereits ein SPF-Record vorhanden ist und ein weiterer Versanddienst hinzukommt, dürfen Sie nicht einfach einen zweiten SPF-TXT-Record für dieselbe Domain anlegen.

Die zulässigen Quellen müssen in einem gemeinsamen SPF-Record zusammengeführt werden. Anbieter können dafür beispielsweise einen include:-Mechanismus vorgeben.

Das 10-DNS-Lookup-Limit beachten

Auch ein einzelner SPF-Record kann fehlerhaft werden, wenn seine Auswertung zu viele DNS-Abfragen erfordert.

SPF erlaubt höchstens zehn DNS-abfragende Terme während der Evaluierung. Dazu gehören insbesondere Mechanismen beziehungsweise Modifier wie:

• include
• a
• mx
• ptr
• exists
• redirect

Wird das Limit überschritten, entsteht ebenfalls ein PermError.

ip4, ip6 und all zählen dagegen nicht gegen dieses DNS-Lookup-Limit.

Das ist vor allem dann relevant, wenn im Laufe der Zeit immer mehr Versanddienste über include: in einen SPF-Record aufgenommen werden.

Nicht jeder Drittanbieter gehört automatisch in den SPF der Hauptdomain

Ein häufiger Fehler besteht darin, pauschal jeden externen E-Mail-Dienst in den SPF-Record der sichtbaren Absenderdomain aufzunehmen.

Das ist nicht immer erforderlich. Manche E-Mail-Marketing-Dienste verwenden für den technischen MAIL FROM eine eigene Domain. In diesem Fall wird SPF gegen diese technische Anbieter-Domain geprüft und ein SPF-Eintrag auf Ihrer sichtbaren Hauptdomain erfüllt für diesen Versand nicht automatisch den erwarteten Zweck.

Prüfen Sie deshalb für jeden Versanddienst dessen konkrete Vorgaben, statt SPF-Werte aus allgemeinen Anleitungen zu kopieren.

Schritt 3: DKIM einrichten und die Signierung aktivieren

DKIM ergänzt SPF um eine kryptografische Signatur der Nachricht. Der Versanddienst signiert ausgehende E-Mails mit einem privaten Schlüssel. Der passende öffentliche Schlüssel wird über das DNS bereitgestellt und kann vom empfangenden System zur Prüfung der Signatur verwendet werden.

DKIM-Selector und DNS-Pfad

DKIM verwendet sogenannte Selectoren. Dadurch können für eine Domain unterschiedliche beziehungsweise wechselnde Schlüssel eingesetzt werden.

Der DNS-Pfad folgt grundsätzlich diesem Muster:

<selector>._domainkey.<domain>

Welche Werte Sie dort veröffentlichen müssen, gibt der jeweilige Versanddienst vor. Je nach Anbieter kann die Veröffentlichung über einen TXT-Record oder eine CNAME-Delegierung erfolgen.

1024 Bit sind Minimum, 2048 Bit die Empfehlung

Bei RSA-DKIM-Schlüsseln ist die Unterscheidung zwischen Mindestanforderung und Empfehlung wichtig.

1024 Bit sind nach den aktualisierten DKIM-Vorgaben das vorgeschriebene technische Minimum. 2048 Bit werden empfohlen. Die pauschale Behauptung, ein 1024-Bit-DKIM-Schlüssel sei grundsätzlich ungültig oder nicht standardkonform, ist daher nicht korrekt.

Wenn Ihr Dienst 2048-Bit-Schlüssel unterstützt und anbietet, entspricht dies der aktuellen Empfehlung.

Der DNS-Eintrag allein aktiviert DKIM nicht

Ein besonders leicht zu übersehender Schritt folgt nach der Veröffentlichung des DNS-Eintrags: Der Versanddienst muss ausgehende Nachrichten tatsächlich mit DKIM signieren.

Je nach Dienst ist dafür nach dem Anlegen beziehungsweise Erkennen des DNS-Eintrags noch eine Aktivierung im Administrationsbereich notwendig.

Ein vorhandener Public Key im DNS beweist daher noch nicht, dass Ihre realen Nachrichten DKIM-signiert versendet werden.

Schritt 4: DMARC und Identifier Alignment herstellen

SPF und DKIM beantworten zunächst technische Authentifizierungsfragen. DMARC verbindet diese Ergebnisse mit der Domain, die der Empfänger tatsächlich im From-Feld sieht.

Dafür ist das sogenannte Identifier Alignment entscheidend.

Was bedeutet Alignment?

Beim SPF-Alignment wird die über SPF geprüfte MAIL-FROM-Domain mit der sichtbaren Header-From-Domain verglichen.

Beim DKIM-Alignment wird entsprechend die DKIM-Signing-Domain aus dem d=-Tag mit der Header-From-Domain verglichen.

Ein einfaches spf=pass oder dkim=pass reicht für einen DMARC-Pass deshalb nicht automatisch aus. Die erfolgreich authentifizierte Domain muss zusätzlich mit der sichtbaren Absenderdomain aligned sein.

Relaxed und Strict Alignment

DMARC unterscheidet zwei Alignment-Modi:

• Relaxed (r): Subdomains können innerhalb des vorgesehenen Domain-Zusammenhangs aligned sein.
• Strict (s): Es wird eine exakte Übereinstimmung verlangt.

Relaxed Alignment ist der Standard. Die entsprechenden Einstellungen sind aspf=r für SPF und adkim=r für DKIM.

Das ist beispielsweise relevant, wenn ein Versanddienst eine Subdomain verwendet. Ein Setup kann unter Relaxed Alignment funktionieren, während dieselbe Domain-Konstellation bei Strict Alignment nicht mehr als aligned gilt.

Für DMARC reicht formal ein aligned Verfahren

Für einen DMARC-Pass muss nach dem DMARC-Protokoll mindestens eines der beiden Verfahren erfolgreich sein und Alignment erreichen:

• SPF besteht und ist aligned, oder
• DKIM besteht und ist aligned.

Hier muss zwischen dem DMARC-Protokoll und zusätzlichen Vorgaben von Mailbox-Providern unterschieden werden. Für Bulk-Sender verlangen Google und Yahoo die Einrichtung von SPF und DKIM sowie DMARC mit Alignment.

Die praktische Konsequenz: Ein DMARC-Pass kann nach dem Protokoll bereits über eines der beiden aligned Verfahren zustande kommen. Daraus folgt aber nicht, dass die strengeren Anforderungen eines Providers für Bulk-Sender bereits erfüllt sind.

Schritt 5: DMARC-Policy schrittweise ausrollen

Der DMARC-Record wird als TXT-Record unter

_dmarc.<domain>

veröffentlicht und beginnt mit:

v=DMARC1

Zu den relevanten DMARC-Tags gehören unter anderem:

• p=none, p=quarantine oder p=reject für die Policy
• rua=mailto:... für Aggregate Reports
• t=y beziehungsweise t=n für den Testmodus

Der sichere Rollout besteht aus mehreren Phasen.

Phase 1: Mit p=none beobachten

Starten Sie zunächst mit p=none.

In dieser Phase können DMARC-Aggregate-Reports über rua Rückmeldungen über beobachtete Versandströme liefern, ohne bereits eine Quarantäne- oder Ablehnungsrichtlinie durchzusetzen.

Die detaillierte Auswertung der XML-Berichte ist ein eigenes Thema. Für die Einrichtung ist zunächst entscheidend, dass Sie die Berichte nutzen, um legitime Versandquellen zu erkennen, die noch nicht korrekt authentifiziert oder aligned sind.

Phase 2: Fehlerhafte legitime Versandquellen korrigieren

Vergleichen Sie die beobachteten Versandströme mit Ihrer Inventur aus Schritt 1.

Taucht beispielsweise ein legitimes CRM, Shopsystem oder Website-Formular auf, dessen Nachrichten DMARC nicht bestehen, sollte dieser Versandweg vor einem Enforcement korrigiert werden.

Wie lange die Beobachtungsphase dauern sollte, lässt sich nicht mit einer pauschalen Frist festlegen. Je nach Versandrhythmus kann eine ausreichende Beobachtung viele Monate erfordern. Eine starre Regel wie „nach 14 Tagen auf Reject wechseln“ ist daher nicht angemessen.

Phase 3: Auf quarantine und anschließend reject umstellen

Erst wenn die legitimen Versandquellen erfasst und die relevanten Authentifizierungs- und Alignment-Probleme behoben sind, kann die Policy schrittweise verschärft werden.

Der Weg führt dabei von der Beobachtung mit p=none zu einer durchsetzenden Policy wie p=quarantine und schließlich gegebenenfalls zu p=reject.

Das frühere pct-Rollout-Modell ist 2026 veraltet

Ältere DMARC-Anleitungen empfehlen teilweise, eine strengere Policy nur auf einen bestimmten Prozentsatz der Nachrichten anzuwenden und diesen Anteil über das pct-Tag schrittweise zu erhöhen.

Dieses Modell sollte für eine aktuelle Einrichtung nicht mehr verwendet werden. RFC 9989 hat das pct-Tag 2026 als historisch eingestuft und aus dem aktuellen DMARC-Modell entfernt.

Ein moderner Rollout basiert stattdessen darauf, zunächst die tatsächlichen Versandquellen zu beobachten und zu korrigieren und anschließend die Policy kontrolliert von none über quarantine bis zu reject zu verändern.

RFC 9989 führt außerdem das optionale t-Tag für den Testmodus ein. Ein entsprechender Record kann beispielsweise t=y enthalten, um diesen Teststatus zu kennzeichnen.

Schritt 6: Einrichtung mit echten Testmails und Headern überprüfen

Nach den DNS-Änderungen ist die Arbeit noch nicht beendet.

Ein DNS-Prüftool kann feststellen, ob bestimmte Records vorhanden und erreichbar sind. Das beweist aber nicht, dass eine tatsächlich verschickte Nachricht korrekt DKIM-signiert wurde, SPF mit der erwarteten Domain besteht und das notwendige DMARC-Alignment erreicht.

Die entscheidende Kontrolle erfolgt deshalb mit echten Nachrichten.

Von jeder Versandquelle eine Testmail senden

Gehen Sie Ihre Inventur aus Schritt 1 erneut durch und verschicken Sie von jeder erfassten Quelle mindestens eine reale Testnachricht an eine externe Test-Mailbox.

Prüfen Sie also nicht nur Ihre normale persönliche Mailbox, sondern beispielsweise auch separat:

• Newsletter-Versand
• CRM-Versand
• Shop- oder ERP-Mails
• Helpdesk-Nachrichten
• Website-generierte E-Mails

So erkennen Sie Konfigurationsprobleme, die nur einen bestimmten Versandweg betreffen.

Authentication-Results im Nachrichtenheader prüfen

Öffnen Sie bei der empfangenen Testnachricht den vollständigen Nachrichtenheader beziehungsweise den Original- oder Quelltext der Nachricht.

Nutzen Sie dazu in Ihrem E-Mail-Programm die Funktion zur Anzeige der vollständigen Nachrichtendetails beziehungsweise des Quelltexts. Je nach Programm kann diese Funktion beispielsweise als „Original anzeigen“ oder „Nachrichten-Header anzeigen“ bezeichnet sein.

Suchen Sie anschließend nach dem Header:

Authentication-Results

Dort dokumentiert das empfangende System die Ergebnisse der Authentifizierungsprüfungen.

Für eine erfolgreich authentifizierte und aligned Nachricht sollten die entsprechenden Ergebnisse insbesondere als

spf=pass

dkim=pass

dmarc=pass

erscheinen.

Betrachten Sie dabei nicht nur das Wort pass, sondern auch die jeweils ausgewerteten Domains. Nur so lässt sich erkennen, ob tatsächlich die erwarteten technischen Identitäten verwendet werden und das notwendige Alignment zustande kommt.

Typische Fehler bei SPF, DKIM und DMARC

Auch wenn die einzelnen DNS-Einträge korrekt aussehen, können einige Konfigurationsfehler das gesamte Setup beeinträchtigen.

Zwei SPF-Records für dieselbe Domain

Ein zusätzlicher Versanddienst wird eingerichtet und erhält kurzerhand einen zweiten SPF-TXT-Record.

Das Ergebnis ist kein „zusätzlicher Schutz“, sondern ein SPF-PermError. Alle zulässigen Quellen müssen in einem einzigen SPF-Record für die betreffende Domain zusammengeführt werden.

Das SPF-Lookup-Limit wird überschritten

Viele include-Mechanismen können dazu führen, dass bei der SPF-Auswertung mehr als zehn DNS-abfragende Terme benötigt werden.

Prüfen Sie deshalb nicht nur, ob Ihr SPF-Record syntaktisch vorhanden ist, sondern auch, ob seine Auswertung innerhalb des zulässigen Limits bleibt.

SPF oder DKIM bestehen, aber DMARC schlägt fehl

Ein pass bei SPF oder DKIM sagt noch nichts darüber aus, ob die dabei authentifizierte Domain zur sichtbaren From-Domain passt.

Bei einem DMARC-Fail trotz erfolgreichem SPF oder DKIM sollten Sie deshalb das Identifier Alignment kontrollieren. Besonders Subdomains und technische Domains von Drittanbietern können hier relevant werden.

DKIM steht im DNS, signiert aber keine Nachrichten

Der DKIM-Key wurde korrekt veröffentlicht, die Signierung im Versanddienst jedoch nicht aktiviert.

Das lässt sich zuverlässig erkennen, indem Sie eine reale Nachricht versenden und deren Authentifizierungsergebnisse prüfen.

Eine Versandquelle wurde vergessen

Shop, CRM, Helpdesk oder Website-Formular werden bei der Inventur leicht übersehen. Solange DMARC nur beobachtet, kann das unauffällig bleiben. Bei einer späteren Verschärfung der Policy können daraus jedoch abgewiesene legitime Nachrichten entstehen.

p=reject wird zu früh aktiviert

Ein sofortiges Enforcement ist riskant, solange nicht bekannt ist, ob sämtliche legitimen Versandströme DMARC bestehen.

Beginnen Sie deshalb mit der Inventur und dem Monitoring, beheben Sie die erkannten Probleme und verschärfen Sie die Policy erst danach.

DMARC-Pass wird mit sicherer Posteingangszustellung verwechselt

SPF, DKIM und DMARC sind ein wichtiger Teil der technischen Absenderauthentifizierung. Sie setzen jedoch Spamfilter nicht außer Kraft.

Checkliste: E-Mail-Domain erfolgreich authentifizieren

Gehen Sie die Einrichtung zum Abschluss noch einmal in dieser Reihenfolge durch:

1. Erfassen Sie alle Systeme, die legitime E-Mails mit Ihrer Domain als Absender versenden.
2. Unterscheiden Sie für diese Versandwege Header-From, Envelope-From beziehungsweise Return-Path und DKIM-Signing-Domain.
3. Prüfen Sie, ob für die betreffende Domain bereits ein SPF-Record existiert.
4. Führen Sie alle notwendigen SPF-Autorisierungen in einem einzigen SPF-Record zusammen.
5. Stellen Sie sicher, dass bei SPF höchstens zehn DNS-abfragende Terme während der Evaluierung erforderlich werden.
6. Übernehmen Sie Drittanbieter nicht pauschal in den SPF der Hauptdomain, sondern berücksichtigen Sie die jeweilige technische MAIL-FROM-Konfiguration und die Vorgaben des Dienstes.
7. Veröffentlichen Sie die vom jeweiligen Versanddienst vorgegebenen DKIM-Daten unter dem passenden Selector und _domainkey.
8. Verwenden Sie bei RSA-DKIM mindestens 1024 Bit; 2048 Bit sind die Empfehlung.
9. Aktivieren Sie nach der DNS-Einrichtung die DKIM-Signierung im jeweiligen Versanddienst, sofern dies dort erforderlich ist.
10. Prüfen Sie das SPF- und DKIM-Alignment mit der sichtbaren Header-From-Domain.
11. Berücksichtigen Sie, dass Relaxed Alignment der DMARC-Standardmodus ist und Strict Alignment eine exakte Übereinstimmung verlangt.
12. Veröffentlichen Sie DMARC als TXT-Record unter _dmarc.<domain> und beginnen Sie mit v=DMARC1.
13. Starten Sie den Rollout zunächst mit p=none und nutzen Sie Aggregate Reports, um noch fehlerhafte legitime Versandströme zu erkennen.
14. Verwenden Sie für einen aktuellen Rollout nicht mehr das historische pct-Modell.
15. Berücksichtigen Sie bei Bedarf den mit RFC 9989 eingeführten Testmodus über das t-Tag.
16. Beheben Sie Authentifizierungs- und Alignment-Probleme legitimer Versandquellen, bevor Sie Enforcement aktivieren.
17. Wechseln Sie erst anschließend kontrolliert zu p=quarantine und gegebenenfalls p=reject.
18. Senden Sie von jeder legitimen Versandquelle eine reale Testnachricht an eine externe Mailbox.
19. Kontrollieren Sie im Authentication-Results-Header SPF, DKIM und DMARC sowie die jeweils verwendeten Domains.
20. Wiederholen Sie die Inventur und Prüfung, wenn Sie später neue Versanddienste hinzufügen.

SPF, DKIM und DMARC sind damit kein einmaliger Satz von DNS-Einträgen, sondern ein zusammenhängender Authentifizierungsprozess. Entscheidend ist, dass Sie alle legitimen Versandwege kennen, die technischen Identitäten korrekt zuordnen, Alignment herstellen und das Ergebnis anschließend an tatsächlich versendeten Nachrichten überprüfen.

So erhalten Sie nicht nur formal vorhandene DNS-Records, sondern eine nachvollziehbar geprüfte Authentifizierung Ihrer realen E-Mail-Versandströme.