Startseite › Ratgeber

SPF, DKIM und DMARC einrichten: Einträge, Stolperfallen und Prüfung

Veröffentlicht 2026-11-03 ／ Aktualisiert 2026-11-03 ／ Von Yuki Nakazawa

Wer E-Mails von der eigenen Domain versendet, kommt um SPF, DKIM und DMARC nicht mehr herum. Gehen Sie in dieser Reihenfolge vor: einen einzigen SPF-Eintrag veröffentlichen, die DKIM-Signatur mit einem 2048-Bit-Schlüssel aktivieren und dann einen DMARC-Eintrag veröffentlichen, der mit p=none und aktivierten Berichten beginnt. Stellen Sie dabei auch sicher, dass die IP-Adresse, die Ihre Mails versendet, ein passendes Reverse DNS (PTR) hat.

Diese Anleitung gilt unabhängig davon, ob Sie über Shared Hosting, Ihren eigenen VPS, Google Workspace, Microsoft 365 oder einen Dienst für Massenversand senden. Sie enthält Einträge zum Anpassen, die Fehler, an denen die Authentifizierung am häufigsten scheitert, und zeigt, wie Sie anhand des Headers einer echten Nachricht prüfen, ob alles funktioniert.

Die Angaben wurden anhand der RFCs und der offiziellen Seiten von Google, Yahoo und Microsoft mit Stand November 2026 geprüft. Die Anforderungen der Mailbox-Anbieter ändern sich, maßgeblich sind daher deren Seiten.

Was SPF, DKIM und DMARC jeweils nachweisen und in welcher Reihenfolge Sie sie einrichten

SPF (Sender Policy Framework) erlaubt einer Domain, im DNS aufzulisten, welche Server ihre Mails senden dürfen. Der empfangende Server betrachtet den Envelope-Absender (die SMTP-Adresse MAIL FROM, die später als Return-Path erscheint), ruft den SPF-Eintrag dieser Domain ab und prüft, ob die verbindende IP-Adresse auf der Liste steht. Für sich genommen sagt SPF nichts über die From-Adresse aus, die der Leser sieht.

DKIM (DomainKeys Identified Mail) versieht jede Nachricht mit einer kryptografischen Signatur. Das sendende System signiert mit einem privaten Schlüssel, und Empfänger prüfen die Signatur mit einem im DNS veröffentlichten öffentlichen Schlüssel. Eine gültige Signatur belegt, dass die signierende Domain (der Wert d=) die Verantwortung für die Nachricht übernommen hat und dass die signierten Header und der Text unterwegs nicht verändert wurden.

DMARC (Domain-based Message Authentication, Reporting and Conformance) verknüpft beides mit der sichtbaren From-Domain. Eine Nachricht besteht DMARC nur, wenn SPF oder DKIM bestanden wird und die authentifizierte Domain mit der From-Domain übereinstimmt (Alignment). Der DMARC-Eintrag teilt Empfängern außerdem mit, was mit fehlgeschlagenen Nachrichten geschehen soll (nichts, Quarantäne oder Ablehnung) und wohin Sammelberichte gehen sollen. So finden Sie Versandquellen, die Sie vergessen haben.

Reihenfolge der Einrichtung

1. Listen Sie alle Systeme auf, die im Namen Ihrer Domain senden: Ihren eigenen Server, Google Workspace oder Microsoft 365, Newsletter- und Transaktionsmail-Dienste, Webformulare, Rechnungs- und Helpdesk-Tools.
2. Veröffentlichen Sie einen einzigen SPF-Eintrag, der alle abdeckt.
3. Aktivieren Sie DKIM auf jedem sendenden System und veröffentlichen Sie dessen öffentlichen Schlüssel.
4. Veröffentlichen Sie DMARC mit p=none und einer rua-Berichtsadresse. Google empfiehlt, nach der Einrichtung von SPF und DKIM 48 Stunden zu warten, bevor Sie DMARC hinzufügen.
5. Lesen Sie die Berichte, korrigieren Sie fehlschlagende Quellen und wechseln Sie dann zu p=quarantine und schließlich zu p=reject.

