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.

SPF DKIM DMARC
SPF, DKIM und DMARC?

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:

ProtokollWas es machtAnalogie
SPFListet autorisierte sendende Server aufFirmenbriefkopf mit genehmigten Büros
DKIMSigniert Nachrichten kryptografischWachssiegel als Echtheitsnachweis
DMARCSetzt Policy für Fehler und ReportingAnweisung, 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:

  1. Du sendest eine E-Mail aus deiner Marketingplattform.
  2. Der empfangende Server liest deine Domain aus dem Return-Path (Envelope Sender).
  3. Der Server fragt DNS nach dem SPF-Record deiner Domain.
  4. Er vergleicht die sendende IP mit der autorisierten Liste im SPF-Record.
  5. 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]all

Version-Tag: Beginnt immer mit v=spf1

Mechanismen: Definieren, wer senden darf

MechanismusBeschreibungBeispiel
include:SPF einer anderen Domain vertraueninclude:spf.brevo.com
ip4:Bestimmte IPv4 autorisierenip4:192.168.1.1
ip6:Bestimmte IPv6 autorisierenip6:2001:db8::1
aIPs des A-Records der Domain erlaubena
mxIPs der Mailserver der Domain erlaubenmx
ptrReverse DNS (veraltet)ptr:example.com
exists:Bedingte Prüfungexists:%{i}.spf.example.com

Qualifier: Definieren, wie Treffer behandelt werden

QualifierBedeutungErgebnis
+Pass (Standard)Autorisiert
-Fail (hart)Nicht autorisiert, ablehnen
~SoftFailNicht autorisiert, annehmen, aber markieren
?NeutralKeine 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 -all

Das 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 -all

Das autorisiert Brevo, Google Workspace und Microsoft 365.

Eigenen Mailserver einschließen:

v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all

Das 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:

AnbieterSPF-Include
Brevoinclude:spf.brevo.com
Google Workspaceinclude:_spf.google.com
Microsoft 365include:spf.protection.outlook.com
Amazon SESinclude:amazonses.com
SendGridinclude:sendgrid.net
Mailguninclude:mailgun.org

Schritt 3: SPF-Record erstellen

Kombiniere alle Includes in einem Record:

v=spf1 include:spf.brevo.com include:_spf.google.com -all

Schritt 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:

Terminal window
dig TXT yourdomain.com

Oder 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 -all
v=spf1 include:_spf.google.com -all
Correct:
v=spf1 include:spf.brevo.com include:_spf.google.com -all

DNS-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:

  1. Dein E-Mail-Anbieter erzeugt ein öffentliches/privates Schlüsselpaar.
  2. Du veröffentlichst den öffentlichen Schlüssel im DNS.
  3. Der Anbieter signiert ausgehende E-Mails mit dem privaten Schlüssel.
  4. Empfangende Server holen deinen öffentlichen Schlüssel aus DNS.
  5. Empfangende Server nutzen den öffentlichen Schlüssel, um die Signatur zu prüfen.
  6. 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.com

Der 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...
TagBeschreibungBeispiel
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:

  1. Gehe zu Settings > Senders, Domains & Dedicated IPs
  2. Wähle deine Domain aus
  3. Öffne den DKIM-Bereich
  4. Kopiere den bereitgestellten DNS-Record

Für selbst gehostete Mailserver erzeugst du Schlüssel mit OpenSSL:

Terminal window
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

Schritt 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;
TagBedeutung
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:

  1. Policy-Durchsetzung: Definiere, wie Empfänger mit Authentifizierungsfehlern umgehen sollen.
  2. Reporting: Erhalte Daten darüber, wer E-Mail mit deiner Domain sendet.

DMARC-Prüfprozess:

  1. Ein empfangender Server bekommt eine E-Mail, die vorgibt, von deiner Domain zu stammen.
  2. Er prüft SPF (passt die sendende IP?).
  3. Er prüft DKIM (ist die Signatur gültig?).
  4. Er prüft DMARC-Alignment (passen die authentifizierten Domains zum From-Header?).
  5. Wenn Alignment fehlschlägt, wendet er deine DMARC-Policy an.
  6. 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:

ModusBeschreibung
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=100

Erforderliche Tags:

TagBeschreibungWerte
v=VersionDMARC1 (immer)
p=Policynone, quarantine, reject

Optionale Tags:

TagBeschreibungStandard
rua=Adresse für aggregierte Reportsnone
ruf=Adresse für forensische Reportsnone
pct=Prozentsatz, auf den Policy angewendet wird100
sp=Subdomain-Policygleich wie p=
adkim=DKIM-Alignment-Modusr (relaxed)
aspf=SPF-Alignment-Modusr (relaxed)
fo=Optionen für forensische Reports0
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=100

