E-Mails landen im Spam? SPF, DKIM und DMARC verständlich erklärt und eingerichtet
Kontaktanfragen von der Website landen im Spam. Newsletter-Bestätigungen kommen nicht an. Gmail lehnt Mails mit einer DMARC-Fehlermeldung ab. Hinter diesen Problemen steckt meist dasselbe: Der Empfangsserver hat der Domain nicht vertraut, weil sie keine E-Mail-Authentifizierung nachweisen kann. SPF, DKIM und DMARC sind die drei DNS-Einträge, die diese Vertrauensfrage beantworten. Sie beweisen, dass eine Nachricht wirklich von deiner Domain stammt und unterwegs nicht manipuliert wurde, und bilden das technische Fundament für zuverlässiges E-Mail-Marketing.
Warum Mails im Spam landen
Ein empfangender Mailserver kann dem From-Feld einer E-Mail nicht einfach vertrauen. Dieses Feld lässt sich problemlos fälschen. Beim E-Mail-Spoofing schickt jemand Phishing-Mails mit deiner Unternehmensadresse als Absender, ohne jemals Zugang zu deinem Mailkonto gehabt zu haben. Empfänger sehen deinen Firmennamen, öffnen die Mail, und dein Ruf leidet.
Spam-Filter berücksichtigen neben dem Inhalt einer Mail vor allem die technische Reputation des Absenders: Ist der versendende Server bekannt? Ist er autorisiert? Stimmt die Signatur? Fehlen diese Nachweise, ist das Spam-Risiko für den Filter nicht von einer gefälschten Mail zu unterscheiden. SPF, DKIM und DMARC geben dem Empfangsserver die Mittel, genau das herauszufinden. SPF-, DKIM- und DMARC-Einträge hinterlegst du im DNS-Bereich deines Domain-Registrars oder DNS-Anbieters, nicht in den Einstellungen der Website selbst.
SPF: Welche Server dürfen für deine Domain senden?
SPF steht für Sender Policy Framework. Es ist ein TXT-Eintrag im DNS deiner Domain, der auflistet, welche Mailserver und IP-Adressen berechtigt sind, Mails im Namen dieser Domain zu verschicken.
Erhält ein Empfangsserver eine Mail von beispiel.de, ruft er den SPF-Eintrag dieser Domain ab und gleicht die IP-Adresse des sendenden Servers mit der Liste ab. Stimmt die IP, gilt die Mail als SPF-authentifiziert. Eine Domain darf nur einen SPF-TXT-Record haben; mehrere Einträge sind unzulässig und führen zum Prüffehler.
Ein typischer SPF-Eintrag für eine Domain, die über Google Workspace und einen Newsletter-Dienst versendet:
v=spf1 include:_spf.google.com include:spf.deinnewsletterdienst.com ~all
Das ~all am Ende steht für SoftFail: Mails von nicht gelisteten Servern werden als verdächtig markiert, aber noch zugestellt. -all (HardFail) lehnt solche Mails direkt ab. Für den Einstieg empfiehlt sich ~all, bis alle Versandquellen sicher erfasst sind.
Ein technisches Limit ist dabei zu beachten: SPF erlaubt maximal zehn DNS-Lookups pro Prüfvorgang (RFC 7208, Abschnitt 4.6.4, 2014). Wer viele externe Dienste in seinen SPF-Eintrag einbindet, sollte dieses Limit prüfen. Wird es überschritten, gilt die SPF-Prüfung als fehlgeschlagen, unabhängig davon, ob der sendende Server eigentlich autorisiert wäre.
DKIM: Die kryptografische Signatur jeder Mail
DKIM steht für DomainKeys Identified Mail. Es fügt jeder ausgehenden E-Mail eine digitale Signatur hinzu. Dein Mailserver signiert die Nachricht mit einem privaten Schlüssel. Der zugehörige öffentliche Schlüssel liegt als TXT-Eintrag im DNS.
Erhält ein Empfangsserver eine Mail, ruft er den öffentlichen Schlüssel ab und prüft die Signatur. Stimmt sie, bestätigt das zwei Dinge: Die Mail stammt tatsächlich von der angegebenen Domain, und der Inhalt wurde unterwegs nicht verändert.
Ein DKIM-Eintrag im DNS sieht vereinfacht so aus:
google._domainkey.beispiel.de TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
Der Präfix vor ._domainkey ist der DKIM-Selektor. Verschiedene Dienste (Mailserver, Newsletter-Tools, Transaktionsdienste) verwenden eigene Selektoren, erkennbar am Präfix. Eine Domain darf mehrere DKIM-Einträge mit unterschiedlichen Selektoren führen. Das ist ausdrücklich erlaubt und nötig, sobald mehrere Dienste im Namen der Domain versenden.
DMARC: Die Richtlinie, die SPF und DKIM verbindet
DMARC steht für Domain-based Message Authentication, Reporting, and Conformance. Es baut auf SPF und DKIM auf und beantwortet die Frage, die die beiden allein offenlassen: Was soll mit einer Mail passieren, die den SPF- oder DKIM-Check nicht besteht?
Ein DMARC-Eintrag legt eine Policy fest und definiert eine Adresse, an die Empfangsserver täglich Berichte schicken. Diese Berichte zeigen, wer im Namen deiner Domain E-Mails versendet und wie viele davon die Checks bestehen:
_dmarc.beispiel.de TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
DMARC prüft außerdem die Ausrichtung (Alignment): Die sichtbare From-Adresse der Mail muss zur Domain im SPF- oder DKIM-Eintrag passen. Damit wird sichergestellt, dass SPF und DKIM nicht nur für eine versteckte technische Domain gelten, sondern für die Absenderadresse, die der Empfänger tatsächlich sieht.
none, quarantine oder reject: Wann welche DMARC-Policy sinnvoll ist
Viele Domaininhaber setzen direkt p=reject und blockieren damit versehentlich eigene Mails, weil SPF oder DKIM noch nicht vollständig konfiguriert waren. Die schrittweise Vorgehensweise ist zuverlässiger:
SituationDMARC-PolicyWarum
Du willst zunächst verstehen, wer im Namen deiner Domain sendet, ohne etwas zu blockieren. SPF und DKIM sind noch nicht oder nur teilweise eingerichtet.
Mails werden trotz Authentifizierungsfehlern zugestellt. Die täglichen DMARC-Berichte (rua) zeigen alle Absenderquellen. Kein Risiko für den laufenden Mailbetrieb.
SPF und DKIM sind eingerichtet, du willst die Konfiguration aber noch testen und sicherstellen, dass keine legitime Quelle fehlt.
Fehlgeschlagene Mails landen im Spam-Ordner statt komplett abgewiesen zu werden. Gibt Spielraum, Konfigurationsfehler zu beheben, bevor echte Mails verloren gehen.
Alle legitimen Versandquellen sind erfasst. SPF und DKIM laufen stabil, und du hast die DMARC-Berichte einige Wochen ausgewertet, ohne unerwartete Absender zu finden.
Nicht authentifizierte Mails werden direkt abgewiesen. Stärkster Schutz vor Spoofing. Nur aktivieren, wenn die Einrichtung vollständig und getestet ist.
Für Unternehmen, die mehrere Versanddienste nutzen (Firmenmailserver, Newsletter-Tool, CRM-Automatisierung), lohnt es sich, diesen Schritt in die Online-Marketing-Strategie einzuplanen: SPF und DKIM für jeden Dienst einrichten, Berichte eine bis zwei Wochen auswerten, dann erst auf p=quarantine wechseln, danach auf p=reject.
Was Gmail und Yahoo heute von Versendern verlangen
Seit Februar 2024 gelten verschärfte Anforderungen für Massenversender. Google hat für Absender, die täglich 5.000 oder mehr Mails an Gmail-Konten schicken, verbindliche Vorgaben eingeführt (Google, E-Mail-Absenderrichtlinien, 2024, support.google.com/mail/answer/81126): SPF und DKIM müssen für die Absenderdomain eingerichtet sein, ein DMARC-Eintrag mit mindestens p=none muss vorhanden sein, und Marketing-Mails müssen eine Abmeldefunktion mit einem Klick anbieten. Weitere Anbieter, darunter Yahoo, folgten mit vergleichbaren Vorgaben.
Für Unternehmen, die eine Webflow-Website für ihr Unternehmen betreiben und darüber Newsletter oder automatische Benachrichtigungen versenden, ist das keine rein technische Frage: Ohne korrekte Authentifizierung landen diese Mails direkt im Spam oder werden von Gmail-Servern abgelehnt.
Auch für kleinere Versandmengen gilt: Gmail und andere große Anbieter legen intern höhere Spam-Schwellen für Domains an, die keine Authentifizierung nachweisen. Eine korrekte Einrichtung verbessert die Zustellrate unabhängig von der Versandmenge.
Formular-Mails von Webflow zustellbar machen
Beim Einsatz von Webflow trifft man auf eine Besonderheit, die bei der SPF/DKIM-Einrichtung leicht übersehen wird: Webflow-Formulare verschicken Benachrichtigungs-E-Mails über Webflows eigene Versandinfrastruktur, nicht über den eigenen Mailserver. Die From-Adresse dieser Benachrichtigungen zeigt eine Webflow-Domain, nicht deine eigene. Damit liegt die Absenderreputation bei Webflow, und die DNS-Einträge deiner Domain haben keinen Einfluss auf diese Mails.
Für einfache Benachrichtigungen an dich als Seitenbetreiber ist das kein Problem: Du erhältst die Einreichung per Mail, und die Reply-To-Adresse enthält die E-Mail-Adresse des Formular-Ausfüllers, sodass du direkt antworten kannst. Kritisch wird es, wenn du Besuchern Bestätigungsmails direkt aus deiner eigenen Domain senden willst (also die automatische Antwort: "Wir haben deine Anfrage erhalten" mit deiner Firmendomain als Absender).
Dafür ist ein Transaktionsdienst nötig. Die Anbindung läuft in diesen Schritten ab:
- Konto bei einem Transaktionsdienst einrichten. Postmark, SendGrid und Mailgun sind verbreitete Optionen, die mit Webflow-Automatisierungen zusammenarbeiten.
- Eigene Domain im Dashboard des Dienstes hinzufügen. Der Dienst stellt daraufhin spezifische SPF-Includes und DKIM-DNS-Einträge zur Verfügung.
- Diese DNS-Einträge beim Domain-Registrar oder DNS-Provider eintragen. Der SPF-Include des Transaktionsdienstes kommt zum bestehenden SPF-Eintrag der Domain hinzu. Der DKIM-Eintrag wird mit dem Selektor des Dienstes als separater TXT-Record angelegt.
- Den Transaktionsdienst mit Webflow verbinden, entweder über Webflow Logic oder ein Automatisierungstool wie Make oder Zapier, das bei einer Formulareinreichung eine Bestätigungsmail über den Dienst verschickt.
- Eine Testmail senden und mit einem Prüftool verifizieren, dass SPF und DKIM korrekt ausgewertet werden, bevor die Funktion für Besucher aktiviert wird.
Das From-Feld der ausgehenden Mail zeigt dann deine eigene Domain. Die DNS-Einträge des Transaktionsdienstes beweisen dem Empfangsserver, dass diese Mail legitim ist und korrekt signiert wurde.
SPF, DKIM und DMARC überprüfen: Drei kostenlose Tools
Diese drei Tools helfen dabei, die Einrichtung zu prüfen, bevor Mails in den produktiven Betrieb gehen:
- MXToolbox (mxtoolbox.com): Prüft SPF-, DKIM- und DMARC-Einträge direkt im DNS der Domain. Gibt konkrete Fehlermeldungen aus, wenn etwas fehlt oder falsch konfiguriert ist. Kostenlos ohne Registrierung nutzbar.
- mail-tester.com: Man sendet eine Testmail an eine temporäre Adresse, die das Tool bereitstellt. Danach bewertet es Authentifizierung, Spam-Score und technische Konfiguration gemeinsam in einem Bericht mit Punktezahl.
- Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx): Prüft die DNS-Konfiguration einer Domain auf MX-, SPF-, DKIM- und DMARC-Einträge. Direkter Zugang ohne Registrierung, kostenlos von Google bereitgestellt.
Unabhängig davon, ob du Webflow oder WordPress als Plattform einsetzt: Diese Tools arbeiten domainbasiert und sind für jede technische Plattform geeignet. Besonders wichtig ist, die Prüfung nach jeder Änderung an DNS-Einträgen und nach dem Hinzufügen neuer Versanddienste zu wiederholen, da neue Dienste eigene SPF-Includes und DKIM-Selektoren mitbringen, die korrekt eingetragen sein müssen.
rev%20komprimiert%20(1).webp)
.jpg)