SPF einrichten: ein Eintrag, zehn Lookups

SPF ist ein TXT-Eintrag auf der Domain selbst. Hier eine Domain, die von ihrem eigenen Server über IPv4 und IPv6 sendet und zusätzlich Google Workspace nutzt:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

In den meisten DNS-Verwaltungen lassen Sie das Feld für den Host leer (oder geben @ ein), wählen TXT und fügen den Wert ab v=spf1 ein. Übliche Bausteine:

Stolperfallen bei SPF

• Ein SPF-Eintrag pro Name. RFC 7208 verbietet mehrere SPF-Einträge für dieselbe Domain; Empfänger liefern dann permerror, und SPF schlägt für alles fehl. Wenn Sie einen Dienst hinzufügen, bearbeiten Sie den vorhandenen Eintrag und hängen dessen include: an, statt einen zweiten v=spf1-Eintrag anzulegen.
• Das Limit von 10 Lookups. Die Mechanismen include, a, mx, ptr und exists sowie der Modifikator redirect lösen jeweils DNS-Abfragen aus, und die Summe über die gesamte Auswertung, einschließlich der Abfragen in verschachtelten Includes, darf 10 nicht überschreiten. Wer darüber liegt, erhält permerror. ip4:, ip6: und all kosten nichts. RFC 7208 sagt außerdem, dass Empfänger nach zwei Abfragen ohne Antwort abbrechen sollten. Entfernen Sie daher Includes für Dienste, die Sie nicht mehr nutzen.
• ~all oder -all. -all bedeutet, dass nicht aufgeführte Quellen nicht berechtigt sind (fail); ~all bedeutet, dass sie wahrscheinlich nicht berechtigt sind (softfail). Google empfiehlt ~all für Workspace-Domains; Microsoft empfiehlt -all für Microsoft 365-Domains, die auch DKIM und DMARC nutzen. Wenn Sie noch nicht sicher sind, alle Absender gefunden zu haben, beginnen Sie mit ~all und überlassen Sie die Durchsetzung DMARC.
• Subdomains brauchen einen eigenen Eintrag. Der SPF-Eintrag auf example.com deckt news.example.com nicht ab. Wenn Sie einen Dienst für Massenversand auf eine eigene Subdomain legen, erhält er zudem ein eigenes Budget von 10 Lookups, und seine Reputation bleibt von den Mails Ihrer Mitarbeiter getrennt.
• Syntaxfehler. Microsoft nennt die üblichen: include= statt include:, ein Leerzeichen nach dem Doppelpunkt und ein abschließender Punkt nach der eingebundenen Domain.

Für Domains, die nie Mails senden, veröffentlichen Sie v=spf1 -all, damit sie schwerer zu fälschen sind.

DKIM einrichten: 2048-Bit-Schlüssel und Selektoren

DKIM besteht aus zwei Hälften: Das sendende System signiert mit einem privaten Schlüssel, und im DNS wird der passende öffentliche Schlüssel veröffentlicht. Bei Google Workspace, Microsoft 365, den meisten Hosting-Panels und den meisten E-Mail-Diensten erzeugen Sie den Schlüssel in der Verwaltungskonsole und kopieren den angezeigten DNS-Wert.

Schlüssellänge und Selektoren

Verwenden Sie einen RSA-Schlüssel mit 2048 Bit. RFC 8301 legt 1024 Bit als Minimum fest und sagt, dass Signierende mindestens 2048 Bit verwenden sollten; außerdem verbietet es rsa-sha1. Googles Empfehlung stimmt damit überein: Wählen Sie 2048 Bit, wenn Ihr DNS-Anbieter das unterstützt, und weichen Sie nur auf 1024 aus, wenn nicht.

