SPF- und DMARC-Check: Einträge abfragen, lesen und Fehler beheben

Was SPF, DKIM und DMARC jeweils prüfen

SPF und DKIM können beide für eine Domain bestehen, die der Leser nie zu sehen bekommt. DMARC schließt diese Lücke mit dem Alignment: Eine Nachricht besteht, wenn SPF oder DKIM für eine Domain besteht, die zur From-Domain passt; ein passendes Ergebnis genügt. Beim standardmäßigen Relaxed-Alignment reicht dieselbe Organisationsdomain, bounce.example.com passt also zu example.com. Strict-Alignment verlangt eine exakte Übereinstimmung; das BSI empfiehlt in TR-03182 diese strenge Variante.

Ein hypothetischer Newsletter-Dienst zeigt, warum das wichtig ist. Er versendet als news@example.com, nutzt als Envelope-Absender aber seine eigene Bounce-Domain bei example.net. SPF besteht für example.net, das nicht zur From-Domain passt; DMARC besteht also nur, wenn der Dienst per DKIM mit d=example.com signiert.

So fragen Sie die Einträge mit dig oder nslookup ab

Mehr als dig (Linux, macOS) oder nslookup (Windows) brauchen Sie nicht:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

Der SPF-Eintrag ist der TXT-Eintrag, der mit v=spf1 beginnt; daneben stehen oft Verifizierungs-Tokens anderer Dienste. Der DMARC-Eintrag ist der TXT-Eintrag unter _dmarc, der mit v=DMARC1 beginnt. Prüfen Sie SPF für die Domain des Envelope-Absenders, die von der From-Domain abweichen kann; der Header Return-Path einer zugestellten Nachricht zeigt sie.

DKIM-Schlüssel lassen sich von außen nicht auflisten, weil jeder unter einem eigenen Selektor liegt. Lesen Sie die Werte s= und d= im Header DKIM-Signature einer Nachricht, die Sie verschickt haben, und fragen Sie dann genau diesen Namen ab, zum Beispiel dig +short TXT s1._domainkey.example.com.

Nach einer Änderung können Resolver noch die alte Antwort liefern, bis deren TTL abgelaufen ist. Um zu sehen, was jetzt veröffentlicht ist, ermitteln Sie die autoritativen Nameserver mit dig +short NS example.com und fragen einen davon direkt: dig +short TXT example.com @ns1.example.net. Schicken Sie danach eine echte Nachricht an ein Postfach, das Sie selbst kontrollieren, und lesen Sie den Header Authentication-Results. Er zeigt, wie der Empfänger SPF, DKIM und DMARC bewertet hat, und genau dieses Ergebnis zählt.

So lesen Sie einen SPF-Eintrag

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

Mechanismen werden von links nach rechts ausgewertet, und der erste Treffer entscheidet. Jeder kann einen Qualifier tragen: + Pass (Standard), - Fail, ~ Softfail, ? Neutral.

~all oder -all

~all besagt, dass nicht aufgeführte Server wahrscheinlich nicht berechtigt sind; allein darauf sollen Empfänger keine Ablehnung stützen. -all besagt, dass sie nicht berechtigt sind; was dann passiert, entscheidet die Richtlinie des Empfängers. Beides ist vertretbar, und die TR-03182 des BSI lässt beides zu: Nachrichten nicht autorisierter Server müssen Softfail oder Fail ergeben. RFC 9989 fügt einen Vorbehalt hinzu: Mit -all kann ein Empfänger, der SPF früh in der SMTP-Sitzung prüft, eine Nachricht ablehnen, die mit passendem DKIM bestanden hätte, typischerweise weitergeleitete Mail, und diese Ablehnung taucht in keinem DMARC-Bericht auf. ?all oder gar kein all trifft keine Aussage über nicht aufgeführte Server. +all lässt jede IP-Adresse im Internet bestehen; veröffentlichen Sie das nie.

Das Limit von 10 DNS-Abfragen

Empfänger werten höchstens 10 Terme aus, die DNS-Abfragen auslösen, die Terme in eingebundenen Einträgen mitgezählt (Abschnitt 4.6.4). Wird die Grenze überschritten, lautet das Ergebnis permerror, und SPF kann einer Nachricht nicht mehr zu einem DMARC-Pass verhelfen. Eine eigene Grenze gilt für Abfragen, die keinen Eintrag liefern (leere Antwort oder NXDOMAIN): Mehr als zwei davon sollen ebenfalls zu permerror führen. Ein Eintrag mit vier sichtbaren Termen kann die Grenze trotzdem überschreiten, wenn die eingebundenen Einträge selbst weitere includes enthalten; zählen Sie also rekursiv. Um wieder unter die Grenze zu kommen, streichen Sie Dienste, die Sie nicht mehr nutzen, schreiben Adressen, die Sie selbst kontrollieren, als ip4/ip6 und verlagern Dienste mit viel Versand auf eine eigene Bounce-Subdomain mit eigenem SPF-Eintrag. Beim Flattening kopieren Sie die IP-Bereiche eines Anbieters in den eigenen Eintrag; diese Kopie veraltet, sobald der Anbieter seine Adressen ändert.

