SPF, DKIM und DMARC einrichten: Anleitung für Cold-E-Mails

Wenn Sie Cold-E-Mails von Ihrer eigenen Domain senden, entscheiden drei DNS-Einträge darüber, ob empfangende Server glauben, dass die E-Mail wirklich von Ihnen stammt: SPF, DKIM und DMARC. Ohne sie kann selbst eine gut geschriebene erste E-Mail gefiltert werden, bevor jemand sie liest.

Diese Anleitung richtet sich an Gründerinnen und Gründer sowie Vertriebsteams, die Akquise-E-Mails von einer Adresse wie you@yourcompany.com aus versenden, meist über Google Workspace. Wir (Outreach) gehen jeden Eintrag in der Reihenfolge durch, in der Sie ihn einrichten sollten, zeigen die Eintragsformate genau so, wie die Hilfeseiten von Google und die RFCs sie veröffentlichen, und weisen auf die Fehler hin, die einen Eintrag in Ordnung aussehen lassen, während er unbemerkt versagt.

Sie müssen kein DNS-Experte sein. Sie brauchen Zugriff auf die DNS-Einstellungen Ihrer Domain (bei Ihrem Domain-Anbieter oder DNS-Host) und für DKIM Administratorzugriff auf Google Workspace.

Was sind SPF, DKIM und DMARC, jeweils in einem Satz?

SPF listet die Server auf, die E-Mails für Ihre Domain senden dürfen, DKIM fügt eine kryptografische Signatur hinzu, die beweist, dass eine Nachricht weder gefälscht noch verändert wurde, und DMARC sagt Empfängern, was zu tun ist, wenn eine Nachricht diese Prüfungen nicht besteht. Alle drei werden als TXT-Einträge im DNS Ihrer Domain veröffentlicht.

Eintrag	Wo er liegt	Was er beantwortet
SPF	`yourcompany.com` (Host `@`)	„Darf dieser Server für diese Domain senden?“
DKIM	`google._domainkey.yourcompany.com`	„Wurde diese Nachricht von der Domain signiert und ist sie unverändert?“
DMARC	`_dmarc.yourcompany.com`	„Was soll nach dem Willen des Domaininhabers geschehen, wenn eine Prüfung fehlschlägt?“

Sie arbeiten zusammen. SPF und DKIM beweisen jeweils etwas Enges; DMARC verknüpft diese Nachweise mit der Adresse, die Menschen tatsächlich in der From:-Zeile sehen.

Sind diese Einträge für Cold-E-Mails tatsächlich erforderlich?

Ja – mindestens SPF oder DKIM ist für jeden Absender an Gmail und Yahoo erforderlich, und Absender von Massen-E-Mails brauchen alle drei. Das ist keine Empfehlung für bewährte Verfahren, sondern steht in den veröffentlichten Absenderregeln beider Anbieter.

Die Richtlinien für E-Mail-Absender von Google verlangen von allen Absendern: „Richten Sie die SPF- oder DKIM-E-Mail-Authentifizierung für Ihre Absenderdomains ein.“ Absender von „mehr als 5.000 Nachrichten pro Tag an Gmail-Konten“ müssen außerdem „SPF und DKIM einrichten“ sowie „die DMARC-E-Mail-Authentifizierung für Ihre Absenderdomain einrichten“, und die From:-Domain muss mit der SPF- oder DKIM-Domain übereinstimmen. Diese Regeln gelten seit dem 1. Februar 2024.

Die Best Practices des Yahoo Sender Hub stimmen überein: Jeder Absender muss „mindestens SPF oder DKIM umsetzen“, und Absender von Massen-E-Mails müssen „sowohl SPF als auch DKIM umsetzen“ und „eine gültige DMARC-Richtlinie mit mindestens p=none veröffentlichen.“

