E-Mails landen im Spam? Die DNS-Checkliste zum Abarbeiten

Wenn legitime E-Mails im Spam landen, liegt es an einem von zwei Dingen: an der Authentifizierung (der Empfänger kann nicht bestätigen, dass die Nachricht wirklich von Ihrer Domain stammt) oder an der Reputation (er kann es, und ihm gefällt nicht, was er sieht). Das Erste lässt sich im DNS beheben. Das Zweite nicht, aber solange das Erste nicht stimmt, zählt alles andere nicht.

Diese Checkliste arbeitet die DNS-Seite in der Reihenfolge ab, in der sich Probleme am schnellsten finden. Die Konzepte dahinter erklärt der Beitrag MX, SPF, DKIM und DMARC erklärt. Hier bleibt es praktisch.

Schritt 0: Header einer Nachricht lesen, die im Spam gelandet ist

Raten Sie nicht. Schicken Sie eine Nachricht an ein Postfach, das Sie selbst kontrollieren, und zwar bei dem Anbieter, bei dem das Problem auftritt. Öffnen Sie sie und wählen Sie „Original anzeigen“ oder „Quelltext anzeigen“. Suchen Sie den Header Authentication-Results, den der Empfänger hinzugefügt hat:

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=bounces.mailer.example;
   dkim=pass header.d=mailer.example header.s=s1;
   dmarc=fail (p=NONE) header.from=example.com

Dieser eine Header sagt Ihnen das meiste von dem, was Sie wissen müssen:

Feld	Frage, die es beantwortet
`spf=` und `smtp.mailfrom=`	Passte die sendende IP-Adresse zum SPF-Record der Envelope-Domain, und welche Domain war das?
`dkim=` und `header.d=`	Gab es eine gültige Signatur, und für welche Domain?
`dmarc=` und `header.from=`	Hat SPF oder DKIM für die Domain bestanden, die der Empfänger sieht?

Im Beispiel „besteht“ alles, und DMARC scheitert trotzdem: SPF und DKIM haben für die Domains des Versanddienstes bestanden, nicht für example.com. Das ist der mit Abstand häufigste Befund, und Schritt 4 befasst sich damit.

Notieren Sie außerdem die sendende IP-Adresse aus der obersten Received:-Zeile, die der Empfänger hinzugefügt hat. Sie brauchen sie in Schritt 5.

Schritt 1: Alles auflisten, was im Namen Ihrer Domain versendet

Am häufigsten scheitert die Authentifizierung bei einem Absender, an den niemand gedacht hat: Postfachanbieter, Newsletter-Tool, CRM, Rechnungssystem, Helpdesk, Kontaktformular der Website, Scanner im Büro, Monitoring-Alarme. Schreiben Sie alle auf. Jeder einzelne muss durch SPF oder DKIM abgedeckt sein, am besten durch beides.

Schritt 2: SPF prüfen

$ dig +short example.com TXT | grep spf1
"v=spf1 include:_spf.mailprovider.example include:spf.mailer.example -all"

Prüfen Sie:

Genau ein Record, der mit v=spf1 beginnt. Zwei Records sind ein permanenter Fehler (permerror), und das Ergebnis ist dasselbe, als hätten Sie keinen.
Jeder Absender aus Schritt 1 ist durch ein include:, ip4: oder ip6: abgedeckt.
Insgesamt nicht mehr als 10 DNS-Abfragen. include, a, mx, exists und redirect zählen jeweils, und Includes sind verschachtelt. Wer das Limit überschreitet, erhält ebenfalls permerror. Entfernen Sie Dienste, die Sie nicht mehr nutzen, bevor Sie zu „SPF-Flattening“ greifen.
Am Ende steht ~all oder -all. +all autorisiert das gesamte Internet, ?all sagt nichts aus.
Kein ptr-Mechanismus. Er ist langsam und unzuverlässig, und die SPF-Spezifikation selbst rät davon ab.
Subdomains, die E-Mails versenden (news.example.com), haben einen eigenen SPF-Record. SPF wird nicht vererbt.

Denken Sie daran, was SPF prüft: den Envelope-Absender (Return-Path), nicht den From-Header. Verwendet ein Dienst seine eigene Bounce-Domain, besteht SPF für dessen Domain und hilft Ihrem DMARC-Ergebnis nicht, solange Sie keinen eigenen Return-Path einrichten.

Schritt 3: DKIM prüfen

Entnehmen Sie Selektor (s=) und Domain (d=) dem DKIM-Signature-Header einer echten Nachricht und fragen Sie dann den Schlüssel ab:

$ dig +short s1._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Der Record existiert und enthält einen Wert für p=. Ein leeres p= bedeutet, dass der Schlüssel widerrufen wurde.
Lange Schlüssel sind auf mehrere Zeichenketten in Anführungszeichen verteilt, ohne verirrte Leerzeichen oder Zeilenumbrüche, die die Verwaltungsoberfläche eingeschleppt hat.
Die Schlüssellänge beträgt 2048 Bit, sofern der Anbieter das zulässt. 1024 Bit sind das Minimum, das Empfänger akzeptieren.
Hat der Anbieter CNAME-Records statt TXT verlangt, sind sie vorhanden und werden von Ihrem DNS-Anbieter weder „geflattet“ noch über einen Proxy geleitet.
d= ist Ihre Domain, nicht die des Anbieters. Die meisten Dienste signieren mit ihrer eigenen Domain, bis Sie deren Einrichtung „Domain authentifizieren“ abgeschlossen haben. Erst dadurch zählt DKIM für DMARC.
Jeder Versanddienst hat seinen eigenen Selektor.

Die DKIM-Selektoren einer Domain lassen sich von außen nicht auflisten. Sie finden sie in den Headern von Nachrichten oder in den Einstellungen des Anbieters.