Der Selektor ist eine Bezeichnung, die angibt, welcher Schlüssel eine Nachricht signiert hat. So kann eine Domain mehrere Schlüssel gleichzeitig haben, einen pro Versanddienst oder einen pro Rotationszeitraum. Der öffentliche Schlüssel liegt unter selector._domainkey.yourdomain. Google Workspace verwendet standardmäßig den Selektor google. Microsoft 365 verwendet zwei CNAME-Einträge, selector1._domainkey und selector2._domainkey, die auf von Microsoft gehostete Schlüssel zeigen. Übernehmen Sie die genauen Ziele aus dem Defender-Portal oder aus Get-DkimSigningConfig, da das Format je nach Mandant unterschiedlich ist.

Einen langen öffentlichen Schlüssel veröffentlichen

Ein öffentlicher Schlüssel mit 2048 Bit ist länger als die 255 Zeichen, die in einem einzelnen DNS-Character-String erlaubt sind. In der Zonendatei wird er daher als mehrere Zeichenketten in Anführungszeichen innerhalb eines TXT-Eintrags geschrieben:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Ersetzen Sie die Teile in Klammern durch Ihren tatsächlichen Schlüssel. Empfänger fügen die Zeichenketten ohne Leerzeichen zusammen, Sie können also an beliebiger Stelle innerhalb des Schlüssels trennen. Viele Verwaltungspanels teilen lange Werte automatisch auf: Fügen Sie zuerst den ganzen Wert ein und teilen Sie ihn nur selbst auf, wenn das Panel ihn ablehnt. Achten Sie darauf, dass beim Kopieren nichts verloren geht; ein leeres p= bedeutet, dass der Schlüssel widerrufen wurde.

Auf Ihrem eigenen VPS mit Postfix oder einem ähnlichen MTA kann ein Signatur-Milter wie OpenDKIM das Schlüsselpaar erzeugen, etwa mit opendkim-genkey -b 2048 -s selector1 -d example.com. Veröffentlichen Sie den Inhalt der erzeugten Datei mit dem öffentlichen Schlüssel wie oben gezeigt.

Prüfen, ob Nachrichten wirklich signiert werden

Öffnen Sie eine gesendete Nachricht und suchen Sie nach einem DKIM-Signature:-Header. Sein Tag d= sollte Ihre Domain sein und s= der veröffentlichte Selektor. Viele E-Mail-Dienste signieren standardmäßig mit ihrer eigenen Domain. Das besteht DKIM, ist aber nicht mit Ihrer From-Domain abgestimmt und hilft DMARC daher nicht. Aktivieren Sie die Authentifizierung mit eigener Domain beim Dienst, damit d= Ihre Domain wird.

DMARC einrichten: mit p=none beginnen, dann durchsetzen

DMARC ist ein TXT-Eintrag unter _dmarc Ihrer Domain. Beginnen Sie im Überwachungsmodus, der Empfänger bittet, den Umgang mit Ihren Mails nicht zu ändern, und fordern Sie Sammelberichte an:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Sammelberichte sind maschinenlesbare Übersichten, welche IP-Adressen im Namen Ihrer Domain Mails gesendet haben und ob diese bestanden. Google empfiehlt ein eigenes Postfach oder eine eigene Gruppe für den Empfang. Sobald die Berichte zeigen, dass jede legitime Quelle mit Alignment besteht, verschärfen Sie die Richtlinie, indem Sie denselben Eintrag bearbeiten, statt einen zweiten anzulegen:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Alignment einfach erklärt

Um DMARC zu bestehen, muss mindestens SPF oder DKIM für eine Domain bestanden werden, die zur From-Domain passt. Im Modus relaxed müssen die Organisationsdomains übereinstimmen, eine DKIM-Signatur mit d=example.com passt also zu Mails von alerts@news.example.com. Der Modus strict verlangt eine exakte Übereinstimmung. E-Mail-Dienste verwenden im Return-Path oft ihre eigene Domain, sodass SPF nicht abgestimmt ist, selbst wenn es besteht. Ein abgestimmtes DKIM ist der praktische Weg, solche Nachrichten durch DMARC zu bringen.

