SPF DKIM DMARC einrichten: So landen Firmenmails nicht im Spam

SPF DKIM DMARC einrichten: Was bewirkt jede Prüfung?

SPF, DKIM und DMARC sind drei DNS Einträge, die dem empfangenden Mailserver beweisen, dass eine Nachricht Ihrer Domain wirklich von Ihnen stammt. Zum Einrichten erfassen Sie zuerst alle Dienste, die in Ihrem Namen senden, tragen dann SPF und DKIM ein, starten DMARC mit p=none, lesen die Berichte und verschärfen die Richtlinie schrittweise.

Stellen Sie sich eine Einlasskontrolle vor. Zunächst ist SPF (Sender Policy Framework) die Gästeliste: Sie nennt die Server, die für Ihre Domain senden dürfen. Danach ist DKIM (DomainKeys Identified Mail) das Siegel auf dem Umschlag, also der Nachweis, dass die Nachricht unterwegs unverändert blieb und Ihre Domain sie signiert hat. Schließlich ist DMARC (Domain based Message Authentication, Reporting and Conformance) die Anweisung an den Türsteher. Es legt also fest, was bei einer ungültigen Liste oder einem ungültigen Siegel geschieht, und liefert Ihnen zudem einen Bericht.

Dieser Ratgeber zeigt, wie Sie SPF DKIM DMARC einrichten, und richtet sich an Unternehmen, deren Mails im Spamordner landen oder zurückkommen. Zeigt Gmail bereits einen Fehlercode, lesen Sie zunächst unseren Beitrag zum Gmail Fehler 550 5.7.26. Hier geht es stattdessen um die dauerhafte Einrichtung. Außerdem nutzen alle Beispiele die Domain example.com, und die Werte stammen aus offiziellen Dokumentationen.

Warum landen Ihre geschäftlichen Mails im Spamordner oder kommen zurück?

Ein empfangender Server stellt vor der Annahme eine Frage: Darf dieser Absender diese Domain verwenden? Die Antwort sucht er dann in Ihren DNS Einträgen. Fehlen die Einträge oder sind sie falsch, stuft der Server die Nachricht als verdächtig ein. Deshalb kann selbst eine saubere, gut geschriebene Mail im Spamordner landen.

Die Absenderrichtlinien von Google sind hier eindeutig: Wer an private Gmail Adressen sendet, braucht SPF oder DKIM, und Absender mit hohem Volumen brauchen alle drei Einträge. Ebenso veröffentlicht Yahoo ähnliche Anforderungen für Massenversender. Prüfen Sie die aktuellen Schwellenwerte allerdings auf den offiziellen Seiten, denn sie können sich ändern.

Folglich landen nicht authentifizierte Nachrichten im Spam oder kommen mit einem Code wie 5.7.26 zurück. Das Problem liegt also oft in der Identität, nicht im Inhalt. Zudem erklärt unser Leitfaden zur E-Mail Zustellbarkeit weitere Faktoren. Der Reverse DNS Eintrag (PTR) Ihrer sendenden IP Adresse eine eigene Anforderung, die unser Beitrag zum PTR Eintrag behandelt.

Was ist der Unterschied zwischen SPF, DKIM und DMARC, und wie arbeiten sie zusammen?

Die drei Einträge ersetzen sich nicht, denn jeder beantwortet eine andere Frage. Die Tabelle zeigt die Unterschiede auf einen Blick. TXT ist dabei der DNS Eintragstyp für Text, und ein CNAME verweist einen Namen auf einen anderen.

Kurz gesagt liefern SPF und DKIM die Belege, und DMARC gleicht sie mit der Absenderadresse ab und entscheidet. Der empfangende Server geht in dieser Reihenfolge vor:

1. Zunächst prüft er den SPF Eintrag der Umschlagabsender Domain. SPF besteht, wenn die sendende IP in der Liste steht.
2. Danach verifiziert er die DKIM Signatur mit dem öffentlichen Schlüssel aus dem DNS.
3. Dann vergleicht er beide Ergebnisse mit der Absenderdomain. Diesen Vergleich nennt man Alignment.
4. Schließlich besteht DMARC, wenn SPF oder DKIM mit Alignment besteht. Andernfalls greift Ihre Richtlinie.

Außerdem erklärt unser Beitrag zu MTA und SMTP Relay, wie eine Nachricht von Server zu Server wandert.

