SPF, DKIM, DMARC: der vollständige Leitfaden zur E-Mail-Konfiguration (2026)

SPF, DKIM und DMARC: Wenn Sie E-Mails versenden, insbesondere Prospecting-E-Mails, sind Sie diesen drei Akronymen zwangsläufig begegnet. Und wahrscheinlich haben Sie angesichts der technischen Dokumentation schon einmal verzweifelt aufgeseufzt. Im Jahr 2026 sind diese drei E-Mail-Authentifizierungsprotokolle nicht mehr optional: Seit Februar 2024 lehnen Google und Yahoo nicht authentifizierte E-Mails von Massenversendern ab, und Microsoft hat im Mai 2025 nachgezogen. Für Teams, die B2B-Cold-Email betreiben, ist dies die Mindestvoraussetzung geworden, um den Posteingang zu erreichen. In diesem vollständigen Leitfaden erklären wir Ihnen genau, was SPF, DKIM und DMARC sind, wie sie zusammenwirken und vor allem, wie Sie sie korrekt auf Ihrer Domain konfigurieren. Mit konkreten Beispielen für DNS-Einträge, häufigen Fehlern, die Sie vermeiden sollten, und einer FAQ, die alle Ihre Fragen beantwortet.

SPF, DKIM und DMARC sind drei sich ergänzende E-Mail-Authentifizierungsprotokolle. Jedes spielt eine andere und präzise Rolle bei der Überprüfung, dass eine von Ihrer Domain gesendete E-Mail tatsächlich legitim ist.

• SPF (Sender Policy Framework): Gibt an, welche Server berechtigt sind, E-Mails von Ihrer Domain zu versenden.

• DKIM (DomainKeys Identified Mail): Fügt jeder E-Mail eine kryptografische Signatur hinzu, um zu beweisen, dass sie nicht verändert wurde.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): Teilt den Empfängerservern mit, was zu tun ist, wenn SPF oder DKIM fehlschlagen, und versendet Monitoring-Berichte.

Alle drei korrekt zu konfigurieren ist die Mindestvoraussetzung, um im Jahr 2026 den Posteingang zu erreichen. Wenn auch nur eines der drei fehlt, riskieren Ihre E-Mails, im Spam zu landen oder schlimmer noch, von Gmail, Outlook oder Yahoo schlichtweg abgelehnt zu werden.

SPF ist das älteste der drei Protokolle (offiziell erschienen 2006 mit RFC 4408, aktualisiert 2014 mit RFC 7208). Das Prinzip ist einfach: Sie veröffentlichen in Ihrem DNS die Liste der Server, die berechtigt sind, E-Mails im Namen Ihrer Domain zu versenden. Wenn ein Server eine E-Mail empfängt, die vorgibt, von Ihrer Domain zu stammen, überprüft er, ob die IP-Adresse des Absenders in dieser Liste enthalten ist.

SPF wird über einen TXT-Eintrag in Ihrer DNS-Zone an der Wurzel Ihrer Domain implementiert. Hier ein typisches Beispiel:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Dieser Eintrag besagt: «E-Mails von dieser Domain dürfen von den Servern von Google Workspace oder Microsoft 365 versendet werden. Jeder andere Server gilt als verdächtig (~all = soft fail).»

Wenn Ihr Unternehmen mehrere Versanddienste nutzt (Google Workspace für interne E-Mails, ein Cold-Email-Tool wie Emelia und ein transaktionales Tool wie SendGrid), muss Ihr SPF sie alle einschliessen:

v=spf1 include:_spf.google.com include:_spf.emelia.io include:sendgrid.net ~all

SPF unterliegt einer technischen Einschränkung, die oft vergessen wird: Ein SPF-Eintrag darf nicht mehr als 10 DNS-Lookups erzeugen. Jeder include:-Mechanismus löst einen zusätzlichen Lookup aus, und einige Dienste (wie Microsoft 365) verbrauchen für sich allein mehrere. Über 10 hinaus gibt das gesamte SPF einen PermError-Fehler zurück und die Überprüfung schlägt fehl. Wenn Sie viele Dienste autorisieren müssen, müssen Sie Ihr SPF mit einem speziellen Tool «abflachen» (SPF Flattening).

Der abschliessende Mechanismus Ihres SPF bestimmt, wie die Server eine E-Mail behandeln, die die Überprüfung nicht besteht.

• ~all (soft fail): Die E-Mail besteht SPF nicht, kann aber trotzdem zugestellt werden, in der Regel als verdächtig markiert. Empfohlen während der Einrichtungsphase und meistens auch im Jahr 2026.

• -all (hard fail): Die E-Mail wird von strikten Servern abgelehnt. Nur zu verwenden, nachdem Sie validiert haben, dass alle Ihre legitimen Versanddienste tatsächlich im SPF enthalten sind.

