SPF, DKIM und DMARC einrichten: E-Mail-Authentifizierung im DNS aufbauen und testen

1. Jeden Versanddienst in einer Übersicht erfassen

MX-Einträge legen fest, an welche Server eingehende Mail für eine Domain zugestellt wird. Ausgehende Mail nimmt eigene Wege. Ein Unternehmen empfängt zum Beispiel über seinen Postfachanbieter, verschickt Rechnungen aber aus dem Shopsystem, Supportantworten aus dem Ticketsystem und Newsletter über einen spezialisierten Dienst.

Legen Sie deshalb eine Absenderliste an, mit einer Zeile pro Dienst. Notieren Sie die sichtbare Absenderadresse (From), die Domain des Envelope-Absenders, die Domain, mit der DKIM signiert wird, die verantwortliche Person und eine echte Beispielnachricht. Diese drei Domains dürfen sich durchaus unterscheiden; die Liste macht nachvollziehbar, welche zu welchem Dienst gehört. Halten Sie die genaue Maildomain neben dem Hostnamen der Website fest, denn example.com, www.example.com und news.example.com haben jeweils eigene DNS-Einträge. Besonders nützlich wird die Liste, wenn ein neuer Dienst hinzukommt oder die Zuständigkeit wechselt.

Auch Domains, die gar keine Mail verschicken, etwa reservierte Tippfehlervarianten oder alte Kampagnendomains, gehören in die Liste. Die Technische Richtlinie TR-03182 des BSI verlangt für solche Domains einen Null-MX-Eintrag, eine SPF-Richtlinie, die keinen Server autorisiert (v=spf1 -all), und eine DMARC-Richtlinie mit p=reject, die Sammelberichte anfordert. Damit erklärt die Domain öffentlich, dass sie weder Mail annimmt noch legitime Mail verschickt.

2. Verstehen, was jedes Verfahren beiträgt

Jedes Verfahren beantwortet eine andere Frage. SPF und DKIM authentifizieren jeweils eine Domain, aber nicht zwingend die, die im Absenderfeld steht. Erst DMARC stellt die Verbindung zur sichtbaren From-Domain her. TLS schützt den Transport zwischen den Mailservern, DKIM macht dagegen Änderungen am signierten Inhalt erkennbar. Wer diese Rollen auseinanderhält, kann die technischen Header einer zugestellten Nachricht deutlich leichter lesen.

3. SPF an den echten Versandwegen ausrichten

SPF prüft, ob der einliefernde Mailserver für die Domain des Envelope-Absenders (MAIL FROM) senden darf, nicht für die Adresse im sichtbaren From-Feld. Die Richtlinie steht als TXT-Eintrag im DNS und beginnt mit v=spf1. Über include bindet sie die veröffentlichte Konfiguration eines Anbieters ein, die ihrerseits auf weitere Einträge verweisen kann. Die SPF-Spezifikation begrenzt die Terme, die DNS-Abfragen auslösen (include, a, mx, ptr, exists und redirect), auf insgesamt zehn pro Auswertung, verschachtelte Einbindungen eingeschlossen; ip4, ip6 und all zählen nicht mit. Wird die Grenze überschritten, endet die Prüfung mit dem Ergebnis permerror. Für Abfragen ohne Ergebnis, sogenannte Void Lookups, sieht die Spezifikation eine Grenze von zwei vor. Zählen Sie die Abfragen deshalb nach, sobald ein Anbieter seine Einbindungen ändert oder ein neuer Dienst hinzukommt.

Pro Name darf es nur eine SPF-Richtlinie geben; zwei Einträge mit v=spf1 führen ebenfalls zu einem permerror. Nehmen Sie neue Dienste deshalb nach deren Dokumentation in diesen einen Eintrag auf. Das Ende der Richtlinie verdient eine bewusste Entscheidung. ~all (Softfail) ist eine schwache Aussage, auf die Empfänger allein keine Ablehnung stützen sollen. -all (Fail) erklärt nicht aufgeführte Server ausdrücklich für nicht autorisiert; was der Empfänger daraus macht, entscheidet er selbst. +all erlaubt jedem Server im Internet, für die Domain zu senden, und nimmt SPF damit jede Wirkung. Die TR-03182 des BSI verlangt, dass Nachrichten nicht autorisierter Server bei einer sendenden Domain entweder Softfail oder Fail ergeben, niemals Pass oder Neutral.