SPF DKIM DMARC einrichten: Was bereiten Sie zuerst vor?

Klären Sie vor dem ersten DNS Eintrag zwei Dinge: Wer sendet in Ihrem Namen Mails, und wer verwaltet Ihr DNS? Sobald Sie beides wissen, ist der Rest Routine, weil die übrigen Schritte einer festen Reihenfolge folgen. Gehen Sie so vor:

1. Erfassen Sie alle Dienste, die in Ihrem Namen Mails senden.
2. Finden Sie das Panel, in dem Sie DNS Einträge verwalten.
3. Prüfen Sie vorhandene SPF, DKIM und DMARC Einträge und notieren Sie deren Werte.
4. Legen Sie genau einen SPF Eintrag an oder aktualisieren Sie den vorhandenen.
5. Aktivieren Sie DKIM bei jedem sendenden Dienst.
6. Veröffentlichen Sie einen DMARC Eintrag mit p=none und einer Berichtsadresse.
7. Lesen Sie die Berichte und beheben Sie legitime Quellen ohne Alignment.
8. Heben Sie die Richtlinie auf quarantine an, sobald die Berichte sauber sind, und auf reject, wenn es zu Ihnen passt.

Bei einer Domain mit Google Workspace sieht das Ergebnis ungefähr so aus (der Schlüssel ist gekürzt):

@                 TXT  v=spf1 include:_spf.google.com ~all
google._domainkey TXT  v=DKIM1; k=rsa; p=MIIBIjANBgkq...
_dmarc            TXT  v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In der Praxis ist die Reihenfolge wichtig. DMARC aktivieren Sie zuletzt, denn eine strenge Richtlinie bei unvollständigem SPF und DKIM kann legitime Mails beeinträchtigen. Außerdem ändert p=none nichts an der Zustellung, Sie sammeln zunächst nur Berichte. RFC 9989 ist der aktuelle DMARC Standard und löst den älteren RFC 7489 ab. Er beschreibt denselben Weg: erst p=none, dann die Berichte auswerten.

Wie erfassen Sie alle Dienste, die in Ihrem Namen Mails senden?

Ohne diesen Schritt bleibt die Einrichtung lückenhaft. Denn am häufigsten sehen wir einen vergessenen Dienst, der still in Ihrem Namen sendet. Nehmen Sie diese Quellen in Ihre Liste auf:

• Ihr Postfachanbieter: Google Workspace, Microsoft 365 oder der Mailserver Ihres Hostinganbieters.
• Kontaktformulare, Angebotsformulare und Bestellformulare Ihrer Website.
• Newsletter und Marketing Automation Tools.
• CRM Systeme, Angebotssoftware und Rechnungsprogramme.
• Helpdesk und Buchungssysteme.
• Ihr Onlineshop samt Zahlungsbenachrichtigungen.
• Geräte wie Scanner und Drucker sowie alte Serverskripte.

Um die Liste zu vervollständigen, fragen Sie zunächst jedes Team. Öffnen Sie dann die Header einiger aktueller Nachrichten und sehen Sie sich Bounce Meldungen an. Notieren Sie außerdem pro Quelle drei Fakten: von welcher Domain sie sendet, was sie für SPF braucht und wie Sie DKIM aktivieren. Übersehen Sie trotzdem eine Quelle, deckt sie DMARC später auf.

Wie finden Sie heraus, wo Ihre DNS Einträge liegen?

Einträge im falschen Panel anzulegen kostet am meisten Zeit. Der Eintrag steht dort, hat aber keine Wirkung. Denn empfangende Server lesen nur die Einträge, die auf den Nameservern Ihrer Domain liegen. Maßgeblich ist also die Firma, auf die Ihre Nameserver zeigen.

Zwei Schritte genügen: Lesen Sie mit unserem DNS Abfrage Tool die NS Einträge Ihrer Domain. Prüfen Sie danach mit unserem Whois Abfrage Tool, bei welchem Registrar die Domain liegt.

In der Praxis können die Nameserver auf Ihren Registrar, Ihren Hostinganbieter oder einen eigenen DNS Dienst zeigen. Zum Beispiel läuft Ihre Website auf einem Server, während das DNS woanders liegt. Dann führt das Panel auf dem Server in die Irre, weil Empfänger es nie abfragen. Haben Sie außerdem keinen Zugang zum DNS Panel, müssen Sie ihn zuerst zurückholen.