Im Jahr 2026 ist die empfohlene Praxis, mit ~all zu beginnen und dann, nach Validierung über die DMARC-Berichte, dass alles sauber ist, auf -all umzustellen, falls Sie es strikt halten möchten.

DKIM (RFC 6376) fügt jeder ausgehenden E-Mail eine kryptografische Signatur hinzu. Diese Signatur, die mit einem privaten Schlüssel berechnet wird, wird vom Empfängerserver mithilfe eines in Ihrem DNS veröffentlichten öffentlichen Schlüssels überprüft. DKIM beweist zwei Dinge: dass die Nachricht tatsächlich von Ihrer Domain stammt und dass sie während der Übertragung nicht verändert wurde.

Wenn Ihr Versandserver eine E-Mail sendet, berechnet er einen kryptografischen Fingerabdruck des Inhalts (Header + Body) und verschlüsselt diesen mit einem privaten Schlüssel. Diese Signatur wird im DKIM-Signature-Header der E-Mail eingefügt. Der Empfängerserver ruft den entsprechenden öffentlichen Schlüssel aus Ihrem DNS ab, entschlüsselt die Signatur und überprüft, ob sie tatsächlich der empfangenen E-Mail entspricht. Wenn auch nur ein Komma unterwegs verändert wurde, schlägt die Überprüfung fehl.

Ein DKIM-Eintrag ist ein TXT, der unter einem bestimmten Selektor in Ihrem DNS veröffentlicht wird. Der Selektor (selector) ermöglicht es, mehrere DKIM-Schlüssel parallel zu haben, was für die Rotation nützlich ist. Typisches Format:

selector1._domainkey.ihredomain.com  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Konkret generiert Ihr E-Mail-Anbieter (Google Workspace, Microsoft 365 oder ein Tool wie Emelia) das Schlüsselpaar und gibt Ihnen den genauen Inhalt, den Sie in Ihre DNS-Zone einfügen müssen.

Hier ist, warum DKIM so wichtig ist: Im Gegensatz zu SPF übersteht DKIM die E-Mail-Weiterleitung. Wenn ein Empfänger Ihre Nachricht an jemand anderen weiterleitet, ändert sich die IP-Adresse des Absenders (es ist nicht mehr Ihr Server, sondern der Server der weiterleitenden Person). Daher schlägt SPF mechanisch fehl. Aber die DKIM-Signatur bleibt intakt, solange der Inhalt nicht verändert wird. Genau deshalb ist DKIM im Jahr 2026 zum Eckpfeiler der E-Mail-Authentifizierung geworden.

DKIM-Schlüssel gibt es historisch in 1024 Bit oder 2048 Bit. Im Jahr 2026 lautet die klare Empfehlung der Branche, 2048 Bit zu verwenden. 1024-Bit-Schlüssel werden zwar noch akzeptiert, aber zunehmend von Anti-Spam-Filtern abgestraft. Idealerweise rotieren Sie Ihre DKIM-Schlüssel alle 6 bis 12 Monate, um das Risikofenster im Falle eines Lecks des privaten Schlüssels zu begrenzen.

DMARC (RFC 7489) ersetzt weder SPF noch DKIM. Es kommt obendrauf, um zwei Fragen zu beantworten: «Was soll der Empfängerserver tun, wenn SPF oder DKIM fehlschlagen?» und «Woher weiss ich, wer versucht, E-Mails im Namen meiner Domain zu versenden?».

DMARC stützt sich auf ein Konzept namens Alignment. Damit eine E-Mail DMARC besteht, muss SPF oder DKIM erfolgreich sein UND die durch eines der beiden überprüfte Domain muss der im «From»-Feld der E-Mail sichtbaren Domain entsprechen (also jener, die der Empfänger sieht). Ohne dieses Alignment könnte ein Angreifer SPF mit seiner eigenen Domain bestehen und sich gleichzeitig im From als Sie ausgeben genau die Spoofing-Technik, die DMARC verhindert.

DMARC wird als TXT unter _dmarc.ihredomain.com veröffentlicht:

_dmarc.ihredomain.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ihredomain.com; pct=100; aspf=r; adkim=r"

Das Tag p= definiert, was die Server im Falle eines Fehlschlags tun sollen:

• p=none: nur Monitoring, die E-Mail wird normal zugestellt. Dies ist der empfohlene Startmodus, um Berichte zu sammeln, ohne etwas zu zerstören.

• p=quarantine: Nicht authentifizierte E-Mails landen im Spam. Zwischenschritt nach einigen Wochen sauberen Monitorings.

• p=reject: Nicht authentifizierte E-Mails werden schlichtweg abgelehnt. Dies ist der finale Zielmodus, der den besten Schutz vor Identitätsdiebstahl bietet.

