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.