Wie erstellen Sie einen SPF Eintrag?

Ein SPF Eintrag ist ein einzelner TXT Eintrag an der Wurzel Ihrer Domain. Er beginnt mit v=spf1, nennt die erlaubten Quellen und endet mit einer Regel. Das Beispiel aus der Google Hilfe für ein Unternehmen, das nur über Google Workspace sendet, sieht so aus:

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

Der Teil include fügt die Serverliste von Google hinzu. Zudem stuft die Regel ~all jede andere Quelle als wahrscheinlich nicht berechtigt ein. Kommt ein neuer Dienst hinzu, legen Sie keinen zweiten Eintrag an. Stattdessen ergänzen Sie ein weiteres include im selben Eintrag:

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

Hier ist service.example.com nur ein Platzhalter für den Wert, den Ihr Newsletter Tool nennt. Merken Sie sich die wichtigste Regel: Eine Domain darf genau einen SPF Eintrag haben. Denn RFC 7208 verbietet mehrere Einträge, und laut Microsoft liefert SPF in diesem Fall einen dauerhaften Fehler.

Beim Anlegen tragen Sie im Feld für den Namen (Host) meist @ ein, manche Panels verlangen stattdessen die Domain selbst. Außerdem erwarten manche Panels den Wert in Anführungszeichen, prüfen Sie dazu die Hilfe Ihres Panels.

Achten Sie auf drei Tippfehler: include= statt include:, ein Leerzeichen nach dem Doppelpunkt und ein Punkt hinter der Domain. Außerdem braucht eine Subdomain wie news.example.com einen eigenen SPF Eintrag, weil der Eintrag der Hauptdomain sie nicht abdeckt.

Was bedeutet das Limit von 10 DNS Abfragen bei SPF?

RFC 7208 begrenzt die Zahl der Begriffe, die DNS Abfragen auslösen, auf 10 pro SPF Prüfung. Der Standard zählt include, a, mx, ptr, exists und redirect. Dagegen zählen ip4, ip6 und all nicht. Deshalb liefert ein Eintrag über dem Limit einen dauerhaften Fehler (permerror), und die SPF Prüfung funktioniert nicht.

Die eigentliche Falle sind allerdings verschachtelte include Angaben. Ein include kann mehrere weitere öffnen, und jedes zählt mit. Sie sehen im Eintrag vielleicht nur drei include, dennoch liegt der Zähler weit darüber. Zudem weist auch Microsoft darauf hin, dass weniger include Angaben nicht automatisch weniger Abfragen bedeuten. Empfänger lesen den Eintrag außerdem von links nach rechts und hören auf, sobald sie den Absender gefunden haben. Daher tritt der Fehler bei manchen Empfängern nie auf, während andere Ihre Mails zurückweisen.

Kommen Sie dem Limit nahe, helfen diese Schritte:

• Löschen Sie die include Zeilen nicht mehr genutzter Dienste.
• Verlagern Sie sendestarke Dienste auf eine Subdomain, denn jede Subdomain hat ein eigenes Limit von 10.
• Dokumentiert ein Anbieter einen stabilen IP Bereich, können Sie ip4 statt include schreiben, müssen den Eintrag aber anpassen, wenn der Anbieter den Bereich ändert.
• Verwenden Sie den Begriff ptr nie, denn RFC 7208 rät von seiner Veröffentlichung ab.

Außerdem zeigt unser kostenloser SPF DKIM DMARC Check die Zahl der Abfragen als nummerierten Baum.

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

Beides ist gültig, und große Anbieter geben unterschiedliche Empfehlungen. Die Google Hilfe empfiehlt ~all (Softfail). Die Microsoft Dokumentation empfiehlt -all (Hardfail), wenn Sie zusätzlich DKIM und DMARC nutzen.

RFC 9989 nennt allerdings ein Risiko. Manche Empfänger weisen eine Nachricht schon in der SMTP Phase ab, wenn SPF scheitert, ohne DMARC zu prüfen. Somit kann eine Nachricht verloren gehen, die über eine passende DKIM Signatur DMARC bestanden hätte, und sie taucht nie in Ihren Berichten auf.

Unser praktischer Rat lautet deshalb: Bleiben Sie bei ~all, bis Sie alle Absender geprüft haben. Entscheiden Sie danach anhand der Berichte über -all. Domains mit Weiterleitungsregeln fahren mit ~all sicherer, denn weitergeleitete Mails fallen bei SPF oft durch, und -all kann sie abweisen, bevor DKIM eine Chance bekommt.