Ein kleines Cold-E-Mail-Programm erreicht vielleicht nie 5.000 Nachrichten pro Tag. Richten Sie trotzdem alle drei ein: Es kostet nichts, dauert einen Nachmittag und bedeutet, dass Sie nie herausfinden müssen, wo die Grenze liegt.

Wie richten Sie SPF ein?

Fügen Sie an Ihrer Stammdomain einen TXT-Eintrag hinzu, der mit v=spf1 beginnt, jeden Dienst auflistet, der E-Mails für Sie versendet, und mit ~all endet. Für eine Domain, die nur über Google Workspace sendet, nennt die SPF-Einrichtungsseite von Google genau diesen Eintrag:

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

Schritte:

Melden Sie sich bei den DNS-Einstellungen Ihres Domain-Anbieters an.
Erstellen Sie einen TXT-Eintrag. Für das Feld Host oder Name sagt Google, dass Sie @ eingeben sollen, wenn Sie den Eintrag zur Stammdomain und nicht zu einer Subdomain hinzufügen.
Fügen Sie den Eintrag als Wert ein und speichern Sie.
Warten Sie. Google weist darauf hin: „Es kann bis zu 48 Stunden dauern, bis die SPF-Authentifizierung wirksam wird.“

Wenn auch andere Dienste E-Mails von Ihrer Domain senden – ein Newsletter-Tool, ein CRM, ein Dienst für Transaktions-E-Mails –, braucht jeder sein eigenes include: im selben Eintrag. Die Seite von Google nennt diese kombinierten Beispiele:

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

Verwenden Sie den include-Wert, den jeder sendende Dienst für sich selbst dokumentiert; raten Sie ihn nicht.

Sollte der SPF-Eintrag mit ~all oder -all enden?

Die Einrichtungsanleitung von Google verwendet ~all, und das ist die sichere Voreinstellung, solange Sie noch dabei sind, jeden Dienst zu ermitteln, der für Sie sendet. Die beiden Endungen bedeuten in RFC 7208, dem SPF-Standard, Unterschiedliches:

~all (softfail) ist „eine schwache Aussage der veröffentlichenden ADMD, dass der Host wahrscheinlich nicht autorisiert ist.“
-all (fail) ist „eine ausdrückliche Aussage, dass der Client nicht berechtigt ist, die Domain in der angegebenen Identität zu verwenden.“

Mit -all schlägt die Prüfung für einen sendenden Dienst, den Sie vergessen haben aufzunehmen, hart fehl. Sobald DMARC eingerichtet ist und seine Berichte zeigen, dass jede legitime Quelle besteht, spielt die SPF-Endung eine geringere Rolle, weil die DMARC-Richtlinie dann die Anweisung ist, der Empfänger folgen.

Warum versagt SPF bei zu vielen include-Angaben?

Weil eine SPF-Prüfung höchstens 10 DNS-Abfragen auslösen darf; darüber hinaus wird das gesamte Ergebnis zu einem Fehler. RFC 7208, Abschnitt 4.6.4 besagt, dass Implementierungen „die Gesamtzahl dieser Begriffe bei der SPF-Auswertung auf 10 begrenzen MÜSSEN“ und dass „die Implementierung, wenn dieses Limit überschritten wird, ‚permerror‘ zurückgeben MUSS.“

Die Begriffe, die zählen, sind include, a, mx, ptr, exists und der Modifikator redirect. Entscheidend ist, dass die Zählung die gesamte Auswertung umfasst – ein include:, das selbst weitere Includes enthält, verbraucht also mehrere Ihrer 10. Die Seite von Google formuliert das als „Ein SPF-Eintrag kann bis zu 10 include-Tags enthalten“; der RFC-Text ist die strengere Lesart, weil auch verschachtelte Abfragen zählen.

Wenn Sie im Lauf der Jahre mehrere Vertriebs- und Marketing-Tools hinzugefügt haben, entfernen Sie die, die Sie nicht mehr verwenden, bevor Sie neue Includes hinzufügen.