Schritt 4: DMARC und Alignment

$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Ein Record unter _dmarc.example.com, der mit v=DMARC1 beginnt und ein gültiges p= enthält.
Eine rua=-Adresse, die tatsächlich jemand liest, ob Mensch oder Werkzeug. Liegt sie auf einer anderen Domain, muss diese Domain einen Autorisierungs-Record veröffentlichen.
Für jeden Absender besteht mindestens SPF oder DKIM mit einer Domain, die zur From-Domain passt (im standardmäßigen „relaxed“-Modus genügt dieselbe Organisationsdomain).

Seit Februar 2024 verlangen Gmail und Yahoo von allen, die etwa 5.000 oder mehr Nachrichten pro Tag an ihre Nutzer senden, SPF, DKIM und einen DMARC-Record (mindestens p=none) mit Alignment, dazu bei Werbe-E-Mails die Abmeldung mit einem Klick und eine niedrige Beschwerderate. Andere große Anbieter haben ähnliche Regeln angekündigt. Kleinere Versender brauchen mindestens SPF oder DKIM und werden in der Praxis nach denselben Maßstäben beurteilt.

Mit p=none erhalten Sie Berichte und erfüllen das Minimum. Vor Spoofing schützt es die Domain nicht. Wechseln Sie zu quarantine und reject, sobald die Berichte zeigen, dass bei allen legitimen Quellen das Alignment stimmt.

Schritt 5: Der sendende Server: Reverse DNS und HELO

Nur relevant, wenn Sie den Mailserver selbst betreiben. Mit der IP-Adresse aus Schritt 0:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com
192.0.2.25

Ein PTR-Record existiert und ist nicht der generische Standardname des Anbieters.
Der Name löst wieder auf dieselbe IP-Adresse auf.
Der Server meldet sich im EHLO mit demselben Namen.
Hat der Server IPv6, gilt für diese Adresse dasselbe, oder der ausgehende Versand ist auf IPv4 beschränkt.

Einzelheiten stehen im Glossar unter Reverse DNS.

Schritt 6: MX und die Domain selbst

Die Domain hat funktionierende MX-Records, die auf Hostnamen zeigen (keine IP-Adressen, keine CNAMEs), die E-Mails annehmen. Empfänger misstrauen Absendern, die weder Bounces noch Antworten empfangen können.
postmaster@ und abuse@ erreichen einen Menschen.
Domains, die nie E-Mails versenden, sagen das auch: v=spf1 -all, ein Null-MX (0 .) und v=DMARC1; p=reject. Geparkte Domains sind ein beliebtes Ziel für Spoofing.

Schritt 7: TLS

Ausgehende E-Mails nutzen STARTTLS. Gmail kennzeichnet unverschlüsselte E-Mails mit einem roten Schloss, und die Regeln für Massenversender verlangen TLS.
Ihr eigener MX bietet STARTTLS mit einem Zertifikat an, das nicht abgelaufen ist:

$ openssl s_client -connect mail.example.com:25 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

Schritt 8: Blocklisten und Reputation

Schlagen Sie die sendende IP-Adresse und die Domain auf den Abfrageseiten der großen Blocklisten-Betreiber selbst nach. Ein Eintrag auf einer obskuren Liste spielt selten eine Rolle, einer auf einer weit verbreiteten schon. Beheben Sie die Ursache (kompromittiertes Konto, offenes Formular, gekaufte Adressliste), bevor Sie die Austragung beantragen.
Melden Sie die Domain bei den Postmaster-Tools an, die große Postfachanbieter bereitstellen. Sie zeigen, wie diese Anbieter Ihre Domain sehen: Spam-Beschwerderate, Authentifizierungsergebnisse, Reputation.

Wenn das DNS stimmt und E-Mails trotzdem im Spam landen

Dann liegt es an Reputation oder Inhalt, und kein DNS-Eintrag hilft:

eine neue Domain oder neue IP-Adresse, die vom ersten Tag an Volumen versendet, ohne Warm-up
Empfänger, die die E-Mails nie bestellt haben und sich beschweren
alte Listen mit vielen toten Adressen
Linkverkürzer, Links auf schlecht beleumundete Domains, Nachrichten, die nur aus Bildern bestehen
eine From-Domain, die von der Domain in den Links und der Domain in der Signatur abweicht
bei geteilten IP-Adressen: das Verhalten anderer Kunden

Das DNS sorgt dafür, dass Sie als Sie selbst beurteilt werden. Was danach geschieht, hängt davon ab, was Sie versenden.

Häufige Fehler

Für einen neuen Dienst einen zweiten SPF-Record anlegen, statt den bestehenden zu erweitern.
spf=pass und dkim=pass sehen und aufhören, ohne zu prüfen, welche Domain bestanden hat.
Ohne Blick in die Berichte auf p=reject springen und Rechnungen verlieren, die ein vergessenes System verschickt.
Nur vom eigenen Postfach an das eigene Postfach beim selben Anbieter testen.
Erwarten, dass Änderungen sofort sichtbar sind. SPF- und DMARC-Records bleiben für die Dauer ihrer TTL im Cache.

Mit OrbitProbe prüfen

Die MX-Abfrage von OrbitProbe zeigt die MX-Hosts einer Domain mit ihren Prioritäten, den wahrscheinlichen E-Mail-Anbieter sowie die SPF- und DMARC-Records, mit Hinweisen auf häufige Konfigurationsfehler. DKIM-Selektoren kann sie nicht auflisten, weil das von außen niemand kann. Prüfen Sie diese anhand eines Nachrichten-Headers, wie in Schritt 3 beschrieben. Führen Sie die Abfrage für genau die Domain aus, die in Ihrer From-Adresse steht, und noch einmal für jede Subdomain, die E-Mails versendet.