Konkret gilt bei ungenutzten Domains etwas anderes. Für eine Domain, die nie sendet, können Sie v=spf1 -all veröffentlichen, und die Microsoft Dokumentation empfiehlt das ausdrücklich. Dann kann niemand in ihrem Namen senden. Außerdem gilt ?all (neutral) nur für Tests, und Microsoft rät im Betrieb davon ab.

Wie erzeugen Sie einen DKIM Schlüssel und tragen ihn im DNS ein?

DKIM nutzt zwei Schlüssel. Das sendende System signiert jede Nachricht mit einem privaten Schlüssel, und Sie veröffentlichen den passenden öffentlichen Schlüssel im DNS. Der Empfänger prüft damit die Signatur. Das Schlüsselpaar erzeugen Sie meist im Panel Ihres Mailanbieters, deshalb richten Sie DKIM für jeden sendenden Dienst einzeln ein.

1. Öffnen Sie im Panel des sendenden Dienstes den Bereich für DKIM oder Domain Authentifizierung und wählen Sie Ihre Domain.
2. Kopieren Sie Eintragsname (Host) und Wert aus dem Panel. Google nennt zum Beispiel einen TXT Eintrag, Microsoft 365 zwei CNAME Einträge.
3. Legen Sie den Eintrag dann genau so in Ihrem DNS Panel an, ohne Text oder Zeilenumbrüche zu ändern.
4. Danach warten Sie, bis das DNS aktualisiert ist, und aktivieren oder bestätigen die Signatur im Panel.
5. Schließlich senden Sie eine Testnachricht und suchen im Header nach dkim=pass.

In der Praxis hat der Eintragsname die Form selector._domainkey.example.com. Ein Selector erlaubt einer Domain mehrere Schlüssel nebeneinander, und RFC 6376 definiert ihn, damit Sie Schlüssel leichter wechseln. Zum Beispiel heißt der Standard Selector bei Google google. Wählen Sie die längste Schlüssellänge, die Ihr Anbieter unterstützt. Laut Google sind längere Schlüssel sicherer. Beim Schlüsselwechsel veröffentlichen Sie dann einen neuen Selector und behalten den alten, bis der Wechsel abgeschlossen ist.

Wie beheben Sie einen DKIM Selector Fehler?

Der DKIM Eintrag existiert, aber das Ergebnis bleibt negativ? Dann liegt die Ursache meist am Selector, am Eintragsnamen oder am Wert. Prüfen Sie der Reihe nach:

• Selector Abgleich: Öffnen Sie den Header einer Testnachricht, suchen Sie s= und d= in der Zeile DKIM-Signature und prüfen Sie, ob das DNS einen Eintrag genau mit dem Namen s._domainkey.d enthält.
• Doppelte Domain: Manche DNS Panels hängen Ihre Domain selbst an. Tippen Sie also den vollen Namen, entsteht ein falscher Eintrag wie google._domainkey.example.com.example.com. Tragen Sie dort nur google._domainkey ein.
• Beschädigter Schlüssel: Beim Kopieren ging vielleicht das Ende des langen Werts verloren, oder Zeilenumbrüche und zusätzliche Anführungszeichen kamen hinzu. Zudem fasst eine DNS Zeichenkette höchstens 255 Zeichen, deshalb zerlegen DNS Panels lange Schlüssel in Teile. Manche Panels erledigen das selbst, andere verlangen die einzelnen Teile von Ihnen.
• Signatur ausgeschaltet: Auch bei korrektem Eintrag haben Sie die Signatur im Panel des Dienstes womöglich nie aktiviert.
• Falsche Signaturdomain: Signiert der Dienst mit seiner eigenen Domain, besteht DKIM, passt aber nicht zu Ihrer Domain.
• Doppelte Einträge: RFC 6376 erwartet pro Selector genau einen TXT Eintrag.

Nach einer Korrektur sehen Sie das Ergebnis eventuell nicht sofort, denn DNS Caches halten den alten Wert eine Weile. Ändern Sie den Eintrag deshalb nicht immer wieder. Warten Sie stattdessen ab und testen Sie danach erneut.

Wie legen Sie den DMARC Eintrag an, und was bedeutet p=none?

