SPF, DKIM und DMARC: Der komplette Leitfaden zur E-Mail-Authentifizierung
Meistere E-Mail-Authentifizierung mit diesem umfassenden Leitfaden zu SPF, DKIM und DMARC. Lerne, was jedes Protokoll macht, wie du DNS-Records einrichtest, häufige Probleme behebst und deine E-Mail-Zustellbarkeit verbesserst.
E-Mail-Authentifizierung ist die Grundlage verlässlicher E-Mail-Zustellung. Ohne korrekte SPF-, DKIM- und DMARC-Konfiguration erreichen sorgfältig erstellte E-Mails die Posteingänge deiner Kund:innen vielleicht nie. Stattdessen landen sie im Spam oder werden komplett abgelehnt.
Dieser umfassende Leitfaden erklärt, was jedes E-Mail-Authentifizierungsprotokoll macht, zeigt die DNS-Einrichtung Schritt für Schritt, behandelt häufige Probleme und zeigt, wie du prüfst, ob deine Konfiguration korrekt funktioniert.
Warum E-Mail-Authentifizierung wichtig ist
E-Mail wurde in einer Zeit entworfen, in der Sicherheit kein Hauptanliegen war. Das ursprüngliche SMTP-Protokoll hat keinen eingebauten Prüfmechanismus, der bestätigt, dass eine E-Mail wirklich von der Person oder Domain kommt, die sie vorgibt. Diese grundlegende Schwäche ermöglicht E-Mail-Spoofing, Phishing-Angriffe und Spam.
E-Mail-Authentifizierungsprotokolle lösen dieses Problem, indem Domain-Inhaber:innen festlegen können:
- Welche Server in ihrem Namen E-Mail senden dürfen (SPF)
- Kryptografischen Nachweis, dass Nachrichten echt und unverändert sind (DKIM)
- Was mit Nachrichten passiert, die die Authentifizierung nicht bestehen (DMARC)
Geschäftliche Folgen schwacher Authentifizierung
Ohne korrekte E-Mail-Authentifizierung:
- Niedrigere Zustellbarkeit: Große Anbieter wie Gmail, Microsoft und Yahoo filtern nicht authentifizierte E-Mails aggressiver.
- Höhere Spam-Raten: Deine legitimen E-Mails konkurrieren mit gespooften Nachrichten, die deine Domain nutzen.
- Markenschaden: Phishing-Angriffe, die deine Marke imitieren, schwächen das Vertrauen deiner Kund:innen.
- Umsatzverlust: Marketingkampagnen erreichen Abonnent:innen nicht, die sich aktiv dafür angemeldet haben.
- Compliance-Risiken: Viele Regelwerke verlangen inzwischen korrekte E-Mail-Authentifizierung.
Die Authentifizierungs-Trias
SPF, DKIM und DMARC arbeiten als vollständiges Authentifizierungssystem zusammen:
| Protokoll | Was es macht | Analogie |
|---|---|---|
| SPF | Listet autorisierte sendende Server auf | Firmenbriefkopf mit genehmigten Büros |
| DKIM | Signiert Nachrichten kryptografisch | Wachssiegel als Echtheitsnachweis |
| DMARC | Setzt Policy für Fehler und Reporting | Anweisung, was mit verdächtigen Briefen zu tun ist |
Jedes Protokoll adressiert andere Angriffsvektoren. SPF verhindert, dass nicht autorisierte Server als du senden. DKIM verhindert Manipulationen nach dem Versand. DMARC verbindet beides und gibt Sichtbarkeit in Authentifizierungsergebnisse.
SPF verstehen (Sender Policy Framework)
SPF (Sender Policy Framework) ist eine DNS-basierte Methode zur E-Mail-Authentifizierung, die festlegt, welche Mailserver E-Mails im Namen deiner Domain senden dürfen.
Wie SPF funktioniert
Wenn eine E-Mail bei einem empfangenden Server ankommt, fragt dieser Server den SPF-Record der Senderdomain ab. Danach prüft er, ob die IP-Adresse, die die E-Mail gesendet hat, als autorisiert gelistet ist. Wenn die IP passt, besteht SPF. Wenn nicht, schlägt SPF fehl.
Der SPF-Prüfprozess:
- Du sendest eine E-Mail aus deiner Marketingplattform.
- Der empfangende Server liest deine Domain aus dem Return-Path (Envelope Sender).
- Der Server fragt DNS nach dem SPF-Record deiner Domain.
- Er vergleicht die sendende IP mit der autorisierten Liste im SPF-Record.
- Der Server speichert das Ergebnis: pass, fail, softfail oder neutral.
SPF-Record-Syntax
SPF-Records werden als TXT-Records im DNS deiner Domain veröffentlicht. Die Grundstruktur:
v=spf1 [mechanisms] [qualifier]allVersion-Tag: Beginnt immer mit v=spf1
Mechanismen: Definieren, wer senden darf
| Mechanismus | Beschreibung | Beispiel |
|---|---|---|
| include: | SPF einer anderen Domain vertrauen | include:spf.brevo.com |
| ip4: | Bestimmte IPv4 autorisieren | ip4:192.168.1.1 |
| ip6: | Bestimmte IPv6 autorisieren | ip6:2001:db8::1 |
| a | IPs des A-Records der Domain erlauben | a |
| mx | IPs der Mailserver der Domain erlauben | mx |
| ptr | Reverse DNS (veraltet) | ptr:example.com |
| exists: | Bedingte Prüfung | exists:%{i}.spf.example.com |
Qualifier: Definieren, wie Treffer behandelt werden
| Qualifier | Bedeutung | Ergebnis |
|---|---|---|
| + | Pass (Standard) | Autorisiert |
| - | Fail (hart) | Nicht autorisiert, ablehnen |
| ~ | SoftFail | Nicht autorisiert, annehmen, aber markieren |
| ? | Neutral | Keine Policy |
Der all-Mechanismus: Wird auf alles angewendet, was nicht zu vorherigen Mechanismen passt.
SPF-Record-Beispiele
Grundsetup mit einem E-Mail-Anbieter:
v=spf1 include:spf.brevo.com -allDas autorisiert Brevo, E-Mail für deine Domain zu senden, und lehnt alle anderen Sender ab.
Mehrere E-Mail-Dienste:
v=spf1 include:spf.brevo.com include:_spf.google.com include:spf.protection.outlook.com -allDas autorisiert Brevo, Google Workspace und Microsoft 365.
Eigenen Mailserver einschließen:
v=spf1 ip4:203.0.113.10 include:spf.brevo.com -allDas autorisiert eine bestimmte IP-Adresse (deinen Server) plus Brevo.
Beim Testen mit Soft Fail starten:
v=spf1 include:spf.brevo.com ~all~all statt -all markiert Fehler, lehnt aber nicht ab. Das ist während der Ersteinrichtung nützlich.
SPF-Records einrichten
Schritt 1: Deine sendenden Quellen identifizieren
Liste jeden Dienst auf, der E-Mail von deiner Domain sendet:
- E-Mail-Marketingplattformen (Brevo, Mailchimp usw.)
- Transaktionale E-Mail-Dienste
- CRM-Systeme
- Helpdesk-Software
- Unternehmens-E-Mail (Google Workspace, Microsoft 365)
- Eigene Mailserver
Schritt 2: SPF-Include-Statements sammeln
Jeder E-Mail-Service-Provider dokumentiert den erforderlichen SPF-Include. Häufige Beispiele:
| Anbieter | SPF-Include |
|---|---|
| Brevo | include:spf.brevo.com |
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |
Schritt 3: SPF-Record erstellen
Kombiniere alle Includes in einem Record:
v=spf1 include:spf.brevo.com include:_spf.google.com -allSchritt 4: DNS-Record hinzufügen
In deiner DNS-Verwaltung:
- Type: TXT
- Host/Name: @ (oder leer lassen für die Root-Domain)
- Value: dein vollständiger SPF-Record
- TTL: 3600 (oder Standard)
Schritt 5: Record prüfen
Nutze DNS-Lookup-Tools zur Bestätigung:
dig TXT yourdomain.comOder nutze Online-Tools wie MXToolbox SPF Lookup.
SPF-Grenzen und Best Practices
Das Limit von 10 DNS-Lookups:
SPF erlaubt maximal 10 DNS-Lookups. Jedes include: zählt als ein Lookup, und eingeschlossene Records können eigene Includes enthalten, die ebenfalls zählen. Wenn du das Limit überschreitest, entsteht ein SPF permerror (permanent error), wodurch alle Prüfungen fehlschlagen.
Strategien, um unter dem Limit zu bleiben:
- Nutze direkte IP-Adressen, wenn möglich (
ip4:zählt nicht als Lookup). - Konsolidiere Dienste, die denselben Anbieter nutzen.
- Nutze SPF-Flattening-Services, die Includes in IP-Adressen umwandeln.
- Entferne ungenutzte Includes alter Dienste.
Weitere SPF-Best-Practices:
- Nur ein SPF-Record pro Domain (mehrere Records verursachen Fehler).
- Starte während der Einrichtung mit
~all(softfail) und wechsle zu-all, sobald alles bestätigt ist. - Aktualisiere SPF, wenn du E-Mail-Anbieter wechselst.
- Nutze den veralteten
ptr-Mechanismus nicht. - Halte Records so einfach wie möglich.
Häufige SPF-Fehler
Mehrere SPF-Records:
Wrong:v=spf1 include:spf.brevo.com -allv=spf1 include:_spf.google.com -all
Correct:v=spf1 include:spf.brevo.com include:_spf.google.com -allDNS-Lookup-Limit überschreiten:
Wenn du viele Includes hast, prüfe die Gesamtzahl deiner Lookups. Nutze SPF-Analyzer, um sicherzustellen, dass du unter 10 bleibst.
Nach Anbieterwechsel nicht aktualisieren:
Wenn du von einem E-Mail-Dienst zu einem anderen wechselst, entferne den alten Include und füge den neuen hinzu.
+all verwenden:
Nutze niemals +all, weil es allen erlaubt, als deine Domain zu senden.
DKIM verstehen (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) fügt deinen E-Mails eine kryptografische Signatur hinzu. Diese Signatur beweist, dass die Nachricht von deiner Domain stammt und während der Übertragung nicht verändert wurde.
Wie DKIM funktioniert
DKIM nutzt Public-Key-Kryptografie:
- Dein E-Mail-Anbieter erzeugt ein öffentliches/privates Schlüsselpaar.
- Du veröffentlichst den öffentlichen Schlüssel im DNS.
- Der Anbieter signiert ausgehende E-Mails mit dem privaten Schlüssel.
- Empfangende Server holen deinen öffentlichen Schlüssel aus DNS.
- Empfangende Server nutzen den öffentlichen Schlüssel, um die Signatur zu prüfen.
- Eine gültige Signatur beweist Authentizität und Integrität.
Was DKIM signiert:
DKIM-Signaturen decken typischerweise bestimmte Header und den Nachrichtentext ab:
- From-Header (erforderlich)
- Subject-Header
- Date-Header
- Nachrichtentext
- Weitere Header je nach Konfiguration
Das verhindert, dass Angreifer diese Elemente nach dem Versand verändern.
DKIM-Record-Struktur
DKIM-Records werden als TXT-Records mit einem bestimmten Namensformat veröffentlicht:
selector._domainkey.yourdomain.comDer Selector ist eine eindeutige Kennung, mit der du mehrere DKIM-Schlüssel haben kannst. Unterschiedliche E-Mail-Dienste nutzen unterschiedliche Selector (z. B. brevo, google, s1, s2).
DKIM-Record-Inhalt:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...| Tag | Beschreibung | Beispiel |
|---|---|---|
| v= | Version (immer DKIM1) | v=DKIM1 |
| k= | Schlüsseltyp (meist rsa) | k=rsa |
| p= | Öffentlicher Schlüssel (base64) | p=MIGfMA0… |
| t= | Flags (optional) | t=s (strict mode) |
| h= | Hash-Algorithmen (optional) | h=sha256 |
DKIM einrichten
Schritt 1: DKIM-Schlüssel erzeugen
Dein E-Mail-Service-Provider erzeugt Schlüssel normalerweise für dich. In Brevo:
- Gehe zu Settings > Senders, Domains & Dedicated IPs
- Wähle deine Domain aus
- Öffne den DKIM-Bereich
- Kopiere den bereitgestellten DNS-Record
Für selbst gehostete Mailserver erzeugst du Schlüssel mit OpenSSL:
openssl genrsa -out private.key 2048openssl rsa -in private.key -pubout -out public.keySchritt 2: DKIM-DNS-Record hinzufügen
In deiner DNS-Verwaltung:
- Type: TXT
- Host/Name: selector._domainkey (z. B. brevo._domainkey)
- Value: der DKIM-Record deines Anbieters
- TTL: 3600
Schritt 3: DKIM-Signierung aktivieren
Aktiviere DKIM-Signierung für deine Domain in den Einstellungen deines E-Mail-Anbieters. Dadurch signiert der Anbieter ausgehende Nachrichten.
Schritt 4: Setup prüfen
Sende eine Test-E-Mail und prüfe die Header auf DKIM-Signature. Nutze Tools wie:
- mail-tester.com
- DKIM Validator
- MXToolbox DKIM Lookup
DKIM-Best-Practices
2048-Bit-Schlüssel nutzen:
Ältere 1024-Bit-Schlüssel gelten als schwach. Moderne Sicherheitsstandards empfehlen mindestens 2048-Bit-RSA-Schlüssel.
Schlüssel regelmäßig rotieren:
Auch wenn es nicht strikt erforderlich ist, ist jährliche DKIM-Schlüsselrotation eine gute Sicherheitspraxis. Füge den neuen Schlüssel hinzu, bevor du den alten entfernst, damit keine Lücke entsteht.
Auf kompromittierte Schlüssel achten:
Wenn dein privater Schlüssel kompromittiert wird, können Angreifer Nachrichten als du signieren. Überwache ungewöhnliche Authentifizierungsmuster.
Unterschiedliche Selector für unterschiedliche Dienste nutzen:
Jeder E-Mail-Anbieter sollte einen eindeutigen Selector nutzen. Das ermöglicht unabhängiges Key Management und verhindert Konflikte mit anderen Diensten.
DNS-Propagation prüfen:
DKIM-Schlüssel können lang sein. Stelle sicher, dass dein DNS-Anbieter TXT-Records mit ausreichender Länge unterstützt. Einige Anbieter verlangen, dass der Schlüssel in mehrere Strings aufgeteilt wird.
DKIM-Header lesen
Wenn du eine E-Mail erhältst, zeigt der DKIM-Signature-Header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=brevo; h=from:to:subject:date:message-id; bh=base64hashofbody; b=base64signature;| Tag | Bedeutung |
|---|---|
| v= | Version (immer 1) |
| a= | Algorithmus (rsa-sha256 empfohlen) |
| c= | Canonicalization (relaxed erlaubt kleinere Änderungen) |
| d= | Signierende Domain |
| s= | Selector |
| h= | Signierte Header |
| bh= | Body Hash |
| b= | Signatur |
DMARC verstehen (Domain-based Message Authentication, Reporting, and Conformance)
DMARC baut auf SPF und DKIM auf, um Policy-Durchsetzung und Reporting bereitzustellen. Es sagt empfangenden Servern, was bei Authentifizierungsfehlern passieren soll, und sendet dir Reports zu Authentifizierungsergebnissen.
Wie DMARC funktioniert
DMARC ergänzt zwei wichtige Fähigkeiten:
- Policy-Durchsetzung: Definiere, wie Empfänger mit Authentifizierungsfehlern umgehen sollen.
- Reporting: Erhalte Daten darüber, wer E-Mail mit deiner Domain sendet.
DMARC-Prüfprozess:
- Ein empfangender Server bekommt eine E-Mail, die vorgibt, von deiner Domain zu stammen.
- Er prüft SPF (passt die sendende IP?).
- Er prüft DKIM (ist die Signatur gültig?).
- Er prüft DMARC-Alignment (passen die authentifizierten Domains zum From-Header?).
- Wenn Alignment fehlschlägt, wendet er deine DMARC-Policy an.
- Er sendet dir aggregierte und/oder forensische Reports.
DMARC-Alignment
DMARC verlangt Alignment zwischen der Domain im From-Header und den Domains, die SPF oder DKIM bestehen:
SPF-Alignment: Die Domain im Return-Path (Envelope Sender) muss zur From-Header-Domain passen oder eine Subdomain davon sein.
DKIM-Alignment:
Die Domain in der DKIM-Signatur (d=-Tag) muss zur From-Header-Domain passen oder eine Subdomain davon sein.
Alignment-Modi:
| Modus | Beschreibung |
|---|---|
| Strict (s) | Exakte Domain-Übereinstimmung erforderlich |
| Relaxed (r) | Subdomains erlaubt (Standard) |
Bei relaxed Alignment besteht die Prüfung, wenn dein From-Header [email protected] zeigt und DKIM mit brevo.example.com signiert, weil beide dieselbe organisatorische Domain example.com teilen.
DMARC-Record-Syntax
DMARC-Records werden als TXT-Records unter _dmarc.yourdomain.com veröffentlicht:
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100Erforderliche Tags:
| Tag | Beschreibung | Werte |
|---|---|---|
| v= | Version | DMARC1 (immer) |
| p= | Policy | none, quarantine, reject |
Optionale Tags:
| Tag | Beschreibung | Standard |
|---|---|---|
| rua= | Adresse für aggregierte Reports | none |
| ruf= | Adresse für forensische Reports | none |
| pct= | Prozentsatz, auf den Policy angewendet wird | 100 |
| sp= | Subdomain-Policy | gleich wie p= |
| adkim= | DKIM-Alignment-Modus | r (relaxed) |
| aspf= | SPF-Alignment-Modus | r (relaxed) |
| fo= | Optionen für forensische Reports | 0 |
| ri= | Report-Intervall (Sekunden) | 86400 |
DMARC-Policies erklärt
p=none (nur überwachen):
Bei Fehlern wird keine Aktion ausgeführt. E-Mails werden normal zugestellt. Nutze diese Policy, während du Reports analysierst und Authentifizierungsprobleme behebst.
v=DMARC1; p=none; rua=mailto:[email protected]p=quarantine (Spam-Ordner):
Fehlgeschlagene E-Mails werden in den Spam- oder Junk-Ordner verschoben. Das ist ein guter Zwischenschritt vor vollständiger Ablehnung.
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100p=reject (blockieren):
Fehlgeschlagene E-Mails werden vollständig abgelehnt. Das bietet maximalen Schutz, aber stelle zuerst sicher, dass alle legitimen Quellen bestehen.
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100DMARC einrichten
Schritt 1: Sicherstellen, dass SPF und DKIM funktionieren
DMARC hängt von SPF und DKIM ab. Prüfe, ob beide korrekt konfiguriert sind, bevor du DMARC hinzufügst.
Schritt 2: Mit Monitoring starten (p=none)
Beginne mit der permissivsten Policy, um Daten zu sammeln, ohne die Zustellung zu beeinflussen:
v=DMARC1; p=none; rua=mailto:[email protected]Schritt 3: DNS-Record hinzufügen
In deiner DNS-Verwaltung:
- Type: TXT
- Host/Name: _dmarc
- Value: dein DMARC-Record
- TTL: 3600
Schritt 4: Reports 2-4 Wochen analysieren
DMARC-Aggregate-Reports kommen täglich als XML-Dateien und zeigen:
- Welche IPs E-Mail mit deiner Domain gesendet haben
- SPF- und DKIM-Pass/Fail-Raten
- DMARC-Alignment-Ergebnisse
- Aktionen empfangender Server
Nutze DMARC-Report-Analyzer, um diese Daten zu visualisieren:
- DMARC Analyzer
- Postmark DMARC
- Valimail
- dmarcian
Schritt 5: Authentifizierungsprobleme beheben
Häufige Probleme, die Reports sichtbar machen:
- Legitimen Diensten fehlt der SPF-Eintrag.
- DKIM ist für einen sendenden Dienst nicht aktiviert.
- Drittanbieter senden ohne korrekte Authentifizierung.
- Weiterleitungen brechen SPF-Alignment.
Schritt 6: Schrittweise durchsetzen
Sobald legitime Quellen konsistent bestehen:
- Wechsle zu
p=quarantine; pct=10(10 % der Fehler in Quarantäne verschieben). - Erhöhe pct auf 25, 50, 75, 100.
- Wechsle zu
p=reject; pct=10. - Erhöhe bis zur vollständigen Ablehnung.
Schritt 7: Warten und überwachen
Prüfe Reports weiter. Neue sendende Quellen, Anbieteränderungen oder Konfigurationsdrift können Authentifizierungsfehler verursachen.
DMARC-Reports verstehen
Aggregierte Reports (rua):
Tägliche XML-Zusammenfassungen mit:
- Reportender Organisation
- Datumsbereich
- Veröffentlichter Policy
- Authentifizierungsergebnissen nach Quell-IP
- E-Mail-Volumen
Beispielauszug:
<record> <source_ip>203.0.113.10</source_ip> <count>1250</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated></record>Forensische Reports (ruf):
Einzelne Nachrichtendetails für Fehler. Diese Reports sind detaillierter, aber datenschutzsensibel. Viele Empfänger senden keine forensischen Reports.
DMARC-Best-Practices
Immer mit p=none starten:
Direkt zu reject zu springen kann legitime E-Mail blockieren. Überwache zuerst.
Dedizierte E-Mail-Adresse für Reports nutzen:
DMARC-Reports können sehr umfangreich werden. Nutze eine dedizierte Adresse oder einen Drittanbieter-Service.
Subdomain-Policy setzen (sp=):
Wenn du keine E-Mail von Subdomains sendest, setze sp=reject, um sie vor Spoofing zu schützen.
Prozentsatz (pct=) für graduellen Rollout nutzen:
Der pct-Tag erlaubt, Policy nur auf einen Prozentsatz der Fehler anzuwenden und den Rest weiter zu überwachen.
Dedizierte DMARC-Services erwägen:
Für größere Organisationen bieten Services wie Valimail, dmarcian oder Postmark DMARC bessere Report-Analyse als rohe XML-Dateien.
DNS-Record-Setup: vollständiger Walkthrough
E-Mail-Authentifizierung erfordert bestimmte DNS-Records. Dieser Abschnitt führt dich durch ein vollständiges Setup für große DNS-Anbieter.
Erforderliche Werte sammeln
Sammle vor dem Start diese Werte aus deinen E-Mail-Anbietern:
Für SPF:
- Alle Include-Statements (z. B. include:spf.brevo.com)
- Bestimmte IP-Adressen, die du autorisieren musst
Für DKIM:
- Den Selector-Namen (z. B. brevo, google, s1)
- Den vollständigen DKIM-Key-Wert
Für DMARC:
- Deine Reporting-E-Mail-Adresse
Records bei häufigen DNS-Anbietern hinzufügen
Cloudflare:
- Logge dich in das Cloudflare Dashboard ein.
- Wähle deine Domain aus.
- Gehe zu DNS > Records.
- Klicke Add Record.
- Für SPF: Type=TXT, Name=@, Content=dein SPF-Record.
- Für DKIM: Type=TXT, Name=selector._domainkey, Content=DKIM-Key.
- Für DMARC: Type=TXT, Name=_dmarc, Content=DMARC-Record.
- Klicke Save.
Google Domains/Squarespace:
- Öffne die DNS-Einstellungen deiner Domain.
- Scrolle zu Custom Records.
- Klicke Manage Custom Records.
- Füge jeden Record mit passendem Type, Host und Data hinzu.
- Für SPF: Host=@, Type=TXT, Data=SPF-Record.
- Für DKIM: Host=selector._domainkey, Type=TXT, Data=DKIM-Key.
- Für DMARC: Host=_dmarc, Type=TXT, Data=DMARC-Record.
GoDaddy:
- Gehe zu My Products > Domains.
- Klicke DNS neben deiner Domain.
- Scrolle zum Records-Bereich.
- Klicke Add für jeden neuen Record.
- Wähle TXT als Type.
- Gib den Name ein (@ für SPF, selector._domainkey für DKIM, _dmarc für DMARC).
- Gib den Value ein.
- Speichere.
Namecheap:
- Gehe zu Domain List > Manage.
- Klicke Advanced DNS.
- Füge jeweils Add New Record hinzu.
- Wähle TXT Record.
- Host: @ für SPF, selector._domainkey für DKIM, _dmarc für DMARC.
- Value: dein Record-Inhalt.
- Speichere alle Änderungen.
DNS-Propagation
Nach dem Hinzufügen von Records brauchen Änderungen Zeit, bis sie global propagiert sind. Typisch sind:
- 5-30 Minuten für erste Sichtbarkeit
- Bis zu 48 Stunden für vollständige globale Propagation
Nutze dig oder nslookup zur Prüfung:
dig TXT yourdomain.comdig TXT selector._domainkey.yourdomain.comdig TXT _dmarc.yourdomain.comOder nutze Online-Tools wie whatsmydns.net, um Propagation weltweit zu prüfen.
Beispiel für ein vollständiges Setup
Für eine Domain, die Brevo und Google Workspace nutzt:
SPF-Record (TXT bei @):
v=spf1 include:spf.brevo.com include:_spf.google.com -allDKIM-Record für Brevo (TXT bei brevo._domainkey):
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [key from Brevo dashboard]DKIM-Record für Google (TXT bei google._domainkey):
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [key from Google Admin]DMARC-Record (TXT bei _dmarc):
v=DMARC1; p=none; rua=mailto:[email protected]Häufige Probleme beheben
Auch bei sorgfältiger Einrichtung kann E-Mail-Authentifizierung fehlschlagen. Hier sind häufige Probleme und wie du sie löst.
SPF-Troubleshooting
SPF-Record nicht gefunden:
Symptome: SPF-Prüfungen zeigen “none” oder “no record”.
Ursachen:
- Record wurde nicht zu DNS hinzugefügt.
- Record wurde an der falschen Stelle hinzugefügt (Subdomain statt Root).
- DNS-Propagation ist noch nicht abgeschlossen.
Lösungen:
- Prüfe mit
dig TXT yourdomain.com, ob der Record existiert. - Prüfe das Name/Host-Feld (sollte @ oder leer für Root-Domain sein).
- Warte auf DNS-Propagation (bis zu 48 Stunden).
SPF PermError (zu viele Lookups):
Symptome: SPF-Ergebnisse zeigen “permerror”.
Ursachen:
- Mehr als 10 DNS-Lookups in deinem SPF-Record.
- Includes enthalten zu viele verschachtelte Includes.
Lösungen:
- Auditiere deine Includes und entferne ungenutzte.
- Ersetze Includes durch ip4:-Einträge, wo möglich.
- Nutze SPF-Flattening-Services.
- Konsolidiere Dienste auf weniger Anbieter.
SPF SoftFail oder Fail für legitime E-Mail:
Symptome: Legitime E-Mails bestehen SPF nicht.
Ursachen:
- Sendender Dienst fehlt im SPF.
- Versand erfolgt von einer nicht autorisierten IP.
- Ein Relay ändert den Envelope Sender.
Lösungen:
- Füge den fehlenden Include für deinen sendenden Dienst hinzu.
- Prüfe, welche IP die E-Mail tatsächlich gesendet hat (aus den Headern).
- Kontaktiere deinen E-Mail-Anbieter für korrekte SPF-Einstellungen.
Mehrere SPF-Records:
Symptome: SPF zeigt permerror oder zufällige Fehler.
Ursachen:
- Zwei oder mehr TXT-Records enthalten v=spf1.
Lösungen:
- Kombiniere alle Mechanismen in einen einzigen SPF-Record.
- Lösche doppelte SPF-Records.
DKIM-Troubleshooting
DKIM-Signatur fehlt:
Symptome: Kein DKIM-Signature-Header in E-Mails.
Ursachen:
- DKIM-Signierung ist beim E-Mail-Anbieter nicht aktiviert.
- Domain-Verifizierung wurde nicht abgeschlossen.
- Versand läuft über einen Pfad ohne DKIM.
Lösungen:
- Aktiviere DKIM in den Einstellungen deines Anbieters.
- Schließe die Domain-Verifizierung ab.
- Prüfe die Anbieter-Dokumentation zum DKIM-Setup.
DKIM-Prüfung fehlgeschlagen:
Symptome: DKIM zeigt “fail” in Authentication-Results.
Ursachen:
- DNS-Record ist nicht veröffentlicht oder falsch.
- Falscher Selector wird genutzt.
- Key in DNS und Signing-Key passen nicht zusammen.
- Nachricht wurde während der Übertragung verändert.
Lösungen:
- Prüfe, ob der DNS-Record unter selector._domainkey.domain existiert.
- Vergleiche den Selector im DKIM-Signature-Header mit DNS.
- Erzeuge Schlüssel neu, wenn ein Mismatch vermutet wird.
- Prüfe Mailfilter oder Relays, die Nachrichten verändern.
DKIM-Key zu lang für DNS:
Symptome: DKIM-Record lässt sich nicht speichern, Truncation-Fehler.
Ursachen:
- 2048-Bit-Schlüssel überschreiten die Länge eines einzelnen TXT-Records.
- DNS-Anbieter hat Zeichenlimits.
Lösungen:
- Teile den Schlüssel in mehrere zitierte Strings auf (die meisten Anbieter behandeln das automatisch).
- Prüfe, ob dein DNS-Anbieter lange TXT-Records unterstützt.
- Nutze 1024-Bit-Schlüssel nur vorübergehend (weniger sicher).
Beispiel für einen aufgeteilten DKIM-Record:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...""...continuation of key..."DMARC-Troubleshooting
DMARC-Alignment-Fehler:
Symptome: SPF und DKIM bestehen, aber DMARC schlägt fehl.
Ursachen:
- Die authentifizierte Domain passt nicht zur From-Header-Domain.
- Drittanbieter-Sendedienst nutzt eine eigene Domain.
- Envelope Sender ist falsch konfiguriert.
Lösungen:
- Stelle sicher, dass dein E-Mail-Anbieter mit deiner Domain signiert (Custom DKIM).
- Konfiguriere einen eigenen Return-Path/Envelope Sender.
- Nutze relaxed Alignment Mode (
adkim=r; aspf=r).
Keine DMARC-Reports erhalten:
Symptome: Keine aggregierten Reports kommen an.
Ursachen:
- rua-Adresse ist falsch.
- E-Mail-Adresse kann keine externe E-Mail empfangen.
- Reports landen im Spam.
- Empfangende Server senden keine Reports.
Lösungen:
- Prüfe die rua-Syntax:
rua=mailto:[email protected]. - Teste, ob die Reporting-Adresse externe E-Mail empfangen kann.
- Prüfe den Spam-Ordner auf Reports.
- Hinweis: Nicht alle Empfänger senden DMARC-Reports.
DMARC-Record nicht gefunden:
Symptome: DMARC-Prüfungen zeigen “no record”.
Ursachen:
- Record wurde an der falschen Stelle veröffentlicht.
- Falsches Format (muss TXT bei _dmarc-Subdomain sein).
Lösungen:
- Der Record muss unter _dmarc.yourdomain.com liegen.
- Prüfe mit
dig TXT _dmarc.yourdomain.com.
Allgemeine Troubleshooting-Tools
Online-Validatoren:
- MXToolbox (mxtoolbox.com) - SPF-, DKIM-, DMARC-Lookups
- Mail Tester (mail-tester.com) - Test-E-Mail für vollständige Analyse senden
- DMARC Analyzer - Report-Visualisierung
- Google Admin Toolbox - MX, SPF, DKIM prüfen
Command-Line-Tools:
# Check SPFdig TXT yourdomain.com
# Check DKIMdig TXT selector._domainkey.yourdomain.com
# Check DMARCdig TXT _dmarc.yourdomain.com
# Check from specific DNS serverdig @8.8.8.8 TXT yourdomain.comE-Mail-Header-Analyse:
Prüfe den Authentication-Results-Header in empfangenen E-Mails:
Authentication-Results: mx.google.com; dkim=pass header.d=example.com header.s=brevo; spf=pass smtp.mailfrom=example.com; dmarc=pass action=none header.from=example.comE-Mail-Authentifizierung und Brevo
Brevo bietet umfassende Unterstützung für E-Mail-Authentifizierung und macht die Konfiguration von SPF, DKIM und DMARC für sendende Domains übersichtlich.
Authentifizierung in Brevo einrichten
Schritt 1: Domain hinzufügen
- Logge dich in dein Brevo-Konto ein.
- Navigiere zu Settings > Senders, Domains & Dedicated IPs.
- Klicke Add a Domain.
- Gib deinen Domainnamen ein.
Schritt 2: SPF konfigurieren
Brevo stellt den SPF-Include bereit, den du zu DNS hinzufügst:
include:spf.brevo.comFüge ihn zu deinem bestehenden SPF-Record hinzu oder erstelle einen neuen:
v=spf1 include:spf.brevo.com -allSchritt 3: DKIM konfigurieren
Brevo erzeugt DKIM-Schlüssel automatisch. Kopiere den bereitgestellten Record:
- Gehe in Brevo zu deinen Domain-Einstellungen.
- Suche den DKIM-Bereich.
- Kopiere DNS-Record-Name und -Wert.
- Füge den TXT-Record zu DNS hinzu.
Schritt 4: Konfiguration prüfen
Brevo prüft deine DNS-Records automatisch. Grüne Haken zeigen eine erfolgreiche Konfiguration.
Vorteile korrekter Brevo-Authentifizierung
Wenn du Authentifizierung mit Brevo korrekt konfigurierst:
- Höhere Inbox-Platzierung: Gmail, Microsoft und andere Anbieter vertrauen authentifizierten Nachrichten.
- Markenschutz: DMARC verhindert Spoofing deiner Domain.
- Bessere Analytics: Öffnungen und Klicks werden genauer gemessen.
- Reputationsaufbau: Konsistente Authentifizierung baut Sender-Reputation auf.
Vorteile der Tajo-Integration
Wenn du Tajo nutzt, um deinen Shopify-Store mit Brevo zu verbinden, bekommst du zusätzliche Vorteile:
- Automatische Kundensynchronisierung: Kundendaten fließen nahtlos für personalisierte E-Mails.
- Event Tracking: Kauf-, Browse- und Warenkorb-Events lösen authentifizierte transaktionale E-Mails aus.
- Multi-Channel-Koordination: Authentifizierung bleibt über E-Mail, SMS und WhatsApp konsistent.
- Vereinheitlichte Analytics: E-Mail-Performance wird zusammen mit anderen Marketingmetriken verfolgt.
Die Kombination aus korrekter E-Mail-Authentifizierung und Echtzeit-Synchronisierung von Kundendaten sorgt dafür, dass deine E-Mails nicht nur den Posteingang erreichen, sondern auch für jede Empfänger:in relevant sind.
Häufig gestellte Fragen
Was ist der Unterschied zwischen SPF, DKIM und DMARC?
SPF legt fest, welche Server E-Mail für deine Domain senden dürfen. DKIM fügt eine kryptografische Signatur hinzu, die Nachrichtenechtheit beweist. DMARC setzt eine Policy dafür, wie Empfänger Authentifizierungsfehler behandeln sollen, und liefert Reporting. Alle drei arbeiten für vollständige E-Mail-Authentifizierung zusammen.
Brauche ich alle drei (SPF, DKIM und DMARC)?
Für optimale Zustellbarkeit und Sicherheit: ja. SPF allein ist anfällig für Spoofing. DKIM allein definiert keine Policy. DMARC braucht SPF oder DKIM, um zu funktionieren. Zusammen bieten sie umfassenden Schutz und die besten Inbox-Platzierungsraten.
Wie lange dauert es, bis E-Mail-Authentifizierung funktioniert?
DNS-Änderungen propagieren normalerweise innerhalb von 30 Minuten bis 48 Stunden. Sobald sie propagiert sind, greift Authentifizierung sofort. Sender-Reputation durch konsistente Authentifizierung aufzubauen, dauert jedoch Wochen bis Monate.
Blockiert DMARC mit p=reject meine legitimen E-Mails?
Das kann passieren, wenn es falsch konfiguriert ist. Deshalb solltest du immer mit p=none (Monitoring) starten, Reports 2-4 Wochen analysieren, Probleme beheben und dann schrittweise zu quarantine und reject wechseln. Überspringe die Monitoring-Phase nie.
Was ist SPF-Alignment vs. DKIM-Alignment?
Alignment bedeutet, dass die authentifizierte Domain zur sichtbaren From-Header-Domain passt. SPF-Alignment vergleicht die Return-Path-Domain. DKIM-Alignment vergleicht die signierende Domain (d=-Tag). DMARC verlangt, dass mindestens eines davon aligned.
Kann ich mehrere DKIM-Schlüssel für eine Domain haben?
Ja. Jeder E-Mail-Dienst kann einen anderen Selector nutzen (z. B. brevo._domainkey, google._domainkey). Dadurch können mehrere Dienste unabhängig mit DKIM signieren. Es gibt kein Limit für die Anzahl von DKIM-Selectors.
Warum landen meine E-Mails nach der Einrichtung von Authentifizierung immer noch im Spam?
Authentifizierung ist notwendig, aber nicht ausreichend für Inbox-Platzierung. Weitere Faktoren sind Sender-Reputation, Inhaltsqualität, Engagement-Raten und Listenhygiene. Authentifizierung bringt dich durch den ersten Filter. Gute Praxis entscheidet über die finale Platzierung.
Wie lese ich DMARC-Aggregate-Reports?
DMARC-Aggregate-Reports sind XML-Dateien. Nutze Tools wie dmarcian, Postmark DMARC oder DMARC Analyzer, um sie zu parsen und zu visualisieren. Diese Tools zeigen, welche IPs E-Mail als deine Domain senden und welche Pass/Fail-Raten sie haben.
Was passiert, wenn ich das SPF-Limit von 10 Lookups überschreite?
SPF liefert einen permanenten Fehler (permerror), und alle SPF-Prüfungen schlagen fehl. Behebe das, indem du ungenutzte Includes entfernst, Includes wo möglich durch IP-Adressen ersetzt oder SPF-Flattening-Services nutzt.
Sollte ich -all oder ~all in meinem SPF-Record nutzen?
Nutze ~all (softfail), während du testest und Vertrauen aufbaust. Wenn du bestätigt hast, dass alle legitimen Quellen bestehen, wechsle zu -all (hard fail) für stärkeren Schutz. Softfail markiert Fehler, lehnt aber nicht ab. Hard fail autorisiert Ablehnung.
Wie oft sollte ich DKIM-Schlüssel rotieren?
Es gibt keine strikte Pflicht, aber jährliche Rotation ist eine gute Sicherheitspraxis. Beim Rotieren fügst du zuerst den neuen Schlüssel hinzu, wartest auf DNS-Propagation, aktivierst Signing mit dem neuen Schlüssel und entfernst den alten Schlüssel nach einer Übergangszeit.
Brauchen Subdomains separate Authentifizierung?
SPF: Ja, jede Subdomain braucht einen eigenen SPF-Record, wenn sie E-Mail sendet.
DKIM: Schlüssel können pro Subdomain geteilt oder getrennt sein.
DMARC: Subdomains erben die Parent-Policy, außer sp= ist gesetzt oder die Subdomain hat einen eigenen DMARC-Record.
Fazit
E-Mail-Authentifizierung mit SPF, DKIM und DMARC ist für Unternehmen, die auf E-Mail-Kommunikation angewiesen sind, nicht mehr optional. Diese Protokolle schützen deine Marke vor Spoofing, verbessern Zustellbarkeit und bauen das Vertrauen auf, das wirksames E-Mail-Marketing braucht.
Wichtigste Punkte:
- SPF autorisiert sendende Server über DNS.
- DKIM beweist Nachrichtenechtheit mit kryptografischen Signaturen.
- DMARC setzt Policy durch und gibt Sichtbarkeit über Reports.
- Starte mit Monitoring (p=none), bevor du Ablehnung durchsetzt.
- Alle legitimen sendenden Quellen müssen korrekt konfiguriert sein.
- Regelmäßiges Monitoring verhindert Konfigurationsdrift.
Für E-Commerce-Unternehmen mit Shopify schafft die Kombination aus korrekter E-Mail-Authentifizierung und Kundendatenintegration über Tajo und Brevo ein starkes Fundament. Transaktionale E-Mails erreichen Kund:innen zuverlässig, Marketingkampagnen landen besser im Posteingang und deine Marke bleibt vor Spoofing-Angriffen geschützt.
Bereit, deine E-Mail-Zustellbarkeit zu verbessern? Starte mit einem Audit deiner aktuellen Authentifizierung anhand der Tools in diesem Leitfaden. Konfiguriere danach SPF, DKIM und DMARC systematisch nach den Schritt-für-Schritt-Anleitungen.
Lerne, wie Tajo mit Brevo integriert, um nahtlose E-Mail-Authentifizierung zusammen mit Echtzeit-Kundendatensynchronisierung für deinen Shopify-Store bereitzustellen.
Verwandte Artikel
- E-Mail-Marketing-Kampagnen: Der komplette Leitfaden zu Planung, Umsetzung und Optimierung
- E-Mail-Marketing-Strategie: Kompletter Guide für Planung und Umsetzung [2025]
- E-Mail-Marketing für kleine Unternehmen: Der komplette Guide (2026)
- E-Mail-Marketing-ROI: Returns berechnen, tracken und verbessern [2025]
- E-Mail-Marketing für Einsteiger:innen: Der komplette Einstiegsleitfaden (2026)