Ein Eintrag pro Name

Zwei TXT-Einträge mit v=spf1 auf demselben Namen ergeben permerror; führen Sie sie zusammen. Ein Eintrag mit mehr als 255 Zeichen kommt als ein einziger TXT-Eintrag mit mehreren Zeichenketten in Anführungszeichen ins DNS, die Empfänger ohne Leerzeichen zusammensetzen. SPF wird auch nicht vererbt: Ein Eintrag auf example.com gilt nicht für mail.example.com, jeder als Envelope-Absender genutzte Name braucht also seinen eigenen.

So lesen Sie einen DMARC-Eintrag

DMARC ist seit Mai 2026 in RFC 9989 spezifiziert, einem Dokument auf dem Standards Track, das RFC 7489 ablöst. Der Eintrag liegt weiterhin unter _dmarc und beginnt mit v=DMARC1:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Ein Eintrag auf example.com gilt auch für Subdomains ohne eigenen Eintrag; Empfänger finden ihn mit dem Verfahren, das RFC 9989 „DNS Tree Walk“ nennt. Empfänger, die Sammelberichte verschicken, liefern sie als XML-Dateien, meist täglich, mit den IP-Adressen, die in Ihrem Namen gesendet haben, und deren Ergebnissen. Zeigt rua auf eine andere Organisationsdomain, etwa einen Auswertungsdienst, muss diese Domain einen TXT-Eintrag wie example.com._report._dmarc.reports.example.net mit v=DMARC1 veröffentlichen (RFC 9990, Abschnitt 4), sonst ignorieren Empfänger die Adresse. Nach Auffassung des BSI enthalten die 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.

Von none zu reject

1. Erfassen Sie jeden Dienst, der im Namen der Domain sendet: Postfachplattform, Newsletter, CRM, Rechnungsstellung, Ticketsystem, Formulare auf der Website.
2. Veröffentlichen Sie p=none mit rua und werten Sie die Berichte aus.
3. Bringen Sie jede legitime Quelle dazu, mit Alignment zu bestehen, am besten über DKIM, das Weiterleitungen in der Regel übersteht, während SPF dabei scheitert.
4. Wechseln Sie zu quarantine, wahlweise zuerst mit t=y, und erwägen Sie dann reject.

RFC 9989 sagt, dass Domains, deren Nutzer an Mailinglisten schreiben, kein reject veröffentlichen sollten (SHOULD NOT); wer es dennoch will, soll zuerst mindestens einen Monat bei none und ebenso lange bei quarantine verbringen und die Ergebnisse vergleichen. Jede Domain, die reject veröffentlicht, muss ihre Mail mit DKIM signieren (MUST). Die TR-03182 des BSI ist strenger: Sie erwartet quarantine oder reject, und eine sendende Domain soll reject verlangen (SHOULD). Eine Domain, die nur Rechnungen und Benachrichtigungen verschickt, ist ein anderer Fall als eine, mit der Ihre Mitarbeitenden in Mailinglisten schreiben. RFC 9989 weist Empfänger außerdem an, nicht allein wegen p=reject abzulehnen, räumt aber ein, dass Listenmail mit unverändertem From in der Praxis oft abgelehnt wird.

Domains, die keine Mail versenden

Geparkte Domains, Tippfehler- und Schreibvarianten (etwa „ue“ statt „ü“ im Firmennamen) und reine Weiterleitungsdomains können trotzdem in einer gefälschten From-Zeile auftauchen. RFC 7208 nennt einen SPF-Eintrag für Domains ohne Mailversand eine etablierte gute Praxis. Ein vollständiger Satz an Einträgen für eine hypothetische geparkte Domain:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

Der SPF-Eintrag berechtigt niemanden, und p=reject kostet hier nichts, weil keine legitime Mail verloren gehen kann. Der Null-MX nach RFC 7505 besagt, dass die Domain keine Mail annimmt; die Berichte gehen deshalb an example.com, das dafür example.net._report._dmarc.example.com veröffentlichen muss. Die BSI TR-03182 schreibt genau diese Kombination für ungenutzte Domains verbindlich vor (MUST). Die DMARC-Richtlinie gilt auch für Subdomains, SPF dagegen nicht; geben Sie deshalb jeder Subdomain mit eigenem A- oder MX-Eintrag ebenfalls ein v=spf1 -all.

Was Gmail, Yahoo und Outlook.com von Versendern verlangen

