Eine Domain ohne Mail-Richtlinie ist ein offener Briefkopf: Jeder kann Nachrichten verschicken, die von ihr zu stammen scheinen. Das trifft auch Domains, die gar keine Mail versenden, im Gegenteil, die sind besonders beliebt, weil dort niemand hinsieht.
Es geht nicht nur um Zustellbarkeit. Ein gefälschter Absender in deinem Namen trifft deine Kunden, und die Rechnung dafür kommt als Vertrauensverlust, nicht als Fehlermeldung. Die großen Anbieter verlangen die drei Einträge inzwischen ohnehin für Massenversender, die Richtung ist eindeutig.
Was die drei Einträge tun#
| Eintrag | Beantwortet | Ohne ihn |
|---|---|---|
| SPF | Welche Server dürfen für diese Domain senden? | jeder Server darf |
| DKIM | Ist die Nachricht unterwegs unverändert und vom richtigen Absender signiert? | keine Prüfbarkeit |
| DMARC | Was soll der Empfänger tun, wenn SPF oder DKIM scheitern und wohin die Berichte? | jeder entscheidet selbst |
SPF und DKIM sind Prüfungen. DMARC ist die Anweisung, was aus dem Ergebnis folgt und der einzige der drei, der dir Berichte zurückliefert.
Der Ist-Zustand in drei Zeilen#
DOM=example.org
dig +short TXT "$DOM" | grep -i spf
dig +short TXT "_dmarc.$DOM"
dig +short TXT "standard._domainkey.$DOM" # Selektor variiert je AnbieterLeere Ausgaben sind das häufigste Ergebnis und gleichzeitig der Befund.
Reihenfolge, die nichts kaputtmacht#
1. Bestand klären: Wer versendet in deinem Namen? Nicht nur der eigene Mailserver: Rechnungsprogramm, Newsletter-Dienst, Kontaktformular des Webhosters, Monitoring-Alarme, Ticketsystem. Jede dieser Quellen muss in SPF stehen oder über DKIM signieren.
2. SPF veröffentlichen, zunächst weich.
example.org. TXT "v=spf1 mx a:mail.example.org include:_spf.dienst.example ~all"
~all (softfail) ist die Übergangsstufe: Nichts wird verworfen, aber die Berichte zeigen, wer sendet. Nach zwei bis vier Wochen ohne Überraschung auf -all gehen.
3. DKIM einrichten. Der Schlüssel wird auf dem versendenden System erzeugt, der öffentliche Teil landet im DNS.
# Beispiel für OpenDKIM
opendkim-genkey -b 2048 -d example.org -s mail2026
cat mail2026.txt # dieser Inhalt kommt als TXT-Eintrag ins DNSSelektoren mit Jahreszahl (mail2026) machen den späteren Schlüsselwechsel zu einer Kleinigkeit statt zu einer Umstellung.
4. DMARC, erst beobachten, dann durchsetzen.
_dmarc.example.org. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
p=none verwirft nichts und liefert trotzdem täglich Berichte. Wenn diese Berichte über vier Wochen nur eigene Quellen zeigen, geht es weiter auf p=quarantine und schließlich p=reject.
Klassische Weiterleitungen brechen SPF: Der weiterleitende Server ist nicht in deiner Liste. DKIM überlebt sie meistens, deshalb erst DMARC durchsetzen, wenn DKIM zuverlässig pass liefert. Wer beides gleichzeitig scharf schaltet, sucht die Ursache später in der falschen Ecke.
Domains, die gar nicht senden#
Für Domains ohne Mailversand ist die Sache kurz und sie gehört zu den Einträgen, die am häufigsten fehlen:
example.org. TXT "v=spf1 -all"
_dmarc.example.org. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
*._domainkey.example.org. TXT "v=DKIM1; p="
Drei Zeilen, und die Domain fällt als Absender für Phishing aus.
Prüfen, dass es wirklich greift#
# Kopfzeilen einer empfangenen Testmail auswerten
grep -iE 'Authentication-Results|dkim=|spf=|dmarc=' testmail.eml
# Syntax der eigenen Einträge gegenlesen
dig +short TXT example.org | tr ';' '\n'Eine Testmail an ein Konto bei einem großen Anbieter und ein Blick in die Kopfzeilen sagt mehr als jeder Prüfdienst: Dort steht spf=pass, dkim=pass, dmarc=pass, oder eben nicht.
Der zugehörige Serverteil steht in Ausgehend begrenzen: Wer keinen Mailserver betreibt, sperrt ausgehenden Port 25 und merkt dadurch, wenn eine übernommene Anwendung mit dem Versand anfängt.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