Ein DMARC Eintrag ist ein TXT Eintrag mit dem Namen _dmarc unter Ihrer Domain. Richten Sie zunächst eine Adresse für den Empfang der Berichte ein. Das Berichtsvolumen kann hoch sein, deshalb empfiehlt Google ein eigenes Postfach oder eine Gruppe statt einer persönlichen Adresse. Danach legen Sie den Eintrag an:

Name: _dmarc.example.com
Typ: TXT
Wert: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Der Tag v=DMARC1 muss an erster Stelle stehen. Der Tag p legt die Richtlinie fest, und rua nennt die Adresse für Aggregatberichte. Außerdem bedeutet p=none: Nachrichten nicht anfassen, nur berichten. Laut RFC 9989 darf eine p=none Richtlinie die Behandlung von Mails beim Empfänger nicht verändern.

Liegt die Berichtsadresse auf einer anderen Domain, muss diese Domain einen DNS Eintrag veröffentlichen, der den Empfang Ihrer Berichte bestätigt. Eine Adresse auf Ihrer eigenen Domain braucht diesen Schritt dagegen nicht. Warten Sie schließlich, bis sich Ihre SPF und DKIM Einträge verbreitet haben, bevor Sie DMARC ergänzen.

Was ist Alignment, und warum scheitert DMARC?

Alignment bedeutet: Die Domain, die SPF oder DKIM bestätigt, passt zur sichtbaren Absenderdomain (From). Im lockeren Modus (relaxed) müssen beide Domains nur dieselbe Hauptdomain teilen. Zum Beispiel passen news.example.com und example.com im lockeren Modus zusammen. Im strengen Modus (strict) müssen sie dagegen identisch sein. Locker ist der Standard und genügt den meisten Unternehmen.

Konkret schaut DMARC bei SPF auf die Domain des Umschlagabsenders (MAIL FROM), nicht auf den HELO Namen. Bei DKIM prüft es die Domain d= in der Signatur. Somit genügt ein Treffer mit Alignment bei einer der beiden Methoden, damit DMARC besteht.

Beispielszenario: Ein Newsletter geht von info@example.com raus. Das Newsletter Tool nutzt als Umschlagabsender seine eigene Domain und signiert ebenfalls mit seiner eigenen Domain. SPF und DKIM bestehen jeweils, doch keine der beiden Domains passt zu example.com, also scheitert DMARC.

Die Lösung ist einfach: Aktivieren Sie im Panel des Tools die Authentifizierung mit eigener Domain. Dann signiert der Dienst zusätzlich mit Ihrer Domain, und DKIM passt. Zudem signieren laut Microsoft Dokumentation viele gehostete Mail Dienste zunächst mit ihrer eigenen Domain und nach Ihrer Einrichtung erneut mit der Domain des Kunden.

Wie lesen Sie DMARC Berichte?

Aggregatberichte sind XML Dateien, die empfangende Mailsysteme an Sie schicken. Meist kommen sie als kleine komprimierte Anhänge, und Empfänger senden sie in der Regel einmal täglich. Sie können die Dateien von Hand lesen. RFC 9989 empfiehlt allerdings die maschinelle Auswertung. Dafür gibt es Auswertungstools und Dienste. Jeder Bericht enthält diese Angaben:

• Name der berichtenden Organisation und Zeitraum.
• Quell IP Adresse und Anzahl der Nachrichten von dort.
• DMARC Auswertung: Disposition sowie Ergebnisse für DKIM und SPF mit Alignment.
• Sichtbare Absenderdomain (From).
• Rohergebnisse der Authentifizierung: DKIM Domain, Selector und Ergebnis, SPF Domain und Ergebnis.

Gruppieren Sie die Quellen zunächst nach IP Adresse oder Dienst. Lassen Sie dann bekannte, bestehende Quellen in Ruhe. Beheben Sie anschließend bekannte Quellen mit Fehlern über das Alignment. Beobachten Sie zuletzt unbekannte Quellen mit hohem Volumen, denn dahinter kann Missbrauch stecken.

Fehlerberichte (Failure Reports) sind ein eigenes Thema. Gmail unterstützt sie nicht, und die meisten Empfänger senden sie aus Datenschutzgründen nicht. Zudem können selbst Aggregatberichte bei kleinen Unternehmen Sendegewohnheiten verraten. Legen Sie deshalb fest, wer auf das Berichtspostfach zugreifen darf. Taucht eine Frage zum Datenschutz (DSGVO) auf, ist dieser Beitrag keine Rechtsberatung, und Sie sollten eine Fachperson fragen.

