SPF, DKIM und DMARC einrichten: Die praktische Schritt-für-Schritt-Anleitung für Ihre Domain

Wer SPF, DKIM und DMARC einrichten möchte, muss dafür im Kern nur einige TXT-Records im DNS der eigenen Domain anlegen – die Herausforderung liegt weniger in der Technik selbst als in der richtigen Reihenfolge und ein paar Stolperfallen, die bei falscher Syntax dazu führen, dass legitime Mails plötzlich im Spam-Ordner landen oder gar nicht mehr zugestellt werden. Dieser Beitrag zeigt Schritt für Schritt, wie Sie die drei Mechanismen korrekt konfigurieren. Wer den konzeptionellen Hintergrund zu den drei Verfahren nachlesen möchte, findet ihn im Grundlagenartikel DMARC, SPF & DKIM: E-Mail-Authentifizierung.

SPF einrichten

SPF (Sender Policy Framework, RFC 7208) legt per TXT-Record am Domain-Root fest, welche Server im Namen Ihrer Domain Mails versenden dürfen.

1. Ermitteln Sie zunächst vollständig, welche Systeme in Ihrem Namen versenden: der eigene Mailserver, Microsoft 365 oder Google Workspace, aber auch Newsletter-Tools, CRM-Systeme oder Portale, die Bestätigungsmails verschicken.
2. Prüfen Sie den aktuell gesetzten Record per Kommandozeile: dig TXT ihredomain.de. Es darf nur ein einziger SPF-TXT-Record je Domain existieren – mehrere SPF-Records führen zu einem PermError und damit zu SPF-Fehlschlägen.
3. Stellen Sie den Record aus den ermittelten Quellen zusammen. Beispiel für Microsoft 365: v=spf1 mx include:spf.protection.outlook.com -all. Beispiel für Google Workspace: v=spf1 include:_spf.google.com ~all.
4. Legen Sie den Record als TXT-Eintrag am Domain-Root (Host @) im DNS Ihres Providers an.
5. Beachten Sie das Lookup-Limit nach RFC 7208: Ein SPF-Record darf maximal 10 DNS-Lookups (durch include, mx, a, exists, ptr) auslösen. Verkettete includes verschiedener Dienstleister überschreiten dieses Limit in der Praxis sehr schnell und führen dann ebenfalls zu einem PermError, wodurch die gesamte SPF-Prüfung fehlschlägt – ein häufiger, aber leicht übersehener Fehler.
6. Warten Sie die DNS-Propagation ab und verifizieren Sie den Record erneut mit dig TXT ihredomain.de.

Der Unterschied zwischen -all und ~all ist dabei entscheidend: -all (hard fail) weist empfangende Server an, Mails von nicht gelisteten Servern konsequent abzulehnen. ~all (soft fail) markiert solche Mails lediglich als verdächtig, blockiert sie aber nicht zwingend. In der Einführungsphase ist ~all die vorsichtigere Wahl, produktiv sollte nach erfolgreicher Prüfung auf -all umgestellt werden.

DKIM einrichten

DKIM (DomainKeys Identified Mail, RFC 6376) signiert ausgehende Mails kryptografisch mit einem privaten Schlüssel; der öffentliche Gegenpart wird als TXT-Record unter <selector>._domainkey.<domain> veröffentlicht.

1. Aktivieren Sie DKIM im Admin-Center Ihres E-Mail-Anbieters. Der exakte Selector-Name und der zu veröffentlichende Record werden dort vorgegeben – bei Microsoft 365 typischerweise als CNAME-Einträge (z. B. selector1._domainkey und selector2._domainkey), bei Google Workspace als einzelner TXT-Record unter einem selbst gewählten Selector. Diese Werte sind je Anbieter unterschiedlich und dürfen nicht frei erfunden werden.
2. Legen Sie den vom Anbieter bereitgestellten Record exakt wie vorgegeben im DNS an.
3. Bestätigen Sie die Aktivierung im Admin-Center, sobald der DNS-Eintrag propagiert ist – bei M365 etwa über den Schalter „DKIM aktivieren“ im Exchange Admin Center.
4. Verifizieren Sie den veröffentlichten Record: dig TXT selector._domainkey.ihredomain.de, wobei Sie „selector“ durch den tatsächlich vergebenen Selector-Namen ersetzen.

DMARC einrichten

DMARC (RFC 7489) baut auf SPF und DKIM auf und legt unter _dmarc.<domain> als TXT-Record fest, wie Empfänger mit Mails umgehen sollen, die beide Prüfungen nicht bestehen.

