E-Mail-Authentifizierung: Warum eingerichtetes SPF, DKIM und DMARC noch nicht ausreichen
Sie haben alles erledigt. Stundenlang haben Sie DNS-Einträge bearbeitet und kryptische Zeichenfolgen aus den Systemen Ihrer E-Mail-Dienstleister kopiert. Sie haben die Prüfwerkzeuge ausgeführt und überall grüne Häkchen erhalten. Warum sinken dann die Öffnungsraten? Warum landen Transaktionsmails wie Passwort-Resets, Rechnungen und Benachrichtigungen im Spam oder verschwinden ganz?
Die unbequeme Wahrheit über SPF, DKIM und DMARC lautet: Eine gültige Konfiguration ist nicht dasselbe wie eine gute Reputation. Ein gültiger Ausweis bringt einen Betrunkenen auch nicht am Türsteher vorbei. Seit Februar 2024 achten Anbieter wie Google, Yahoo und Microsoft nicht mehr nur darauf, ob eine Nachricht Spam sein könnte, sondern verstärkt auf die korrekte Umsetzung ihrer Protokollvorgaben. Wenn Ihr Dashboard grünes Licht zeigt, Ihre Umsätze aber Warnsignale senden, stoßen Sie wahrscheinlich an eine der versteckten Hürden jenseits der bekannten Abkürzungen.
Die Falle für Massenversender: Die Schwelle ist niedriger als gedacht
Der gefährlichste Irrtum lautet: „Ich versende weniger als 5,000 E-Mails pro Tag, deshalb gelten die Regeln für Massenversender nicht für mich.“
Das ist aus zwei Gründen falsch, und selbst korrekt eingerichtetes SPF, DKIM und DMARC schützt Sie nicht vor dieser Falle. Erstens kann Google das Volumen auf Ebene der primären Domain zusammenrechnen. Wenn Sie 2,000 Marketingmails über news.example.com, 2,000 Transaktionsmails über app.example.com und 1,500 interne Hinweise über corp.example.com versenden, gelten Sie als Massenversender. Die Mengen der Subdomains werden der Root-Domain zugerechnet.
Zweitens zählt auch der einmal erreichte Höchststand. Überschreiten Sie die Schwelle von 5,000 E-Mails auch nur einmal, etwa bei einer Black-Friday-Aktion oder einer einmaligen Datenbankbenachrichtigung, kann Google Ihre Domain dauerhaft als Massenversender einstufen. Selbst wenn das Volumen später auf 50 E-Mails pro Tag fällt, können weiterhin die strengsten Vorgaben gelten. Prüfen Sie deshalb stets die aktuellen Richtlinien des jeweiligen Anbieters.
Microsoft berücksichtigt wiederum andere Faktoren. Ihre SPF-, DKIM- und DMARC-Einträge können einwandfrei sein, doch auch das Alter der IP-Adresse und das Versandmuster spielen eine Rolle. Wenn Sie mit einer neuen Domain und einer neuen IP sofort 2,000 E-Mails versenden, kann Microsoft den Versand unabhängig vom SPF-Ergebnis mit 4xx-Antworten drosseln. Für den Anbieter sind Sie noch ein unbekannter Absender, dessen Vertrauen erst schrittweise aufgebaut werden muss.
Typische Fehler bei SPF, DKIM und DMARC
Viele Verantwortliche richten SPF, DKIM und DMARC ein, prüfen die Syntax und betrachten die Aufgabe als erledigt. Doch eine korrekte Syntax garantiert noch keine korrekte Funktion. An den folgenden Stellen treten die häufigsten Probleme auf.
SPF: Das schwarze Loch bei Weiterleitungen
SPF ist im Kern eine Liste erlaubter IP-Adressen. Der Eintrag besagt beispielsweise: „IP 1.2.3.4 darf für example.com senden.“ Das funktioniert gut, bis ein Empfänger eine automatische Weiterleitung einrichtet.
Sie schicken eine Rechnung an client@smallbiz.com. Der Kunde leitet sämtliche Nachrichten an client@gmail.com weiter. Gmail sieht nun eine Verbindung von der IP von smallbiz.com und nicht von Ihrer IP. Da smallbiz.com nicht in Ihrem SPF-Eintrag steht, schlägt die Prüfung fehl. Wenn Sie sich allein auf SPF verlassen, kann die weitergeleitete Nachricht im Spam landen oder abgewiesen werden. Damit sie die Weiterleitung übersteht, muss die DKIM-Signatur gültig bleiben, wobei auch dies keine Zustellung in den Posteingang garantiert. Die vollständige Einrichtung erklärt unser Leitfaden zum SPF-Eintrag.
DKIM: Das Problem der Domain-Ausrichtung
DMARC prüft zweierlei: ob SPF oder DKIM, beschrieben in RFC 6376, erfolgreich war und ob die verwendeten Domains ausgerichtet sind. Ausrichtung bedeutet, dass die Domain im From-Header zu den technischen Header-Domains passt, also zum Return-Path bei SPF oder zum Wert d= bei DKIM.
Ein typischer Problemfall im Support: Sie versenden über ein CRM wie Zendesk oder HubSpot als support@yourcompany.com. Das CRM verarbeitet Rückläufer, daher lautet der Return-Path bounces.zendesk.com und die SPF-Ausrichtung schlägt fehl. Ohne eigenen CNAME signiert DKIM zudem mit d=zendesk.com, wodurch auch die DKIM-Ausrichtung scheitert. Technisch ist die Nachricht authentifiziert, denn Zendesk hat sie versendet und signiert. DMARC erkennt jedoch kein Verfahren, dessen Domain zu Ihrer Domain passt. Bei der Richtlinie p=reject wird eine solche Nachricht wahrscheinlich abgewiesen.
Die Grenze von 10 DNS-Abfragen
SPF, definiert in RFC 7208, hat eine feste Obergrenze von 10 DNS-Abfragen pro Prüfung. Agenturen mit Kunden, die zahlreiche SaaS-Dienste verwenden, kennen dieses Problem. Google Workspace allein kann im Beispiel 4 Abfragen beanspruchen. Kommen Mailchimp, HubSpot, ein Ticketsystem und ein Personaltool hinzu, sieht der Eintrag etwa so aus:
v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com ~all
Jedes include: löst eine DNS-Abfrage aus, und der eingebundene Eintrag kann weitere Einbindungen enthalten. Wird die Gesamtzahl von 10 überschritten, antwortet der empfangende Server mit PermError. Praktisch gilt SPF damit als nicht bestanden. Der Versuch, alle Dienste vollständig einzutragen, kann die Authentifizierung also unbeabsichtigt außer Kraft setzen.
Versteckte Hürden jenseits von SPF, DKIM und DMARC
Neben den drei großen Verfahren gibt es technische Anforderungen ohne griffige Marketingnamen, die Nachrichten ebenso schnell blockieren können.
FCrDNS, vorwärts bestätigtes Reverse DNS
Jede sendende IP benötigt einen PTR-Eintrag, also Reverse DNS, der auf einen Hostnamen verweist. Dieser Hostname wiederum muss einen A-Eintrag besitzen, der auf die ursprüngliche IP zurückzeigt. Die Prüfung in beide Richtungen weist die Kontrolle über die Infrastruktur nach. Wenn Sie eine Cloud-VM bereitstellen, Postfix installieren und ohne PTR-Eintrag versenden, kann Gmail die Quelle als verdächtig einstufen und sofort 550 5.7.1 zurückgeben. Die konkrete Reaktion hängt vom Anbieter und von der Reputation ab.
RFC 8058: Abmeldung mit einem Klick
Seit Juni 2024 reicht bei Marketingmails ein Link in der Fußzeile für die Vorgaben großer Anbieter möglicherweise nicht mehr aus. Die Nachricht muss zwei bestimmte Header enthalten:
List-Unsubscribe: <https://example.com/unsub>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Der HTTPS-Endpunkt muss eine POST-Anfrage und nicht GET akzeptieren. Anti-Spam-Bots prüfen E-Mails, indem sie Links „anklicken“. Löst ein GET-Aufruf die Abmeldung aus, können Bots echte Nutzer versehentlich austragen. Ist der Ausstieg hingegen schwer zu finden, wählen Empfänger eher „Spam melden“ und bringen Sie näher an die Beschwerdegrenze von 0.3%.
Die 0.3%-Klippe: Wie Reputation wirtschaftlich wirkt
Perfektes SPF, DKIM und DMARC, fehlerfreies FCrDNS und korrekte Header helfen nicht, wenn Empfänger Ihre Inhalte nicht haben möchten.
Eine der entscheidenden Kennzahlen ist die Spam-Beschwerderate. Der Richtwert liegt bei 0.3%, also 3 Beschwerden pro 1,000 E-Mails. Bei einer Überschreitung kann Google die Zustellung stark einschränken oder die Domain blockieren. Berechnung und Folgen richten sich nach den jeweils aktuellen Vorgaben des Anbieters.
Die Yahoo-Falle beim Posteingang als Nenner
Yahoo kann die Spamrate anhand der im Posteingang angekommenen Nachrichten und nicht anhand der Gesamtzahl berechnen. Sie versenden 1,000 E-Mails. Ihre Domain-Reputation ist bereits angeschlagen, daher landen 900 im Spam und nur 100 im Posteingang. Eine Person beschwert sich. Die Rechnung lautet: 1/100 = 1.0%, also 3x so viel wie der genannte Grenzwert. Eine einzige Beschwerde kann damit einen negativen Kreislauf verstärken, aus dem man nur schwer wieder herauskommt.
Das Problem mit dem störenden Nachbarn
Selbst bei korrekt eingerichtetem SPF, DKIM und DMARC werden Ihre Nachrichten auf gewöhnlichem Shared Hosting oder einer günstigen „unbegrenzten“ E-Mail-Plattform möglicherweise über dieselbe IP wie die E-Mails Tausender anderer Kunden versendet. Verschickt einer davon Krypto-Betrug, kann Spamhaus die IP auf eine Blockliste setzen. Dann werden auch Ihre Nachrichten blockiert. Sie selbst haben nichts falsch gemacht, teilen sich aber die Infrastruktur-Reputation mit einem problematischen Nachbarn.
| Versandart | Wer die Reputation kontrolliert | Geeignet für |
|---|---|---|
| Geteilte IP (die meisten ESPs) | Der Anbieter, Sie sind von dessen Kontrolle über andere Nutzer abhängig | Absender mit geringem Volumen, die den Maßnahmen des Anbieters vertrauen |
| Managed SMTP (TrekMail Starter/Pro) | TrekMail, wir setzen strenge Anti-Spam-Regeln durch und sperren schlechte Absender | Unternehmen, die einen verwalteten Versand wünschen |
| Eigenes SMTP (TrekMail Free + kostenpflichtige Tarife) | Sie, durch Anbindung dedizierter IPs von Amazon SES, SendGrid oder Mailgun | Agenturen und Absender mit hohem Volumen, die vollständige Trennung wünschen |
Die Freitags-Checkliste für SPF, DKIM und DMARC
1. Header prüfen: Senden Sie eine Nachricht an ein persönliches Gmail-Konto. Öffnen Sie sie, klicken Sie auf die drei Punkte und wählen Sie die Anzeige des Originals. Suchen Sie nach Authentication-Results. Waren SPF und DKIM erfolgreich? Stimmt die Domain unter dkim= mit der Domain unter header.from überein? Falls nicht, liegt ein Ausrichtungsproblem vor.
2. FCrDNS prüfen: Führen Sie dig -x <your-sending-ip> aus. Liefert der Befehl einen Hostnamen? Führen Sie anschließend dig <that-hostname> aus. Wird die ursprüngliche IP zurückgegeben? Wenn sich der Kreis nicht schließt, stoppen Sie den Versand und korrigieren Sie DNS.
3. Nachrichtenströme trennen: Senden Sie Marketingmails nicht über Ihre primäre Unternehmensdomain. Nutzen Sie team@company.com für persönliche Geschäftskommunikation und newsletter@marketing.company.com für Kampagnen. Erreicht die Marketing-Subdomain die Grenze von 0.3%, ist die Hauptdomain meist weniger direkt betroffen, wobei Subdomains nicht bei jedem Anbieter eine vollständige Reputationsisolation bieten.
4. Mehr erfahren: Praktische Schritte zur Wiederherstellung finden Sie in unserem Leitfaden zur Absenderreputation und in der ausführlichen Erklärung zur Reputation von E-Mail-Domains.
TrekMail-Tarife
| Tarif | Preis | Authentifizierungsfunktion |
|---|---|---|
| Free | $0 | Eigenes SMTP, vollständige IP-Kontrolle (keine Karte erforderlich) |
| Starter | $3.50/mo | Managed SMTP, automatische DKIM-Erstellung |
| Pro | $10/mo | Mehrere Domains, Dashboard zur DNS-Validierung |
| Agency | .25/mo | Gemeinsamer Speicherpool, DNS-Massenkonfiguration, verwaltete Reputation |
Alle kostenpflichtigen Tarife: 14-tägige Testphase, Karte erforderlich. Free: keine Karte. Preise und Leistungsumfang können sich ändern, prüfen Sie daher vor der Buchung die aktuellen Angaben.
Fazit
SPF, DKIM und DMARC sind keine einmalige Aufgabe, sondern eine laufende betriebliche Anforderung. Erfolgreiche Authentifizierungsprüfungen sind lediglich die Eintrittskarte. Damit Nachrichten tatsächlich im Posteingang bleiben, brauchen Sie eine strikte Domain-Ausrichtung, einwandfreie Netzwerkhygiene einschließlich FCrDNS und Headern zur Abmeldung mit einem Klick sowie eine Reputationsstrategie, die Sie vor den Folgen anderer Nutzer derselben IP schützt. Verlassen Sie sich nicht auf Standardeinstellungen, sondern kontrollieren und prüfen Sie Ihre Infrastruktur fortlaufend.
Grüne Häkchen bei SPF, DKIM und DMARC sind die Eintrittskarte, nicht das Ziel. TrekMail kostenlos testen und die eigene E-Mail-Authentifizierung wirklich kontrollieren.