Wie stellen Sie DMARC auf quarantine und reject um?

Gehen Sie nicht überstürzt vor. Folgen Sie dieser Reihenfolge:

1. Starten Sie mit p=none und rua und sammeln Sie Berichte.
2. Beobachten Sie die Berichte, bis jede legitime Quelle mit Alignment besteht.
3. Beheben Sie jede legitime Quelle ohne Alignment.
4. Stellen Sie bei sauberen Berichten auf p=quarantine um und beobachten Sie weiter.
5. Wechseln Sie nur dann auf p=reject, wenn Sie es brauchen und die Wirkung verstehen.

Wie lange das dauert, hängt von Ihrer Versandhäufigkeit ab. RFC 9989 nennt für manche Domains mehrere Monate. Wir geben deshalb keinen Zeitplan vor, denn das Maß sind saubere Berichte, nicht die verstrichene Zeit.

Manche Anbieterdokumente beschreiben für einen schrittweisen Wechsel den Tag pct. RFC 9989 entfernt diesen Tag allerdings und führt stattdessen einen Tag t für Tests ein. Welche Variante Empfänger unterstützen, kann abweichen, daher lohnt der Blick in die aktuelle Dokumentation Ihres Anbieters.

Außerdem haben es Domains leicht, die nie Mails senden: Veröffentlichen Sie v=spf1 -all und setzen Sie DMARC auf p=reject.

Ist p=reject für jedes Unternehmen richtig?

Nicht immer. RFC 9989 warnt, dass p=reject indirekte Mailwege stören kann, etwa Mailinglisten, Rollenadressen mit Weiterleitung und Weiterleitungsregeln. Der Grund ist einfach: Weiterleitungen brechen SPF häufig, während DKIM gültig bleibt, wenn sich die Nachricht nicht ändert.

Der Standard macht zwei klare Aussagen:

• Erstens darf sich eine Domain mit p=reject nicht allein auf SPF verlassen, und sie muss ihre Nachrichten mit gültigem DKIM signieren.
• Zweitens sollte eine Domain, deren Nutzer an Mailinglisten schreiben könnten, p=reject nicht veröffentlichen. Will sie es dennoch, empfiehlt RFC 9989 mindestens einen Monat p=none und danach einen gleich langen Zeitraum p=quarantine, um die Wirkung zu messen.

Kurz gesagt kann eine Domain, die nur Bestellbestätigungen, Formulare und Newsletter versendet, reject erwägen. Eine Domain für allgemeine Mails, von der Mitarbeitende an öffentliche Listen schreiben, ist dagegen oft mit quarantine besser bedient. Entscheiden Sie anhand Ihrer Berichte.

SPF DKIM DMARC einrichten bei Google Workspace: Wie gehen Sie vor?

Bei Google Workspace erledigen Sie zwei der drei Einträge vollständig im DNS. Die Admin Konsole bietet für SPF und DMARC keine Einstellung, deshalb legen Sie diese Einträge dort an, wo Sie Ihre Domain verwalten. DKIM beginnt dagegen in der Konsole. Haben Sie die Domain über einen Google Partner gekauft, existieren manche Einträge schon. Prüfen Sie daher zuerst den Bestand.

1. SPF: Senden Sie nur über Google, veröffentlichen Sie v=spf1 include:_spf.google.com ~all im DNS. Haben Sie weitere Absender, ergänzen Sie sie im selben Eintrag.
2. DKIM: Öffnen Sie in der Admin Konsole den Bereich für die E-Mail Authentifizierung in den Gmail Einstellungen, wählen Sie Ihre Domain und erzeugen Sie einen neuen Eintrag. Der Standard Selector ist google.
3. Tragen Sie dann Eintragsname und Wert aus der Konsole im DNS ein. Der Name lautet google._domainkey, der Wert beginnt mit v=DKIM1; k=rsa; p=.
4. Sobald sich der Eintrag verbreitet hat, starten Sie die Authentifizierung im selben Bereich.
5. DMARC: Legen Sie den _dmarc Eintrag aus dem vorigen Abschnitt mit p=none an.