Eine Nebenwirkung von -all beschreibt die neue DMARC-Spezifikation RFC 9989: Manche Empfänger prüfen SPF schon früh in der SMTP-Sitzung und lehnen bei einem Fail ab, bevor DMARC überhaupt ausgewertet wird. Das kann auch Nachrichten treffen, die dank einer gültigen DKIM-Signatur mit passender Domain DMARC bestanden hätten. Solche Ablehnungen tauchen in keinem DMARC-Sammelbericht auf, weil die Sitzung vorher abbricht. Prüfen Sie bei jeder Änderung an einem Dienst seine Abhängigkeiten und aktualisieren Sie Absenderliste und DNS im selben Schritt.

Wie Sie die SPF- und DMARC-Einträge Ihrer Domain mit dig oder nslookup abfragen und Term für Term lesen, zeigt der SPF- und DMARC-Check.

4. Signaturen, Alignment und Berichte zusammenführen

DKIM ergänzt SPF um eine Signatur. Der versendende Dienst signiert ausgewählte Header und den Inhalt der Nachricht; den passenden öffentlichen Schlüssel veröffentlicht die Domain im DNS unterhalb von _domainkey, zum Beispiel unter selector1._domainkey.example.com. Aktivieren Sie die DKIM-Signatur bei Ihrem Anbieter und veröffentlichen Sie die vorgegebenen Selektor-Einträge. Nach RFC 8301 müssen RSA-Schlüssel mindestens 1024 Bit lang sein, empfohlen sind mindestens 2048 Bit; rsa-sha1 ist nicht mehr zulässig. Senden Sie danach eine echte Nachricht und lesen Sie beim Empfänger den Header Authentication-Results. Er zeigt, wie das empfangende System die Nachricht tatsächlich bewertet hat.

Die aktuelle DMARC-Spezifikation ist RFC 9989 vom Mai 2026. Sie ersetzt RFC 9091 und RFC 7489, das nur als informatives Dokument außerhalb des IETF-Standardprozesses erschienen war. Der Eintrag liegt weiterhin unter _dmarc.example.com und beginnt mit v=DMARC1. Eine Nachricht besteht DMARC, wenn SPF oder DKIM besteht und die dabei geprüfte Domain zur sichtbaren From-Domain passt. Diese Übereinstimmung heißt Alignment, und eines der beiden Verfahren genügt. Standardmäßig ist das Alignment „relaxed“: Beide Domains müssen nur dieselbe Organisationsdomain haben. Das BSI empfiehlt in TR-03182 dagegen strenges Alignment, also eine exakte Übereinstimmung.

Die Richtlinie p=none dient als Beobachtungsphase: Empfänger wenden weiter ihre eigenen Filter an, und die über rua angeforderten Sammelberichte (Aggregate Reports) zeigen, welche Quellen in Ihrem Namen senden und mit welchem Ergebnis. Nutzen Sie sie, um den normalen Versand zu verstehen, legitime Dienste zu bestätigen und die nächsten Schritte bewusst zu wählen. Das Tag pct gibt es in RFC 9989 nicht mehr; stattdessen bittet t=y die Empfänger, eine Stufe milder vorzugehen als veröffentlicht, also reject wie quarantine und quarantine wie none zu behandeln. Nach Auffassung des BSI enthalten DMARC-Berichte personenbezogene Daten und müssen deshalb innerhalb der EU verarbeitet werden. Das spielt eine Rolle, wenn Sie einen externen Dienst mit der Auswertung beauftragen.

Wie streng die Richtlinie am Ende sein soll, hängt von Ihren Versandwegen ab. Domains, deren Nutzer an Mailinglisten schreiben, sollen nach RFC 9989 kein p=reject veröffentlichen. Wer es trotzdem anstrebt, soll die Auswirkungen zuerst mindestens einen Monat mit p=none und danach ebenso lange mit p=quarantine anhand der Sammelberichte beobachten. Empfänger wiederum dürfen Nachrichten nicht allein wegen p=reject ablehnen. Das BSI erwartet in TR-03182 dagegen quarantine oder reject und empfiehlt sendenden Domains reject als Ziel. Beide Positionen haben ihre Gründe; entscheiden Sie anhand Ihrer Berichte und halten Sie die Begründung fest. Wer p=reject veröffentlicht, muss laut RFC 9989 mit DKIM signieren und darf sich nicht allein auf SPF verlassen, weil Weiterleitungen SPF-Prüfungen scheitern lassen.

5. Zertifikate und Mailtransport aufeinander abstimmen