Was passiert, wenn eine Domain zwei SPF-Einträge hat?

SPF scheitert mit einem Fehler – zwei Einträge gelten als fehlerhafte Konfiguration und nicht als zwei Listen, die zusammengeführt werden. RFC 7208 besagt, dass die Prüfung, wenn für eine Domain mehr als ein v=spf1-Eintrag existiert, „das Ergebnis ‚permerror‘ ergibt.“

Häufig passiert das so: Jemand fügt für ein neues Tool einen zweiten TXT-Eintrag hinzu, statt den vorhandenen zu bearbeiten. Die Lösung ist, beide zu einem Eintrag mit mehreren include:-Begriffen zusammenzuführen, wie in den Beispielen oben.

Wie aktivieren Sie DKIM in Google Workspace?

Erstellen Sie in der Admin-Konsole einen Schlüssel, veröffentlichen Sie ihn als TXT-Eintrag unter google._domainkey und klicken Sie dann auf „Authentifizierung starten.“ Die DKIM-Einrichtungsseite von Google beschreibt den Weg:

Gehen Sie in der Google Admin-Konsole zu Apps > Google Workspace > Gmail > E-Mail authentifizieren. (Dafür benötigen Sie die Administratorberechtigung für die Gmail-Einstellungen.)
Wählen Sie die Domain aus und erstellen Sie einen neuen Eintrag.
Wählen Sie die Schlüssellänge. Google sagt, wählen Sie 2048, „wenn Ihr Domainanbieter 2048-Bit-Schlüssel unterstützt“, weil „längere Schlüssel sicherer sind als kürzere“, und 1024 nur, „wenn Ihr Domainhost keine 2048-Bit-Schlüssel unterstützt.“
Behalten Sie den standardmäßigen DKIM-Präfixselektor google bei – Google nennt ihn „die empfohlene Option“ für Workspace.
Google zeigt Ihnen einen DNS-Hostnamen, google._domainkey, und einen TXT-Wert, der mit v=DKIM1 beginnt. Kopieren Sie beide in einen neuen TXT-Eintrag bei Ihrem DNS-Host.
Klicken Sie wieder in der Admin-Konsole auf Authentifizierung starten.

Der TXT-Wert, den Google erzeugt, hat diese Form (der Schlüssel selbst ist eine lange, für Ihre Domain einzigartige Zeichenfolge):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Zeitablauf: Google sagt, „es kann bis zu 48 Stunden dauern, bis die DKIM-Authentifizierung funktioniert“, nachdem Sie den Schlüssel hinzugefügt haben. Wenn Sie Gmail gerade erst für eine neue Domain eingerichtet haben, weist Google darauf hin, dass Sie „24 bis 72 Stunden warten müssen“, bevor der DKIM-Schlüssel in der Admin-Konsole überhaupt verfügbar ist.

Wenn ein anderer Dienst E-Mails für Sie versendet, liefert er Ihnen einen eigenen DKIM-Eintrag mit eigenem Selektor. Veröffentlichen Sie auch diesen – mehrere DKIM-Schlüssel mit unterschiedlichen Selektoren können nebeneinander bestehen, anders als bei SPF.

Wie richten Sie DMARC ein, ohne Ihre eigene E-Mail zu blockieren?

Veröffentlichen Sie zuerst einen TXT-Eintrag unter _dmarc.yourcompany.com mit p=none, lesen Sie die Berichte und verschärfen Sie die Richtlinie erst dann. Die DMARC-Einrichtungsseite von Google sagt: „Wenn Sie mit der Verwendung von DMARC beginnen, empfehlen wir, die Richtlinienoption (p) auf none festzulegen.“ Sie rät außerdem: „Warten Sie nach der Einrichtung von SPF und/oder DKIM 48 Stunden, bevor Sie DMARC einrichten.“