Testen Sie nicht mit einer Mail an sich selbst, denn laut Google lässt sich DKIM so nicht bestätigen. Senden Sie stattdessen an eine andere Gmail oder Workspace Adresse. Haben Sie Gmail gerade erst aktiviert, kann es zudem dauern, bis der DKIM Schlüssel in der Konsole erscheint. Die Details nennt die Google Workspace Hilfe zu DKIM. Haben Sie sich noch nicht für einen Anbieter entschieden, lesen Sie unseren Vergleich Google Workspace oder Microsoft 365.

SPF DKIM DMARC einrichten bei Microsoft 365: Welche Schritte brauchen Sie?

Bei Microsoft 365 verwalten weder das Admin Portal noch PowerShell die SPF und DMARC Einträge eigener Domains. Beide Einträge legen Sie bei Ihrem Registrar oder DNS Dienst an. DKIM läuft dagegen in zwei Stufen.

1. SPF: Senden Sie nur über Microsoft 365, veröffentlichen Sie v=spf1 include:spf.protection.outlook.com -all im DNS. Microsoft nutzt im Beispiel -all, diese Wahl haben wir im SPF Abschnitt besprochen. Weitere Absender ergänzen Sie im selben Eintrag.
2. DKIM: Die Signatur für eigene Domains startet nicht von selbst. Öffnen Sie im Microsoft Defender Portal die Einstellungen zur E-Mail Authentifizierung, wechseln Sie zum Reiter DKIM und wählen Sie Ihre Domain.
3. Das Portal zeigt zwei CNAME Einträge: selector1._domainkey und selector2._domainkey. Kopieren Sie die Zielwerte exakt und tragen Sie sie im DNS ein.
4. Dann schalten Sie die Signatur ein, sobald das Portal die Einträge erkennt.
5. DMARC: Legen Sie den _dmarc Eintrag mit p=none im DNS an.

Raten Sie die Zielwerte nicht, denn laut Microsoft kann das Format der CNAME Ziele bei neu hinzugefügten Domains von älteren abweichen. Die Beispiele der Dokumentation dienen zudem nur der Veranschaulichung. Die Details nennt die Microsoft Learn Seite zu DKIM. Denken Sie außerdem daran, dass jede sendende Subdomain eine eigene DKIM Einrichtung braucht.

SPF DKIM DMARC einrichten bei cPanel und Hostinganbietern: Was ist zu beachten?

Läuft Ihre Website auf einem cPanel Server, bietet das Panel womöglich die Ansicht Email Deliverability. Sie zeigt den Status von SPF, DKIM und DMARC Ihrer Domains und schlägt für fehlerhafte Einträge einen Wert vor. Eine Reparaturfunktion kann den vorgeschlagenen Eintrag zum Beispiel direkt anlegen. Ob diese Ansicht verfügbar ist, entscheidet allerdings Ihr Hostinganbieter.

Entscheidend ist: Die Einträge wirken nur, wenn der Server der autoritative Nameserver Ihrer Domain ist. Das stellt die cPanel Dokumentation zu Email Deliverability klar. Sonst bleibt der Eintrag lokal auf dem Server und hat keine Wirkung. Kopieren Sie den vorgeschlagenen Eintrag dann und legen Sie ihn dort an, wo Ihr DNS liegt.

Mischformen sind in der Praxis häufig. Ihre Postfächer liegen zum Beispiel bei Google Workspace, während Ihre Website auf einem cPanel Server läuft. Dann senden Ihre Formulare vom Server, und Ihr SPF Eintrag muss beide Quellen enthalten. Der Reverse DNS Eintrag der Server IP ist Sache Ihres Hostinganbieters; unser Beitrag zum PTR Eintrag erklärt ihn.

Wir sind kein Hosting oder E-Mail Anbieter. Wir richten Website und geschäftliche E-Mail bei Google Workspace, Microsoft 365 oder Ihrem Hostinganbieter ein, ziehen sie um und betreuen sie.

Wie authentifizieren Sie Newsletter Tools, CRM und Webformulare?

Dienste von Drittanbietern senden in Ihrem Namen, daher braucht jeder eine eigene Einrichtung. Newsletter und CRM Tools haben im Panel meist einen Bereich für die Domain Authentifizierung. Dort nennt der Dienst Ihnen DKIM Einträge und fragt manchmal nach einer eigenen Umschlagabsender Domain. Tragen Sie diese Einträge im DNS ein, signiert der Dienst mit Ihrer Domain, und das Alignment folgt. Ergänzen Sie ein SPF include allerdings nur, wenn die Hilfeseite des Dienstes es verlangt.