Der normale Verlauf im Jahr 2026: 4 bis 6 Wochen lang mit p=none beginnen, die DMARC-Berichte analysieren, alle legitimen E-Mail-Quellen korrigieren, die fehlschlagen, dann für 2 bis 4 Wochen auf p=quarantine umstellen und schliesslich auf p=reject.

Die Tags aspf= und adkim= steuern das zwischen den Domains erforderliche Alignment-Niveau.

• Relaxed-Modus (r): Subdomains werden akzeptiert. Wenn Ihr From «kontakt@ihredomain.com» ist und SPF mit «mail.ihredomain.com» besteht, ist das Alignment in Ordnung. Dies ist der für die meisten Organisationen empfohlene Modus.

• Strict-Modus (s): Es ist eine exakte Übereinstimmung erforderlich. «kontakt@ihredomain.com» und «mail.ihredomain.com» sind dann nicht mehr aligned. Nur zu verwenden, wenn Sie die vollständige Kontrolle über alle Ihre versendenden Subdomains haben.

Dies ist wohl der am meisten unterschätzte Vorteil von DMARC. Mit rua=mailto:dmarc@ihredomain.com erhalten Sie täglich aggregierte XML-Berichte, die detailliert aufzeigen, wer versucht, E-Mails im Namen Ihrer Domain zu versenden, von welchen IPs aus und mit welcher SPF/DKIM-Erfolgsrate. Diese Berichte offenbaren vergessene Dienste (die ohne Authentifizierung für Sie versenden), Spoofing-Versuche und Konfigurationsfehler. Mehrere kostenlose oder kostenpflichtige Tools wie dmarcian, Postmark DMARC oder URIports parsen diese XML-Dateien in lesbare Dashboards.

Jedes Protokoll deckt eine Lücke ab, die die anderen nicht schliessen:

• SPF allein reicht nicht aus: Es überprüft die IP des Versandservers (Return-Path), nicht das sichtbare From. Ein Angreifer kann SPF mit seiner eigenen Domain bestehen und gleichzeitig Ihre Domain im From spoofen.

• DKIM allein reicht nicht aus: Es beweist, dass die Nachricht nicht verändert wurde, aber es teilt dem Empfängerserver nicht mit, was im Falle eines Fehlschlags zu tun ist. Und nicht alle Absender signieren mit DKIM.

• DMARC allein ist wirkungslos: Es stützt sich auf SPF oder DKIM, um zu funktionieren. Ohne diese hat DMARC nichts zu bewerten.

Zusammen bilden die drei ein vollständiges System: SPF überprüft die IP, DKIM überprüft die Integrität des Inhalts, DMARC wendet die Policy an und bietet Sichtbarkeit. Genau deshalb verlangen Google, Yahoo, Outlook und Apple nun alle drei für Massenversender.

Die logische Reihenfolge der Implementierung ist: SPF zuerst (am schnellsten), DKIM danach (erfordert die Generierung eines Schlüsselpaars), DMARC zuletzt (hängt von den beiden anderen ab). Hier ist die Vorgehensweise.

Listen Sie alle Dienste auf, die E-Mails im Namen Ihrer Domain versenden: Ihr E-Mail-Anbieter (Google Workspace, Microsoft 365), Ihre Cold-Email-Tools, Ihre transaktionalen Dienste, Ihre Newsletter. Fragen Sie bei jedem nach dem zu verwendenden include:-Wert. Kombinieren Sie diese in einem einzigen TXT-Eintrag an der Wurzel Ihrer Domain. Beginnen Sie mit ~all (soft fail). Überprüfen Sie anschliessend mit einem Tool wie MXToolbox, dass der Eintrag syntaktisch korrekt ist und unter dem Limit von 10 Lookups bleibt.

Folgen Sie für jeden Versanddienst dem Verfahren zur DKIM-Schlüsselgenerierung in dessen Oberfläche (Google Workspace: Apps -> Gmail -> E-Mail authentifizieren -> Neuen Record in 2048 Bit generieren). Kopieren Sie das bereitgestellte TXT und veröffentlichen Sie es in Ihrem DNS unter dem angegebenen Selektor. Warten Sie auf die DNS-Propagation (5 bis 60 Minuten) und aktivieren Sie dann die Authentifizierung in der Oberfläche des Anbieters. Wiederholen Sie dies für jedes Versandtool.

Beginnen Sie mit einer permissiven Policy, um Berichte zu sammeln, ohne den legitimen Datenverkehr zu blockieren:

v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.com; pct=100; aspf=r; adkim=r

Lesen Sie 4 bis 6 Wochen lang die täglichen Berichte und identifizieren Sie alle legitimen E-Mail-Quellen, die fehlschlagen. Korrigieren Sie sie (fügen Sie das fehlende SPF-include hinzu, aktivieren Sie DKIM auf dem vergessenen Dienst usw.). Sobald Ihre Berichte sauber sind, wechseln Sie für 2 bis 4 Wochen auf p=quarantine und dann auf p=reject.