Wenn Sie für Subdomains eine andere Richtlinie wünschen, fügen Sie sp= hinzu. Beispielsweise lehnt p=reject; sp=quarantine fehlschlagende Mails der Hauptdomain ab, während fehlschlagende Mails von Subdomains nur in Quarantäne kommen.

Hinweis zum aktualisierten Standard

Im Mai 2026 wurde DMARC als RFC 9989 neu veröffentlicht, das RFC 7489 ablöst. Bestehende Einträge funktionieren weiter und beginnen weiterhin mit v=DMARC1. Der neue Standard streicht den Tag pct, der außer bei 0 oder 100 selten korrekt angewendet wurde, und führt Tags wie t=y (Testmodus) und np (Richtlinie für nicht existierende Subdomains) ein. Manche Hilfeseiten von Anbietern zeigen noch pct. Am eindeutigsten führen Sie die Durchsetzung daher ein, indem Sie die p=-Werte schrittweise durchlaufen.

Reverse DNS (PTR) für Ihre sendende IP

Reverse DNS ordnet einer IP-Adresse wieder einen Hostnamen zu. Google verlangt von allen Absendern an private Gmail-Konten einen PTR-Eintrag, dessen Hostname wieder auf dieselbe sendende IP auflöst. Yahoo verlangt gültiges Forward- und Reverse-DNS für sendende IPs und empfiehlt einen aussagekräftigen, nicht generischen PTR-Eintrag.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

Der PTR-Eintrag liegt nicht in der Zone Ihrer Domain. Ihn verwaltet, wem die IP-Adresse gehört. Bei einem VPS setzen Sie ihn daher im Kundenpanel des Anbieters (oft als Reverse DNS oder rDNS bezeichnet) und legen dann in Ihrem eigenen DNS einen passenden A-Eintrag an (AAAA für IPv6). Wenn Sie über IPv6 senden, braucht die IPv6-Adresse dieselbe Behandlung. Bei Google Workspace, Microsoft 365, E-Mail-Diensten und den meisten Shared-Hosting-Angeboten verwaltet der Anbieter die sendenden IPs und deren Reverse DNS für Sie.

So prüfen Sie Ihre Einrichtung

Authentication-Results lesen

Senden Sie eine Testnachricht an ein externes Postfach und lassen Sie sich die vollständigen Header anzeigen. In Gmail öffnen Sie die Nachricht und wählen „Original anzeigen“. Googles DKIM-Hilfe weist darauf hin, dass Sie an einen anderen Nutzer und nicht an sich selbst senden sollten. Suchen Sie nach einem Header wie diesem:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Das genaue Format unterscheidet sich je nach Empfänger. Entscheidend sind spf=pass, dkim=pass und dmarc=pass, mit Ihrer eigenen Domain in header.i oder header.d und in header.from. Besteht SPF für die Domain eines Dienstes, DKIM zeigt aber eine andere Domain, schlägt DMARC fehl: Korrigieren Sie zuerst das DKIM-Alignment.

DNS direkt abfragen

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Unter Windows erfüllt nslookup -type=TXT _dmarc.example.com denselben Zweck. DNS-Änderungen brauchen Zeit, bis sie sich verbreiten; laut Google kann es bei SPF und DKIM jeweils bis zu 48 Stunden dauern, bis sie wirken. Kostenlose Online-Prüftools können Ihre Einträge ebenfalls auswerten und die SPF-Lookups für Sie zählen.

Wenn die Authentifizierung besteht und Mails trotzdem zurückkommen oder im Spam landen, prüfen Sie mit unserem Blacklist-Checker, ob Ihre sendende IP oder Domain auf einer DNSBL steht, und lesen Sie unter E-Mail wegen Blacklist nicht zugestellt die nächsten Schritte.

Anforderungen an Absender bei Gmail, Yahoo und Outlook.com

Die großen Mailbox-Anbieter setzen Authentifizierung inzwischen durch. Mit Stand November 2026 sagen ihre offiziellen Seiten Folgendes.