p=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=100

DMARC 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:

  1. Wechsle zu p=quarantine; pct=10 (10 % der Fehler in Quarantäne verschieben).
  2. Erhöhe pct auf 25, 50, 75, 100.
  3. Wechsle zu p=reject; pct=10.
  4. 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:

  1. Logge dich in das Cloudflare Dashboard ein.
  2. Wähle deine Domain aus.
  3. Gehe zu DNS > Records.
  4. Klicke Add Record.
  5. Für SPF: Type=TXT, Name=@, Content=dein SPF-Record.
  6. Für DKIM: Type=TXT, Name=selector._domainkey, Content=DKIM-Key.
  7. Für DMARC: Type=TXT, Name=_dmarc, Content=DMARC-Record.
  8. Klicke Save.

Google Domains/Squarespace:

  1. Öffne die DNS-Einstellungen deiner Domain.
  2. Scrolle zu Custom Records.
  3. Klicke Manage Custom Records.
  4. Füge jeden Record mit passendem Type, Host und Data hinzu.
  5. Für SPF: Host=@, Type=TXT, Data=SPF-Record.
  6. Für DKIM: Host=selector._domainkey, Type=TXT, Data=DKIM-Key.
  7. Für DMARC: Host=_dmarc, Type=TXT, Data=DMARC-Record.

GoDaddy:

  1. Gehe zu My Products > Domains.
  2. Klicke DNS neben deiner Domain.
  3. Scrolle zum Records-Bereich.
  4. Klicke Add für jeden neuen Record.
  5. Wähle TXT als Type.
  6. Gib den Name ein (@ für SPF, selector._domainkey für DKIM, _dmarc für DMARC).
  7. Gib den Value ein.
  8. Speichere.

Namecheap:

  1. Gehe zu Domain List > Manage.
  2. Klicke Advanced DNS.
  3. Füge jeweils Add New Record hinzu.
  4. Wähle TXT Record.
  5. Host: @ für SPF, selector._domainkey für DKIM, _dmarc für DMARC.
  6. Value: dein Record-Inhalt.
  7. 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:

Terminal window
dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

Oder 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 -all

DKIM-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:

Terminal window
# Check SPF
dig TXT yourdomain.com
# Check DKIM
dig TXT selector._domainkey.yourdomain.com
# Check DMARC
dig TXT _dmarc.yourdomain.com
# Check from specific DNS server
dig @8.8.8.8 TXT yourdomain.com

E-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.com

E-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

  1. Logge dich in dein Brevo-Konto ein.
  2. Navigiere zu Settings > Senders, Domains & Dedicated IPs.
  3. Klicke Add a Domain.
  4. Gib deinen Domainnamen ein.

Schritt 2: SPF konfigurieren

Brevo stellt den SPF-Include bereit, den du zu DNS hinzufügst:

include:spf.brevo.com

Füge ihn zu deinem bestehenden SPF-Record hinzu oder erstelle einen neuen:

v=spf1 include:spf.brevo.com -all

Schritt 3: DKIM konfigurieren

Brevo erzeugt DKIM-Schlüssel automatisch. Kopiere den bereitgestellten Record:

  1. Gehe in Brevo zu deinen Domain-Einstellungen.
  2. Suche den DKIM-Bereich.
  3. Kopiere DNS-Record-Name und -Wert.
  4. 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

Frequently Asked Questions

Was sind SPF, DKIM und DMARC?
SPF prüft sendende Server, DKIM fügt E-Mails eine digitale Signatur hinzu und DMARC sagt empfangenden Servern, wie sie nicht authentifizierte Nachrichten behandeln sollen. Zusammen authentifizieren sie deine E-Mails und schützen vor Spoofing.
Brauche ich alle drei: SPF, DKIM und DMARC?
Ja. Google und Yahoo verlangen inzwischen SPF und DKIM für alle Sender und DMARC für Sender mit mehr als 5.000 E-Mails pro Tag. Alle drei zusammen liefern die beste Zustellbarkeit und Sicherheit.
Wie richte ich SPF, DKIM und DMARC ein?
Füge DNS-Records zu deiner Domain hinzu: SPF als TXT-Record mit autorisierten Sendern, DKIM als TXT-Record mit deinem öffentlichen Schlüssel und DMARC als TXT-Record mit deiner Policy. Deine E-Mail-Plattform liefert die konkreten Werte.

Subscribe to updates

strategy

Drop your email or phone number — we'll send you what matters next.

auto-detect
Brevo erhalten