Die Seite von Google nennt diesen vollständigen Beispieleintrag:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Dieses Beispiel zeigt den fertigen, strengsten Zustand. Für einen ersten Eintrag genügt dasselbe Format mit einer Überwachungsrichtlinie und einer Berichtsadresse – zum Beispiel v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. Der Tag rua sendet zusammengefasste Berichte an dieses Postfach; Google empfiehlt ein eigenes Postfach oder eine eigene Gruppe, weil Berichte in großer Zahl eintreffen können.

Die drei Richtlinienwerte, wie in der DMARC-Spezifikation definiert:

Richtlinie	Was Sie von Empfängern verlangen
`p=none`	Keine bestimmte Maßnahme – nur berichten
`p=quarantine`	Fehlschläge als verdächtig behandeln (zum Beispiel im Spam-Ordner ablegen)
`p=reject`	E-Mails ablehnen, die die DMARC-Prüfung nicht bestehen

Eine Domain bekommt einen DMARC-Eintrag. Nach RFC 9989 werden, wenn mehrere DMARC-Einträge zurückgegeben werden, „alle verworfen“ – das heißt, es gilt überhaupt keine Richtlinie.

Was bedeutet „Übereinstimmung“ (Alignment), und warum scheitert DMARC, obwohl SPF besteht?

DMARC besteht nur, wenn SPF oder DKIM für eine Domain besteht, die mit der From:-Adresse übereinstimmt, die Menschen sehen. SPF kann für die eigene Domain Ihres Versanddienstes bestehen, während die From:-Zeile Ihre Domain zeigt – und dann scheitert DMARC trotzdem, weil die bestandene Domain nicht übereinstimmt.

Die DMARC-Spezifikation legt fest, dass eine Nachricht besteht, wenn mindestens ein Authentifizierungsverfahren ein „Bestanden“ ergibt, „auf Grundlage einer Kennung, die übereinstimmt“ (RFC 7489, jetzt fortgeführt in RFC 9989). Standardmäßig ist die Übereinstimmung locker (relaxed; adkim und aspf stehen standardmäßig auf r): mail.yourcompany.com und yourcompany.com gelten als Treffer, weil sie dieselbe Organisationsdomain haben. Der strenge Modus (s), wie in Googles Beispiel, verlangt eine exakte Übereinstimmung.

In der Praxis ist DKIM deshalb für Cold-E-Mails so wichtig: Signiert Ihr Versanddienst mit Ihrer Domain, besteht die DKIM-Übereinstimmung, selbst wenn die SPF-Übereinstimmung scheitert.

Hat sich der DMARC-Standard 2026 geändert?

Ja. RFC 9989, im Mai 2026 als Standards-Track-Dokument veröffentlicht, löst die ursprüngliche Spezifikation RFC 7489 ab – und entfernt den Tag pct. Bestehende v=DMARC1-Einträge funktionieren weiter.

Die wichtigste Änderung, die die meisten Absender bemerken werden: pct (die Richtlinie nur auf einen Prozentsatz fehlschlagender E-Mails anwenden) entfällt. Der RFC-Text erklärt, dass „die Betriebserfahrung gezeigt hat, dass der Tag ‚pct‘ meist nicht genau angewendet wurde, es sei denn, der angegebene Wert war entweder 0 oder 100.“ An seine Stelle tritt ein Testkennzeichen, t=y, das Empfänger bittet, Ihre angegebene Richtlinie nicht anzuwenden, solange Sie sie testen.

Die Hilfeseite von Google zeigt in ihrem Beispiel weiterhin pct=100. Das richtet keinen Schaden an: RFC 9989 sagt, „unbekannte Tags MÜSSEN ignoriert werden“, sodass ein übrig gebliebenes pct einfach übersprungen wird. Wenn Sie Ihren Eintrag das nächste Mal bearbeiten, können Sie es entfernen.

Wie prüfen Sie, ob alles funktioniert?