CAA-Einträge legen fest, welche Zertifikatsaussteller (CAs) für eine Domain Zertifikate ausstellen dürfen. Öffentliche CAs müssen sie vor jeder Ausstellung prüfen. Dabei gilt der Eintrag, der dem angefragten Namen am nächsten liegt: Ein CAA-Eintrag auf example.com gilt auch für www.example.com, solange die Subdomain keinen eigenen hat. Ein fehlender Eintrag ist zulässig; dann schränkt das DNS die Wahl der CA schlicht nicht ein. Tragen Sie die CAs ein, die Website, CDN und weitere Dienste tatsächlich nutzen, auch für die automatische Erneuerung, und gleichen Sie den Eintrag mit Ihrer Zertifikatsübersicht ab. Die CAA-Spezifikation erklärt, wie diese Erlaubnis im DNS ausgedrückt wird. Zwei Grenzen sollten Sie kennen: CAA verhindert keine Fehlausstellung durch eine CA, die Sie selbst erlaubt haben, und Browser werten CAA bei der Zertifikatsprüfung nicht aus.

MTA-STS betrifft dagegen die eingehende Mail Ihrer Domain. Mit der MTA-STS-Spezifikation teilt eine empfangende Domain sendenden Servern mit, dass sie nur zustellen sollen, wenn die MX-Server TLS mit einem vertrauenswürdigen Zertifikat anbieten. Dazu gehören drei Teile: ein TXT-Eintrag unter _mta-sts.example.com, eine Richtliniendatei unter https://mta-sts.example.com/.well-known/mta-sts.txt, die den Modus enforce, testing oder none festlegt, sowie die dort genannten MX-Server mit passender TLS-Konfiguration. Der TXT-Eintrag allein genügt nicht; was gelten soll, steht in der Richtliniendatei. Pflegen Sie die drei Teile deshalb gemeinsam und dokumentieren Sie sie neben Ihren Zertifikaten.

6. Den fertigen Aufbau mit echten Nachrichten prüfen

Sichern Sie vor einer geplanten DNS-Änderung die bestehenden Einträge und notieren Sie den autoritativen DNS-Anbieter sowie die TTL. Prüfen Sie nach der Veröffentlichung sowohl die Antwort des autoritativen Nameservers als auch die eines externen Resolvers. Planen Sie die nächste Beobachtung nach Ablauf der TTL ein, denn bis dahin können Resolver noch die alte Antwort aus ihrem Cache liefern.

1. Senden Sie aus jedem Dienst in der Absenderliste eine typische Nachricht.
2. Prüfen Sie den Empfang und den Header Authentication-Results.
3. Notieren Sie die Ergebnisse für SPF, DKIM und DMARC samt Alignment.
4. Gleichen Sie die Beobachtungen mit den Sammelberichten ab und aktualisieren Sie die Zuständigkeiten.

Prüfen Sie die Domain, die tatsächlich im From-Feld steht, nicht nur den Namen der Website. Hat eine Subdomain keinen eigenen DMARC-Eintrag, suchen Empfänger nach RFC 9989 per „DNS Tree Walk“ weiter oben im Namensbaum. Ein fehlender Eintrag auf www.example.com heißt also nicht automatisch, dass die Domain ohne DMARC dasteht.

Testen Sie mit den Nachrichtentypen, die Ihr Unternehmen wirklich verschickt: Rechnungen, Supportantworten, Kontobenachrichtigungen. Empfängerkonten bei verschiedenen Postfachanbietern machen die Prüfung aussagekräftiger. Bewahren Sie zu jedem Versandweg ein datiertes Beispiel auf, damit auch später nachvollziehbar bleibt, wie die Konfiguration gedacht ist. So wird aus DNS-Pflege eine wiederholbare Routine.

Um die SPF-, DMARC-, MTA-STS- und CAA-Einträge einer Domain gleich jetzt abzufragen, nutzen Sie den kostenlosen SPF- und DMARC-Checker.

7. Die Identität Ihrer Domain an einer Stelle dokumentieren

Führen Sie Absenderliste, DNS-Einträge, erlaubte Zertifikatsaussteller und Beispielnachrichten an einer Stelle zusammen. Einen ersten Blick von außen liefert der kostenlose Snapshot von Sitelemetry: Er führt ohne Anmeldung acht passive Prüfungen an einer öffentlichen Adresse aus, darunter SPF, DMARC und CAA für den eingegebenen Hostnamen, und ist kein Penetrationstest. DKIM gehört nicht dazu; dafür bleibt der Blick in den Header einer echten Nachricht. Weiter geht es mit dem Leitfaden zu SSL/TLS und Security-Headern für die Verbindung zur Website oder mit dem Leitfaden zu Website-Integrationen für angebundene Geschäftsdienste.