• Gmail (in Kraft seit dem 1. Februar 2024): Alle, die an private Gmail-Konten senden, brauchen SPF oder DKIM, übereinstimmendes Forward- und Reverse-DNS, eine TLS-Verbindung und eine Spamrate unter 0,3% in den Postmaster Tools. Absender von mehr als 5.000 Nachrichten pro Tag brauchen zusätzlich SPF und DKIM, einen DMARC-Eintrag (p=none genügt), eine mit SPF oder DKIM abgestimmte From-Domain und die Abmeldung mit einem Klick für Marketing-Mails. DKIM-Schlüssel müssen mindestens 1024 Bit lang sein, empfohlen werden 2048.
• Yahoo (Durchsetzung ab Februar 2024): Alle Absender brauchen SPF oder DKIM, gültiges Forward- und Reverse-DNS und eine Spamrate unter 0,3%. Massenversender brauchen SPF und DKIM, eine bestandene DMARC-Richtlinie von mindestens p=none, Alignment der From-Domain (relaxed genügt), eine funktionierende Abmeldung mit einem Klick und gültiges Forward- und Reverse-DNS für die sendenden IPs.
• Outlook.com (der Verbraucherdienst hinter outlook.com, hotmail.com und live.com): Domains, die mehr als 5.000 E-Mails pro Tag senden, müssen SPF und DKIM bestehen und DMARC mit mindestens p=none veröffentlichen, abgestimmt mit SPF oder DKIM. Ab dem 5. Mai 2025 würden nicht konforme Nachrichten laut Microsoft mit dem Fehler 550; 5.7.515 abgelehnt.

Den vollständigen Text finden Sie in den Google-Richtlinien für E-Mail-Absender, den Best Practices für Absender von Yahoo und der Ankündigung von Microsoft zu Outlook.com. Auch wenn Sie weit weniger Nachrichten senden: Wenn Sie alle drei jetzt einrichten, trifft Sie eine spätere niedrigere Schwelle nicht unvorbereitet. Zur Fehlersuche speziell bei Gmail siehe Gmail stellt Ihre E-Mails nicht zu.

Häufige Fehler

• Ein zweiter SPF-Eintrag. Wer für jeden Dienst einen neuen v=spf1-Eintrag anlegt, macht SPF für die gesamte Domain ungültig. Führen Sie alles in einem Eintrag zusammen.
• Zu viele Includes. Alte Dienste, die in SPF verbleiben, zehren am Budget von 10 Lookups. Entfernen Sie, was Sie nicht mehr nutzen, und verlagern Sie Massenversand auf eine Subdomain.
• Schlüssel veröffentlicht, Signatur nicht aktiviert. In Google Workspace müssen Sie nach dem Aktivwerden des DNS-Eintrags noch auf „Authentifizierung starten“ klicken; andere Plattformen haben einen ähnlichen Schalter.
• Der Dienst signiert mit seiner eigenen Domain. SPF und DKIM bestehen beide, DMARC schlägt fehl. Aktivieren Sie die Signatur mit eigener Domain.
• Direkt auf p=reject springen. Ein vergessenes Webformular oder Rechnungssystem stellt über Nacht nichts mehr zu. Beginnen Sie mit p=none und lesen Sie die Berichte.
• Fehler durch Kopieren und Einfügen. Zusätzliche Anführungszeichen im Wert, ein abgeschnittener Schlüssel oder ein Hostname, der als _dmarc.example.com.example.com endet, weil das Panel die Domain selbst anhängt. Ein kurzes dig deckt all das auf.

Häufige Fragen

Verwendete offizielle Seiten

Die Angaben in diesem Artikel wurden zum Zeitpunkt der Veröffentlichung anhand der unten aufgeführten offiziellen Seiten geprüft. Richtlinien und Verhalten können sich ohne Ankündigung ändern. Prüfen Sie daher die offiziellen Seiten, bevor Sie sich in wichtigen Fragen darauf verlassen.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Verwandte Ratgeber

Alle Ratgeber →