Rufen Sie die veröffentlichten Einträge ab, senden Sie dann eine echte Nachricht an eine Gmail-Adresse und lesen Sie deren Authentifizierungsergebnisse. Zwei schnelle Prüfungen:

Rufen Sie die DNS-Einträge ab. Unser kostenloses Prüfwerkzeug ruft die SPF-, DKIM- und DMARC-Einträge für die Domain der eingegebenen Adresse ab – ohne Registrierung. Es prüft Googles Standard-DKIM-Selektor (google._domainkey); wenn Ihr Versanddienst einen anderen Selektor verwendet, meldet das Prüfwerkzeug DKIM als nicht bestätigt, selbst wenn es eingerichtet ist. Das Werkzeug gibt es auf Englisch und Koreanisch; geben Sie Ihre Absender-E-Mail-Adresse ein.
Prüfen Sie eine echte Nachricht. Senden Sie eine E-Mail an ein Gmail-Konto, auf das Sie Zugriff haben, öffnen Sie sie, wählen Sie „Original anzeigen“ und achten Sie auf SPF: PASS, DKIM: PASS und DMARC: PASS.

Geben Sie den DMARC-Berichten dann ein bis zwei Wochen Zeit. Wenn jede legitime Quelle, die Sie nutzen, als bestanden angezeigt wird, wechseln Sie von p=none zu p=quarantine und später zu p=reject, wenn Sie den stärksten Schutz vor Absenderfälschung wünschen.

Welche Fehler führen am häufigsten zum Scheitern der Authentifizierung?

Zwei SPF-Einträge, zu viele SPF-Abfragen, ein erzeugter, aber nie gestarteter DKIM-Schlüssel und DMARC, das veröffentlicht wurde, bevor SPF und DKIM Zeit hatten zu wirken. Eine Checkliste:

Ein SPF-Eintrag, in dem jeder Absender als include: enthalten ist, und höchstens 10 Abfragebegriffe.
Klicken Sie auf „Authentifizierung starten“, nachdem Sie den DKIM-Schlüssel veröffentlicht haben – der DNS-Eintrag allein genügt nicht.
Warten Sie etwa 48 Stunden nach SPF und DKIM, bevor Sie DMARC hinzufügen, und veröffentlichen Sie es unter _dmarc, nicht an der Stammdomain.
Senden Sie von einer Domain, die Sie kontrollieren. Sie können kein DMARC für eine @gmail.com-Adresse veröffentlichen.

Authentifizierung sorgt dafür, dass Ihre E-Mail in Betracht gezogen wird; sie sorgt nicht dafür, dass Empfänger sie wollen. Spam-Beschwerden zählen weiterhin – Google und Yahoo sagen beide, dass Sie Ihre Spamrate unter 0.3% halten sollen, wie wir in warum Cold-E-Mails im Spam landen behandeln. Und der Versand an Adressen, die nicht existieren, erzeugt Rückläufer, weshalb wir empfehlen, Adressen vor dem Senden zu prüfen.

Kurz gefasst

Google und Yahoo verlangen SPF oder DKIM von jedem Absender und von Absendern von Massen-E-Mails alle drei plus Übereinstimmung (5.000+ Nachrichten pro Tag an Gmail).
SPF: ein TXT-Eintrag unter @, zum Beispiel v=spf1 include:_spf.google.com ~all; bleiben Sie innerhalb von 10 DNS-Abfragebegriffen.
DKIM: 2048-Bit-Schlüssel, Selektor google, TXT unter google._domainkey, dann Authentifizierung starten.
DMARC: ein TXT-Eintrag unter _dmarc, mit p=none und einer Berichtsadresse beginnen, später verschärfen. RFC 9989 (Mai 2026) hat pct durch t=y ersetzt.
Prüfen Sie Ihre Einträge mit unserem kostenlosen Prüfwerkzeug für die E-Mail-Authentifizierung und bestätigen Sie sie dann an einer echten Nachricht.