Mehrere kostenlose Tools ermöglichen es, Ihre Konfiguration zu testen:

• MXToolbox: Überprüfung von SPF, DKIM, DMARC und vollständige Diagnose der Domain.

• Google Admin Toolbox: spezifische Diagnose für Google Workspace-Domains.

• dmarcian: Analyse der DMARC-Berichte in einem lesbaren Dashboard.

• dig-Befehl lokal: «dig TXT ihredomain.com» für SPF, «dig TXT _dmarc.ihredomain.com» für DMARC.

Selbst mit den besten Absichten treten bei SPF-, DKIM- und DMARC-Konfigurationen immer wieder bestimmte Fehler auf.

• Das Limit von 10 DNS-Lookups bei SPF überschreiten: Ihr Eintrag gibt einen PermError zurück und alles schlägt fehl. Flachen Sie Ihr SPF bei Bedarf ab.

• Mehrere separate SPF-Einträge veröffentlichen: Sie können nur einen einzigen SPF-TXT pro Domain haben. Mehrere Einträge = automatischer Fehlschlag.

• Vergessen, die Versanddomain zu alignen: Wenn DMARC im Strict-Modus ist und Ihr From auf der Root-Domain liegt, während SPF mit einer Subdomain besteht, schlägt das Alignment fehl.

• Die DMARC-Berichte nicht überwachen: Ein DMARC in p=none zu veröffentlichen, ohne jemals die Berichte zu lesen, ist nutzlos. Genau in diesem Moment werden die Probleme identifiziert.

• Einen zu kurzen DKIM-Schlüssel verwenden (1024 Bit): wird zunehmend von modernen Filtern abgestraft. Bevorzugen Sie 2048 Bit.

• Zu schnell auf p=reject umsteigen: Ohne vorheriges Monitoring blockieren Sie Ihre eigenen legitimen E-Mails. Rechnen Sie mindestens 6 Wochen bis zum Enforcement.

Wenn Sie im Jahr 2026 B2B-Cold-Email betreiben, ist die korrekte Konfiguration von SPF, DKIM und DMARC keine Option, sondern die Überlebensbedingung für Ihre Kampagnen. Die Toleranzschwellen der Anti-Spam-Filter sind seit 2024 radikal strenger geworden: Gmail, Outlook und Yahoo lehnen nicht authentifizierte E-Mails nun ab, anstatt sie wie früher einfach als Spam zu klassifizieren. Konkret hat eine Cold Email, die von einer Domain ohne saubere SPF/DKIM/DMARC versendet wird, eine Chance nahe null, den Posteingang zu erreichen.

Der andere kritische Punkt: Ihre Reputation einer Domain baut sich auf der Gesamtheit der versendeten E-Mails auf. Wenn ein Teil Ihrer Sendungen schlecht authentifiziert ist, leidet Ihre gesamte Domain darunter. Deshalb verwenden die Profis im Cold Email oft dedizierte Domains für das Prospecting (zum Beispiel «unternehmen-kontakt.com» anstelle der Hauptdomain «unternehmen.com»), mit eigenem SPF/DKIM/DMARC, um ihre Reputation zu isolieren.

Bei Emelia wird die SPF/DKIM/DMARC-Authentifizierung automatisch verwaltet, wenn Sie Ihre Postfächer mit der Plattform verbinden. Die DNS-Konfiguration bleibt auf Ihrer Seite (Sie behalten die Kontrolle über Ihre Domain), aber das Tool führt Sie Schritt für Schritt und überprüft die Gültigkeit Ihres Setups vor jedem Kampagnenversand.

SPF, DKIM und DMARC sind im Jahr 2026 keine Option mehr: Sie sind das technische Fundament, auf dem die Zustellbarkeit Ihrer E-Mails beruht. Ob Sie Cold Email, Newsletter, transaktionale E-Mails oder einfach interne Kommunikation betreiben, diese drei Protokolle bestimmen, ob Ihre Nachrichten den Posteingang erreichen oder im Spam verschwinden.

Die gute Nachricht: Die Einrichtung ist eine einmalige Investition, die sich auf Dauer auszahlt. Einmal korrekt konfiguriert und auf p=reject umgestellt, schützen Sie Ihre Domain vor Identitätsdiebstahl, steigern Ihre Zustellbarkeit erheblich und gewinnen die durch die DMARC-Berichte gebotene Sichtbarkeit. Wenn Sie heute eine B2B-E-Mail-Prospecting-Strategie starten, beginnen Sie damit, noch bevor Sie über Copywriting oder Sequenz nachdenken.