SPF, DKIM und DMARC per Kommandozeile testen
von Stefan Lindecke (Admin)
E-Mail-Authentifizierung direkt per CLI prüfen
Eine funktionierende Mail-Infrastruktur besteht heute nicht nur aus einem SMTP-Server. Wer E-Mails zuverlässig zustellen und gleichzeitig die eigene Domain gegen Missbrauch schützen möchte, sollte mindestens SPF, DKIM und DMARC korrekt konfigurieren.
DMARC baut dabei auf SPF und DKIM auf und prüft zusätzlich, ob die authentifizierte Domain zur sichtbaren Absenderdomain passt („Alignment“). Eine Nachricht besteht den DMARC-Test, wenn mindestens SPF oder DKIM erfolgreich und entsprechend aligned ist.
Die folgenden Beispiele verwenden die Domain:
lindesbs.de
Die Tests funktionieren unter praktisch jeder Linux-Distribution. Benötigt wird hauptsächlich dig, das beispielsweise unter Debian/Ubuntu im Paket dnsutils enthalten ist.
1. SPF-Record überprüfen
SPF wird als TXT-Record im DNS der Domain veröffentlicht.
dig TXT lindesbs.de
Übersichtlicher ist:
dig +short TXT lindesbs.de
Da eine Domain mehrere TXT-Records besitzen kann, kann man gezielt nach SPF suchen:
dig +short TXT lindesbs.de | grep 'v=spf1'
Eine typische Antwort könnte beispielsweise so aussehen:
"v=spf1 mx a ip4:203.0.113.10 -all"
Die wichtigsten Bestandteile sind:
| Eintrag | Bedeutung |
|---|---|
v=spf1 |
SPF Version 1 |
a |
IP-Adresse des A-Records darf senden |
mx |
Mailserver aus dem MX-Record dürfen senden |
ip4: |
angegebene IPv4-Adresse darf senden |
ip6: |
angegebene IPv6-Adresse darf senden |
include: |
SPF-Regeln einer anderen Domain einbeziehen |
~all |
andere Absender führen zu Softfail |
-all |
andere Absender führen zu Fail |
SPF definiert damit, welche Systeme berechtigt sind, E-Mails für eine Domain zu versenden.
MX-Server ebenfalls kontrollieren
Wenn im SPF beispielsweise mx verwendet wird, sollte man sich auch die MX-Records ansehen:
dig +short MX lindesbs.de
Anschließend lässt sich die IP-Adresse eines Mailservers überprüfen:
dig +short A mail.lindesbs.de
dig +short AAAA mail.lindesbs.de
2. DMARC per CLI überprüfen
Der DMARC-Eintrag befindet sich nicht direkt unter der Domain, sondern unter:
_dmarc.lindesbs.de
Die Abfrage erfolgt mit:
dig +short TXT _dmarc.lindesbs.de
Beispielsweise könnte die Antwort lauten:
"v=DMARC1; p=reject; sp=reject; pct=100; adkim=r; aspf=r; rua=mailto:postmaster@lindesbs.de"
Damit lässt sich bereits ein großer Teil der Konfiguration kontrollieren.
Die wichtigsten DMARC-Parameter
| Parameter | Bedeutung |
|---|---|
v=DMARC1 |
DMARC-Version |
p=none |
nur beobachten |
p=quarantine |
fehlgeschlagene Nachrichten sollen als verdächtig behandelt werden |
p=reject |
fehlgeschlagene Nachrichten sollen abgewiesen werden |
sp= |
Policy für Subdomains |
pct= |
Anteil der Nachrichten, auf die die Policy angewendet wird |
adkim=r |
relaxed DKIM Alignment |
adkim=s |
strict DKIM Alignment |
aspf=r |
relaxed SPF Alignment |
aspf=s |
strict SPF Alignment |
rua= |
Empfänger der aggregierten DMARC-Reports |
Ein häufiger Fehler ist beispielsweise:
p=none
Der DMARC-Eintrag funktioniert damit zwar, schützt die Domain aber noch nicht durch Quarantäne oder Ablehnung. Die Policy none fordert vom empfangenden Server ausdrücklich keine bestimmte Behandlung fehlgeschlagener Nachrichten.
3. DMARC über einen bestimmten DNS-Server testen
Gerade nach Änderungen am DNS kann es sinnvoll sein, unterschiedliche Resolver abzufragen.
Beispielsweise:
dig @1.1.1.1 +short TXT _dmarc.lindesbs.de
oder:
dig @8.8.8.8 +short TXT _dmarc.lindesbs.de
Zusätzlich kann man den autoritativen Nameserver direkt fragen.
Zunächst:
dig +short NS lindesbs.de
Angenommen, einer der Nameserver lautet:
ns1.example.net.
Dann:
dig @ns1.example.net +short TXT _dmarc.lindesbs.de
Das ist besonders hilfreich, wenn eine DNS-Änderung auf dem autoritativen Nameserver bereits vorhanden ist, bei öffentlichen Resolvern aufgrund des TTL/Cachings aber noch der alte Wert erscheint.
4. DKIM per Kommandozeile überprüfen
Bei DKIM gibt es einen zusätzlichen Parameter: den Selector.
Ein DKIM-Eintrag befindet sich unter:
SELECTOR._domainkey.DOMAIN
Verwendet unser Mailserver beispielsweise den Selector:
dkim
lautet die Abfrage:
dig +short TXT dkim._domainkey.lindesbs.de
Ein DKIM-Record sieht beispielsweise ungefähr so aus:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Der entscheidende Teil ist:
p=...
Dort befindet sich der öffentliche Schlüssel, mit dem ein empfangender Mailserver die DKIM-Signatur einer Nachricht überprüfen kann.
Aber wie finde ich den DKIM-Selector?
Wenn man den Selector nicht kennt, kann man ihn nicht zuverlässig durch eine normale DNS-Abfrage ermitteln.
Am einfachsten schaut man sich eine tatsächlich verschickte E-Mail an. Im Header findet sich beispielsweise:
DKIM-Signature: v=1; a=rsa-sha256; d=lindesbs.de; s=dkim; ...
Relevant sind:
d=lindesbs.de
s=dkim
d= gibt die signierende Domain und s= den Selector an.
Daraus ergibt sich:
dig +short TXT dkim._domainkey.lindesbs.de
5. Externe DMARC-Report-Adresse überprüfen
Hier steckt eine etwas weniger bekannte Besonderheit von DMARC.
Angenommen, lindesbs.de verwendet:
rua=mailto:postmaster@ktrion.de
Dann werden die Reports nicht an lindesbs.de, sondern an die externe Domain ktrion.de geschickt.
Diese externe Domain muss den Empfang autorisieren. Das verhindert, dass jemand beliebige fremde Domains als Ziel großer Mengen von DMARC-Reports einträgt.
Für unser Beispiel muss deshalb folgender Name existieren:
lindesbs.de._report._dmarc.ktrion.de
Test:
dig +short TXT lindesbs.de._report._dmarc.ktrion.de
Die erwartete Antwort lautet:
"v=DMARC1"
Kommt keine Antwort, fehlt wahrscheinlich die Autorisierung.
Auf dem DNS-System für ktrion.de müsste entsprechend ein TXT-Record veröffentlicht sein:
lindesbs.de._report._dmarc.ktrion.de. TXT "v=DMARC1"
Dieses Verfahren ist Bestandteil der DMARC-Spezifikation für externe Report-Ziele.
6. Alle wichtigen DNS-Checks hintereinander
Für einen schnellen Check können wir die wichtigsten Abfragen einfach zusammenfassen:
DOMAIN="lindesbs.de"
SELECTOR="dkim"
echo "=== MX ==="
dig +short MX "$DOMAIN"
echo
echo "=== SPF ==="
dig +short TXT "$DOMAIN" | grep 'v=spf1'
echo
echo "=== DKIM ==="
dig +short TXT "${SELECTOR}._domainkey.${DOMAIN}"
echo
echo "=== DMARC ==="
dig +short TXT "_dmarc.${DOMAIN}"
Damit erhält man innerhalb weniger Sekunden einen Überblick über die öffentlich sichtbare Mail-Konfiguration.
7. DNSSEC nicht vergessen
Zusätzlich lässt sich prüfen, ob DNSSEC für die Domain eingerichtet wurde:
dig +dnssec lindesbs.de
Etwas kompakter:
dig +dnssec lindesbs.de | grep -E 'RRSIG|DNSKEY'
Die Existenz von Signaturen allein beweist allerdings noch nicht vollständig, dass die gesamte Vertrauenskette korrekt validiert.
Mit einem validierenden Resolver lässt sich beispielsweise testen:
dig @1.1.1.1 lindesbs.de A +dnssec
Im Header sollte bei erfolgreicher Validierung das Flag
ad
auftauchen:
flags: qr rd ra ad;
ad steht für Authenticated Data.
8. Reverse DNS des Mailservers prüfen
Für die Zustellbarkeit ist auch der PTR-/Reverse-DNS-Eintrag des sendenden Servers wichtig.
Angenommen, unser Mailserver verwendet:
mail.lindesbs.de
Zunächst ermitteln wir dessen IP:
dig +short A mail.lindesbs.de
Angenommen, die Antwort lautet:
203.0.113.10
Dann:
dig +short -x 203.0.113.10
Idealerweise erhalten wir:
mail.lindesbs.de.
Anschließend kontrollieren wir noch einmal die Gegenrichtung:
dig +short A mail.lindesbs.de
Damit ergibt sich:
203.0.113.10
↓ PTR
mail.lindesbs.de
↓ A
203.0.113.10
Diese Übereinstimmung wird häufig als Forward-confirmed Reverse DNS (FCrDNS) bezeichnet.
9. Eine echte E-Mail ist der wichtigste Test
DNS-Abfragen zeigen uns, was konfiguriert wurde. Sie zeigen aber noch nicht, ob eine tatsächlich verschickte E-Mail SPF, DKIM und DMARC besteht.
Dafür schicken wir beispielsweise eine Nachricht von:
test@lindesbs.de
an ein externes Postfach und untersuchen dort die vollständigen Header.
Interessant ist insbesondere:
Authentication-Results:
spf=pass ...
dkim=pass ...
dmarc=pass ...
Ein ideales Ergebnis wäre:
spf=pass
dkim=pass
dmarc=pass
Aber wichtig: Für DMARC reicht nicht einfach irgendein spf=pass oder dkim=pass. Die erfolgreich authentifizierte Domain muss zusätzlich zur sichtbaren From:-Domain ausgerichtet sein. Genau dieses Identifier Alignment ist ein zentraler Bestandteil von DMARC.
10. Praktischer Komplettcheck
Für lindesbs.de könnte ein manueller Check daher folgendermaßen aussehen:
DOMAIN="lindesbs.de"
SELECTOR="dkim"
echo "### MX"
dig +short MX "$DOMAIN"
echo
echo "### SPF"
dig +short TXT "$DOMAIN" | grep 'v=spf1'
echo
echo "### DKIM"
dig +short TXT "${SELECTOR}._domainkey.${DOMAIN}"
echo
echo "### DMARC"
dig +short TXT "_dmarc.${DOMAIN}"
echo
echo "### Nameserver"
dig +short NS "$DOMAIN"
echo
echo "### DNSSEC"
dig @1.1.1.1 "$DOMAIN" A +dnssec | grep -E 'flags:|RRSIG'
Verwendet DMARC beispielsweise eine externe Report-Adresse bei ktrion.de, ergänzen wir:
echo
echo "### DMARC External Reporting"
dig +short TXT \
"${DOMAIN}._report._dmarc.ktrion.de"
Fazit
Für einen ersten Mailserver-Check benötigt man keinen Webdienst. Mit dig lassen sich die entscheidenden DNS-Einstellungen direkt untersuchen:
# SPF
dig +short TXT lindesbs.de | grep 'v=spf1'
# DMARC
dig +short TXT _dmarc.lindesbs.de
# DKIM
dig +short TXT SELECTOR._domainkey.lindesbs.de
# MX
dig +short MX lindesbs.de
# Reverse DNS
dig +short -x IP-DES-MAILSERVERS
Bei einem externen DMARC-Report-Empfänger kommt hinzu:
dig +short TXT \
lindesbs.de._report._dmarc.REPORT-DOMAIN
Ein sauberer DNS-Check ist allerdings nur der erste Schritt. Der abschließende Test sollte immer eine wirklich versendete E-Mail umfassen. Erst deren Authentication-Results zeigen, ob SPF und DKIM nicht nur vorhanden sind, sondern ob die Nachricht beim Empfänger tatsächlich DMARC besteht.
Hinweis zur Aktualität: DMARC wurde 2026 auf den IETF Standards Track überführt; RFC 9989, 9990 und 9991 haben den älteren RFC 7489 aktualisiert bzw. abgelöst.