Wenn Mails beim Empfänger im Spam-Ordner landen oder abgelehnt werden, steckt dahinter sehr oft keine „kaputte“ Einstellung, sondern ein Missverständnis: SPF, DKIM und DMARC prüfen unterschiedliche Absender. Erst wenn man das verstanden hat, lassen sich die Fehlerbilder sauber einordnen.
Der Unterschied in 30 Sekunden
| Prüft | Steht im DNS als | Wenn es fehlt | |
|---|---|---|---|
| SPF | Darf dieser Server für die Domain senden? | TXT auf der Domain: v=spf1 … | Fremde Server können Ihre Domain leichter fälschen; Mails öfter im Spam. |
| DKIM | Ist die Mail unverändert und von der Domain signiert? | TXT auf selector._domainkey | Weiterleitungen brechen SPF — ohne DKIM besteht die Mail dann gar nichts. |
| DMARC | Passt SPF oder DKIM zur sichtbaren Absenderdomain — und was tun, wenn nicht? | TXT auf _dmarc: v=DMARC1; p=… | Keine Richtlinie, keine Berichte; Gmail und Microsoft verlangen DMARC für Massenversender. |
Selbst prüfen: Mail-DNS-Check (MX, PTR, SPF, DMARC), SPF-Lookup-Limit und den DMARC-Generator für den passenden Eintrag.
Was SPF, DKIM und DMARC tatsächlich prüfen
SPF beantwortet eine einzige Frage: Darf die sendende IP-Adresse für die Domain im Envelope-From (auch MAIL FROM oder Return-Path) Mails verschicken? Diese Adresse sieht der Empfänger in der Regel gar nicht. Der sichtbare Absender (From:) spielt für SPF keine Rolle.
DKIM prüft, ob die Nachricht von einer Domain kryptografisch signiert wurde (Feld d= in der Signatur) und unterwegs nicht verändert wurde. Den öffentlichen Schlüssel holt sich der Empfänger aus dem DNS (selector._domainkey.domain).
DMARC verbindet beides mit dem, was der Empfänger tatsächlich sieht: der From-Domain. DMARC verlangt, dass SPF oder DKIM besteht und dass die dabei geprüfte Domain zur From-Domain passt („Alignment“). Die Policy (none, quarantine, reject) sagt dem Empfänger, was bei einem Fehlschlag zu tun ist.
Das Alignment-Problem
Ein typisches Beispiel: Ein Newsletter-Dienst verschickt Mails mit dem sichtbaren Absender info@beispiel.de, benutzt aber als Return-Path eine eigene Domain, etwa bounce.newsletter-dienst.com.
Ergebnis: SPF besteht – für newsletter-dienst.com. Eine DKIM-Signatur mit d=newsletter-dienst.com besteht ebenfalls. Beide Domains passen aber nicht zu beispiel.de. DMARC schlägt fehl, obwohl „SPF pass“ im Header steht.
Alignment gibt es in zwei Modi: relaxed (Standard, aspf=r/adkim=r) akzeptiert Subdomains derselben Organisations-Domain, etwa mail.beispiel.de zu beispiel.de. Strict verlangt exakt dieselbe Domain.
Lösung: Beim Versanddienst DKIM mit der eigenen Domain einrichten (meist ein oder zwei CNAME- oder TXT-Einträge) und, wenn möglich, eine eigene Return-Path-Domain konfigurieren. Dann besteht DMARC über DKIM, selbst wenn SPF nicht aligned ist.
Header richtig lesen
Im Mailprogramm den Quelltext der Nachricht öffnen (bei Gmail: „Original anzeigen“) und nach Authentication-Results suchen:
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=bounce.newsletter-dienst.com;
dkim=pass header.d=newsletter-dienst.com;
dmarc=fail (p=QUARANTINE) header.from=beispiel.deHier sieht man sofort das Muster: SPF und DKIM bestehen, aber für newsletter-dienst.com statt beispiel.de. Der Abgleich von smtp.mailfrom und header.d mit header.from ist der wichtigste Schritt der Fehlersuche.
Prüfbefehle
dig +short TXT beispiel.de | grep -i spf
dig +short TXT _dmarc.beispiel.de
dig +short TXT selector1._domainkey.beispiel.deTypische Fehler, die dabei auffallen:
Mehrere SPF-Einträge: Pro Domain darf es nur einen TXT-Eintrag mit v=spf1 geben. Zwei Einträge führen zu einem permerror – alle Absender müssen in einem Eintrag stehen.
Zu viele DNS-Abfragen: SPF erlaubt höchstens 10 Abfragen (include, a, mx, redirect …). Wer viele Dienste per include einbindet, überschreitet das schnell – ebenfalls permerror.
Falscher Selector: Den Selector findet man im Header (s= in der DKIM-Signatur), nicht raten.
In welcher Reihenfolge man alles einführt
1. SPF bereinigen. Ein Eintrag, alle legitimen Versender enthalten, am Ende zunächst ~all.
2. DKIM bei jedem Versanddienst aktivieren – jeweils mit der eigenen Domain (Webmailer, Newsletter-Tool, Ticketsystem, CRM, Rechnungsprogramm …).
3. DMARC im Beobachtungsmodus starten:
_dmarc.beispiel.de. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"Zwei bis vier Wochen die Aggregat-Berichte (rua) auswerten: Wer verschickt tatsächlich Mails in Ihrem Namen? Oft taucht dabei ein längst vergessener Dienst auf.
4. Schrittweise verschärfen: p=quarantine (zunächst mit pct=10 und dann steigern), erst danach p=reject.
Weitere Ursachen für Spam-Einstufung
Fehlender oder falscher PTR-Eintrag (Reverse-DNS) beim eigenen Mailserver: Die IP sollte auf einen Hostnamen zeigen, der wieder auf dieselbe IP auflöst.
IP-Adresse auf einer Blockliste – nach einem Umzug oder bei geteilter IP leider häufig (zum Umzug siehe DNS-Umzug ohne Ausfall).
Plötzlicher Versandstoß von einer bisher ruhigen Domain.
Massenmails ohne Abmelde-Link: Google und Yahoo verlangen seit 2024 von Absendern größerer Mengen SPF, DKIM, DMARC, eine einfache Abmeldung per List-Unsubscribe und niedrige Spam-Raten.
Checkliste
- Genau ein SPF-Eintrag, höchstens 10 Abfragen?
- DKIM bei jedem Versanddienst mit der eigenen Domain aktiv?
- DMARC-Eintrag vorhanden, Berichte werden gelesen?
- Im Header:
header.frompasst zusmtp.mailfromoderheader.d? - PTR-Eintrag stimmt, IP nicht gelistet?
Die meisten „Spam-Probleme“ sind kein Zustellproblem, sondern ein Identitätsproblem: Der Empfänger kann nicht nachvollziehen, dass die Mail wirklich von der Domain kommt, die im Absender steht. Wer das mit sauberem Alignment belegt, löst den Großteil der Fälle.