Seit November 2025 setzt Gmail die Regeln schrittweise strenger durch, bis hin zu Ablehnungen. Googles Regeln betreffen private Gmail-Konten, nicht Empfänger bei Google Workspace. Google und Yahoo verlangen DKIM-Schlüssel mit mindestens 1024 Bit. Microsoft lehnt Mail, die die Anforderungen verfehlt, mit 550 5.7.515 ab. Alle drei akzeptieren p=none; das erfüllt die Vorgabe, drückt aber keine Haltung zu gefälschter Mail aus. Betrachten Sie es als Zwischenstufe, nicht als fertige Einrichtung.

Große Postfachanbieter im deutschsprachigen Raum wie GMX, WEB.DE oder T-Online stehen nicht in der Tabelle. Wenn viele Ihrer Empfänger dort ein Postfach haben, prüfen Sie gesondert, welche Vorgaben diese Anbieter für Versender veröffentlichen.

MTA-STS und CAA: zwei weitere Einträge zum Prüfen

MTA-STS (RFC 8461) schützt eingehende Mail: Es teilt sendenden Servern mit, nur dann an Ihre MX-Hosts zuzustellen, wenn diese TLS mit einem vertrauenswürdigen Zertifikat anbieten. Dazu gehören ein TXT-Eintrag unter _mta-sts.example.com, etwa v=STSv1; id=20261001000000Z;, und eine Richtliniendatei unter https://mta-sts.example.com/.well-known/mta-sts.txt mit Modus, MX-Namen und max_age. Beginnen Sie im Modus testing, in dem Sender weiter zustellen und Fehler melden, sofern TLS-Reporting unter _smtp._tls.example.com eingerichtet ist, und wechseln Sie dann zu enforce. Ändern Sie die id bei jeder Änderung der Richtlinie.

CAA (RFC 8659) nennt die Zertifikatsaussteller (CAs), die TLS-Zertifikate für die Domain ausstellen dürfen, zum Beispiel CAA 0 issue "ca.example.net". Öffentliche CAs müssen den Eintrag vor der Ausstellung prüfen; eine Fehlausstellung durch eine berechtigte CA verhindert er nicht, und Browser werten ihn nicht aus. Ein Eintrag auf example.com gilt auch für Subdomains ohne eigenen Eintrag. Führen Sie jede CA auf, die Sie nutzen, auch die Ihres CDN, sonst können Erneuerungen scheitern. Der Leitfaden zu SSL/TLS und Security-Headern behandelt Zertifikate ausführlicher.

Typische SPF- und DMARC-Fehler und wie Sie sie beheben

Was der kostenlose Snapshot in Ihrem Mail-DNS prüft

Der kostenlose Snapshot führt ohne Anmeldung acht passive Prüfungen an einem öffentlichen Origin aus. Er ist kein Penetrationstest und nicht das Audit mit sechs Bereichen. Eine der acht Prüfungen liest Mail-Einträge im DNS:

• Exakter Hostname. MX, TXT, _dmarc, _mta-sts und CAA werden für den eingegebenen Hostnamen abgefragt, ohne Rückgriff auf die übergeordnete Domain. Ein fehlender Eintrag auf www.example.com bedeutet nicht, dass example.com ungeschützt ist. Damit die Einträge Ihrer Maildomain gelesen werden, geben Sie diese Domain selbst ein (example.com statt www.example.com); sie muss auf eine Adresse auflösen, damit der Snapshot einen Score berechnet.
• SPF. Ein fehlender Eintrag wird nur gemeldet (mittel), wenn der Host MX-Einträge hat. +all gilt als hohes Risiko, ?all als niedriges; ~all und -all lösen nichts aus. Mehr als zehn Terme mit DNS-Abfrage werden gemeldet (mittel), gezählt werden aber nur die Terme im Eintrag selbst, weil include: nicht aufgelöst wird.
• DMARC. Ein fehlender Eintrag wird nur gemeldet (mittel), wenn der Host MX-Einträge hat. p=none erscheint als Beobachtungsmodus (niedrig), quarantine oder reject gelten als bestanden. sp, pct, rua und das Alignment werden nicht ausgewertet.
• MTA-STS und CAA. Ein fehlender _mta-sts-TXT-Eintrag wird nur gemeldet (niedrig), wenn der Host MX-Einträge hat; die Richtliniendatei wird nicht abgerufen. Ist ein CAA-Eintrag vorhanden, gilt die Prüfung als bestanden, fehlt er, gibt es ein Signal der Stufe niedrig; der Inhalt wird nicht mit Ihrem Zertifikat abgeglichen.
• Nicht geprüft: DKIM, TLS-Reporting und DNSSEC.

Sie erhalten einen Score mit Note, eine Härtungsnote, die Zahl der Risikosignale und der bestandenen Prüfungen sowie bis zu drei Signale, die schwersten zuerst. Ein Mail-Befund kann also hinter einem Web-Befund zurückstehen. Ein Name, der nicht auf eine Adresse auflöst, bekommt keinen Score. Die Website-Launch-Checkliste geht alle acht Prüfungen durch, und der Leitfaden zur E-Mail-Authentifizierung im DNS behandelt die laufende Pflege.