Microsoft empfiehlt für Massenversand Dienste, die Sie nicht kontrollieren, eine Subdomain statt der Hauptdomain. Zum Beispiel schützt news.example.com den Ruf Ihrer Hauptdomain. Außerdem hat jede Subdomain ein eigenes Limit von 10 Abfragen.

Webformulare sind eine eigene Falle. Formulare senden oft über die Mailfunktion des Servers, also kommen sie aus einer Quelle, die Ihr SPF Eintrag nicht nennt. Sicherer geht es so: Tragen Sie im Feld From eine Adresse Ihrer Domain ein, setzen Sie die Adresse des Besuchers in Reply-To und senden Sie über ein authentifiziertes SMTP Konto Ihres Mailanbieters. Nutzen Sie WordPress, führt Sie unsere Anleitung zum WordPress Mailversand durch die Schritte.

Wie testen Sie Ihre Einrichtung von SPF, DKIM und DMARC?

Die Einträge anzulegen ist nur die halbe Arbeit. Das echte Ergebnis sehen Sie im Test. Gehen Sie so vor:

1. Geben Sie Ihre Domain in unserem SPF DKIM DMARC Check ein. Er zeigt den SPF Abfragebaum, die DKIM Selectoren und die DMARC Richtlinie. Kennen Sie Ihren Selector nicht, lassen Sie das Feld leer, dann prüft das Tool gängige Selectoren.
2. Nutzen Sie das DNS Abfrage Tool, um die Roheinträge zu sehen. Fragen Sie für DKIM zusätzlich selector._domainkey.example.com ab und prüfen Sie die Hostnamen.
3. Senden Sie dann von jedem Dienst eine echte Nachricht an eine andere Gmail Adresse. Testen Sie Formular, Newsletter Tool und CRM getrennt.
4. Öffnen Sie die Nachricht in Gmail und wählen Sie Original anzeigen. Suchen Sie dort nach pass für SPF, DKIM und DMARC.
5. Fügen Sie den Header in den Check ein, dann zeigt er auch das Alignment.

Entspricht das Ergebnis nicht Ihrer Erwartung, ändern Sie den Eintrag nicht sofort. Denn DNS Änderungen hängen vom TTL Wert ab (so lange darf ein Cache den Eintrag behalten) und vom Cache des Empfängers. Zudem nennt auch die Google Hilfe, dass Einträge Zeit brauchen, bis sie aktiv sind. Warten Sie also ab und testen Sie erneut.

Welche Fehler passieren beim Einrichten von SPF, DKIM und DMARC am häufigsten?

Die Tabelle zeigt die Fehler, die uns in der Praxis am häufigsten begegnen, mit Symptomen und Lösungen.

Die meisten dieser Fehler verletzen wenige Grundregeln: ein SPF Eintrag, exakte Hostnamen und DKIM für jeden Absender.

Was prüfen Sie nach der Einrichtung, und wann holen Sie Hilfe?

Eine Einrichtung erledigen Sie nicht einmal und vergessen sie dann. Einträge veralten, wenn Sie einen Dienst hinzufügen oder den Anbieter wechseln. Gehen Sie deshalb regelmäßig diese Checkliste durch:

• Ist die Liste Ihrer sendenden Dienste aufgeschrieben und aktuell?
• Hat die Domain genau einen SPF Eintrag mit weniger als 10 Abfragen?
• Besteht DKIM bei jedem Dienst und passt es zu Ihrer Domain?
• Lesen Sie Ihre DMARC Berichte regelmäßig?
• Haben Sie include und DKIM Einträge nicht mehr genutzter Dienste gelöscht?
• Tragen Domains, die nie senden, v=spf1 -all?

Sie können diese Kontrolle zum Beispiel in Ihre monatliche Checkliste zur Website Wartung aufnehmen. Beim Anbieterwechsel erinnert Sie zudem unser Leitfaden zum Umzug Ihrer geschäftlichen E-Mail daran, diese Einträge nicht zu vergessen.

Bei mehreren Domains oder fehlendem DNS Zugang spart fachliche Hilfe Zeit, wenn Sie SPF DKIM DMARC einrichten oder DMARC auf reject anheben wollen. Fordern Sie ein Angebot für die Einrichtung oder den Umzug von Website und geschäftlicher E-Mail an.