1. Legen Sie zunächst einen reinen Beobachtungs-Record an: v=DMARC1; p=none; rua=mailto:dmarc-reports@ihredomain.de; pct=100. In dieser Phase wird keine Mail blockiert, Sie erhalten lediglich tägliche Aggregatberichte der großen Empfänger (Google, Microsoft und andere) an die angegebene Adresse.
2. Werten Sie die Reports über mehrere Wochen aus. Die Berichte kommen als XML zurück; ein DMARC-Report-Analyse-Tool erleichtert die Auswertung, indem es zeigt, welche Quellen im Namen Ihrer Domain senden und ob diese SPF und DKIM korrekt bestehen.
3. Erst wenn alle legitimen Versandquellen sauber durchlaufen, verschärfen Sie die Policy schrittweise, zunächst mit reduziertem Prozentsatz: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@ihredomain.de, und erhöhen pct nach weiterer Beobachtung sukzessive auf 100.
4. Erst wenn auch p=quarantine über einen längeren Zeitraum keine unerwarteten Zustellprobleme mehr verursacht, stellen Sie final auf p=reject um.

Rollout-Reihenfolge

Die international anerkannte Best Practice ist ein gestaffelter Rollout in drei Stufen: p=none zum reinen Sammeln von Daten ohne jede Auswirkung auf die Zustellung, danach p=quarantine, sobald alle legitimen Absender identifiziert und in SPF beziehungsweise DKIM korrekt abgebildet sind, und erst zuletzt p=reject, wenn die Reports über einen ausreichenden Zeitraum keine Auffälligkeiten mehr zeigen. Ein direkter Start mit p=reject ist keine Abkürzung, sondern ein verbreiteter Fehler: Er führt in aller Regel dazu, dass legitime Mails aus vergessenen Quellen – etwa einem Newsletter-Tool oder einer Fachanwendung – kommentarlos verworfen werden, ohne dass Absender oder Empfänger davon erfahren.

Häufige Fehler

• Mehrere SPF-TXT-Records für dieselbe Domain, statt aller Quellen in einem einzigen Record zusammengefasst.
• Zu viele verkettete include-Anweisungen, wodurch das SPF-Lookup-Limit von 10 nach RFC 7208 überschritten wird und die Prüfung komplett fehlschlägt.
• DKIM-Record im DNS angelegt, aber die Aktivierung im Admin-Center des Mailanbieters vergessen – ohne diesen Schritt wird trotz korrektem Record nicht signiert.
• Direkter Einstieg mit p=reject ohne vorherige Beobachtungsphase über p=none und p=quarantine.
• Fehlende oder falsche rua-Adresse im DMARC-Record, sodass Reports ins Leere laufen und niemand die Auswirkungen der Policy überwacht.
• DNS-Änderungen nicht verifiziert – der Record wurde gespeichert, aber nie mit dig oder einem vergleichbaren Werkzeug auf korrekte Propagation geprüft.

Häufige Fragen

Wie lange dauert es, bis SPF, DKIM und DMARC vollständig wirken?

Die einzelnen DNS-Änderungen sind je nach TTL meist innerhalb weniger Stunden aktiv. Für DMARC empfiehlt sich jedoch eine Beobachtungsphase von mehreren Wochen je Rollout-Stufe, damit alle legitimen Versandquellen zuverlässig erfasst werden, bevor die Policy verschärft wird.

Was passiert, wenn mein SPF-Record das Lookup-Limit überschreitet?

Überschreitet ein SPF-Record die nach RFC 7208 zulässigen 10 DNS-Lookups, liefert die Prüfung einen PermError. Viele Empfänger werten das wie ein Fehlschlagen der SPF-Prüfung, wodurch auch Mails von eigentlich autorisierten Servern nicht mehr korrekt bewertet werden.

Brauche ich wirklich alle drei Mechanismen gleichzeitig?

SPF und DKIM sind die technische Grundlage und sollten beide vorhanden sein, da DMARC ohne mindestens eine bestandene Prüfung nicht sinnvoll greift. DMARC selbst ist die Steuerungsebene darüber und macht erst sichtbar, ob SPF und DKIM in der Praxis konsistent funktionieren – für einen wirksamen Schutz vor Domain-Spoofing sind daher alle drei Bausteine gemeinsam erforderlich.

Wenn Sie die Umsetzung lieber begleitet angehen möchten oder die Auswertung der DMARC-Reports intern nicht abgebildet werden kann, unterstützt netzorange Sie dabei – nehmen Sie gerne Kontakt zu uns auf.