SPF, DKIM, DMARC(Warum deine Newsletter im Spam landen)

Willkommen beim Marketing Techie Podcast, dem Podcast über die Technik hinter dem Online-Marketing. Verständlich erklärt, auch für Non-Techies. Mit Emilian Buza von trace5.co. In dieser Folge: SPF, DKIM, DMARC. Und warum deine Newsletter im Spam landen.

Am 3. Mai 1978 sendete ein Mann namens Gary Thuerk eine Werbemail. Sie gilt bis heute als die erste Spam-Mail der Geschichte.

Ja, richtig gehört. Tatsächlich gab es schon 1978 E-Mails. Und sie waren nicht einmal Neuheiten.

Schon seit Anfang der Siebzigerjahre konnte man Nachrichten von einem Computer zu einem anderen schicken. Und zwar im ARPANET. Das war ein Netz, das das US-Verteidigungsministerium finanziert hatte, um Großrechner an Universitäten und Forschungsinstituten miteinander zu verbinden, ein Vorläufer des heutigen Internets.

Nur war dieses Netz winzig. Ein paar tausend Menschen hatten eine Adresse darin. Fast alle waren Wissenschaftler, Techniker oder arbeiteten fürs Militär.

Gary Thuerk, Marketing-Manager bei DEC, der Digital Equipment Corporation, war einer von ihnen. DEC war damals einer der großen Computerhersteller. Wann immer es neue Rechner im Programm hatte, lud zu Vorführungen in Kalifornien ein. Und Thuerk dachte sich: Die Leute im ARPANET sind genau meine Zielgruppe. Warum schreibe ich nicht einfach alle an?

Einen Export aus einer Kundendatenbank gab es natürlich noch nicht. Es gab ein gedrucktes Verzeichnis. Also wurden rund 400 Adressen von Hand abgetippt. Und weil das Empfängerfeld nicht für so viele Adressen gebaut war, rutschte ein Teil davon in den Text der Mail. Die Leute öffneten also eine Nachricht, die mit einer endlosen Liste fremder Adressen anfing.

Der Ärger kam schnell. Die Behörde, die das Netz betrieb, nannte die Mail einen klaren Verstoß gegen die Nutzungsregeln. Das Netz sei für Regierungsarbeit da, nicht für Werbung. Thuerk hat später trotzdem behauptet, die Aktion habe Rechner für über zehn Millionen Dollar verkauft. Ob das stimmt, lässt sich schwer prüfen.

Für unser Thema ist an dieser Geschichte aber etwas anderes interessant. Jeder wusste, von wem die Mail kam. Absender? Gary Thuerk, DEC. Die Beschwerden landeten bei genau dem Richtigen.

Heute ist es umgekehrt. Wer heute Betrugsmails verschickt, schreibt nicht seinen eigenen Namen als Absender hinein. Er schreibt deinen hinein.

Und damit sind wir bei der Frage dieser Folge. Woher weiß ein Postfachanbieter wie Gmail eigentlich, ob eine Mail mit deinem Absender wirklich von dir kommt? Und warum hält er manchmal deinen eigenen Newsletter für eine Fälschung?

Und lass uns in das Thema dieser Folge mit einer Preisfrage einsteigen – auch wenn du außer Erkenntnis nichts zu gewinnen hast.

Also.

Du bekommst eine Mail von einem Onlineshop, bei dem du gestern etwas bestellt hast.

Der Inhalt: „Ihre Zahlung ist fehlgeschlagen. Bitte hinterlegen Sie Ihre Kartendaten erneut.“

Du schaust auf den Absender. Da steht tatsächlich die Adresse des Shops.

Nicht irgendeine ähnlich aussehende Adresse. Nicht bloß der Name des Shops über einer fremden Mailadresse. Sondern genau die richtige Adresse.

Jetzt die Frage: Kann die Mail trotzdem von einem Betrüger kommen?

Was meinst du?

Hier die Auflösung: Ja.

Denn tatsächlich war und ist es erstaunlich einfach, eine E-Mail mit einer falschen Absenderadresse zu senden.

Das betrifft gefälschte Zahlungsaufforderungen genauso wie Newsletter oder Bestellbestätigungen.

Und das stellt E-Mail-Anbieter vor ein großes Problem: Wie kann ein empfangender Mailanbieter herausfinden, ob jemand diese Absenderdomain überhaupt verwenden darf?

Dabei helfen drei Abkürzungen, die du heute in dieser Folge kennenlernen wirst: SPF, DKIM und DMARC.

Alle drei gehen dich als Online-Marketer etwas an.

Warum?

Weil es passieren kann, dass deine eigenen E-Mails eine dieser entscheidenden Prüfungen nicht bestehen. Genau wie die Mail eines Betrügers. Und dann können sie im Spam landen oder abgelehnt werden.

Wenn du also verstehen willst, warum deine Newsletter möglicherweise nicht bei deiner Liste ankommen, solltest du dir diese Folge besser anhören.

Aber lass uns zunächst noch einmal das zugrunde liegende Problem anschauen.

Also. Nehmen wir einen Shop mit der Domain deinshop.de. Bei einer Mailadresse ist die Domain der Teil hinter dem At-Zeichen.

Der Shop verschickt jede Woche einen Newsletter.

Und unser Betrüger möchte Mails verschicken, die genauso aussehen, als kämen sie von diesem Shop.

Wie du jetzt schon weißt, könnte er das. Aber warum?

Um das zu verstehen, musst du eine Besonderheit der E-Mail kennen: Beim E-Mail-Versand gibt es zwei verschiedene Absenderangaben.

Die eine ist eine Adresse für Rückmeldungen bei Zustellproblemen.

Die andere ist die Absenderadresse, die dir die Mail anzeigt.

Warum braucht es zwei?

Stell dir vor, dein Shop verschickt über ein Newsletter-Tool zehntausend Mails. Einige Empfängeradressen existieren nicht mehr. Das Tool soll erkennen, welche das sind.

Deshalb kann es beim Versand eine eigene Adresse für solche Fehlermeldungen angeben.

Im sichtbaren Absender steht trotzdem newsletter@deinshop.de.

Die Kunden sehen deinen Shop. Die Rückmeldungen über gescheiterte Zustellungen gehen an das Tool.

Das ist völlig normal.

Wir merken uns also schon einmal: Es gibt die Rücksendeadresse für Zustellfehler und die sichtbare Absenderadresse. Sie können unterschiedlich sein.

Wie kommen diese Angaben nun zum Empfänger?

E-Mails werden über Mailserver gesendet und empfangen. Das sind Computer mit Software, die Mails annimmt und weitergibt.

Schickst du eine Mail an eine Gmail-Adresse, verbindet sich der versendende Server mit einem Server von Google. Dabei überträgt er die Nachricht und die beiden Absenderangaben.

Und beide Adressen kann der Absender zunächst selbst eintragen.

Unser Betrüger kann also newsletter@deinshop.de hineinschreiben.

Google muss selbst herausfinden, ob es dieser Angabe vertraut.

Nur: Wen soll Google fragen?

Den Server, der die verdächtige Mail gerade anliefert?

„Darfst du wirklich für diesen Shop verschicken?“

Der würde einfach Ja sagen.

Google braucht eine Auskunft, die der Betrüger nicht selbst für deinshop.de festlegen kann.

Und dafür gibt es das DNS.

Das DNS liefert zu einem Domainnamen die passende technische Serveradresse. Wir haben darüber in Episode 11 des Marketing Techie Podcasts gesprochen.

Es kann aber auch andere Informationen zu einer Domain bereithalten.

Wer die DNS-Einstellungen von deinshop.de verwaltet, kann dort beispielsweise veröffentlichen, welche Server Mails für diese Domain verschicken dürfen.

Google kann diese Angaben nachschlagen. Unser Betrüger kann sie für deinshop.de normalerweise nicht ändern.

Damit haben wir eine Grundlage für die erste Prüfung.

Sie heißt SPF.

SPF beantwortet die Frage: Darf der Server, der diese Mail gerade anliefert, für die Domain der Rücksendeadresse verschicken?

Der Domainbetreiber veröffentlicht dafür im DNS, welche Versandserver erlaubt sind.

Google erkennt den anliefernden Server an seiner technischen Adresse und prüft, ob er dazugehört.

Nehmen wir an, der Betrüger hat zunächst in beide Absenderangaben newsletter@deinshop.de geschrieben.

Google schaut im DNS von deinshop.de nach.

Dort sind die vorgesehenen Versandserver erlaubt. Der Server des Betrügers gehört nicht dazu.

Wenn die veröffentlichten Regeln alle anderen Server ausdrücklich ausschließen, fällt die Prüfung durch.

Erwischt.

Könnte man meinen.

Aber unser Betrüger hat aufgepasst.

SPF hat die Domain der Rücksendeadresse geprüft.

Nicht die Domain der sichtbaren Absenderadresse.

Also besorgt er sich eine eigene Domain. Nennen wir sie betrug-xyz.com.

Für diese Domain erlaubt er seinen eigenen Server im DNS.

Dann verwendet er eine Rücksendeadresse unter betrug-xyz.com.

In die sichtbare Absenderadresse schreibt er weiterhin newsletter@deinshop.de.

Was passiert?

Google prüft, ob der Server für betrug-xyz.com verschicken darf.

Ja, darf er.

SPF bestanden.

Und in der Mail steht als sichtbarer Absender weiterhin dein Shop.

SPF hat dabei keinen Fehler gemacht. Es hat genau die Frage beantwortet, für die es gebaut wurde.

Nur war das noch nicht die ganze Frage, die uns interessiert.

Stellt sich natürlich die Frage: Warum prüft SPF denn nur die Rücksende-Adresse und nicht beide?

Weil SPF für eine engere Aufgabe entwickelt wurde: Es prüft die Berechtigung des Servers für die Domain, die beim eigentlichen Transport als Absender angegeben wird. Das ist die Rücksendeadresse. Die sichtbare Absenderadresse steht dagegen in der Nachricht selbst. Und die wird von SPF eben nicht erfasst.

Darum gibt es noch weitere Verfahren, wie das DKIM.

Hier berechnet dein Newsletter-Tool vor dem Versand einen Code und hängt ihn an die Mail an.

Dieser Code wird aus dem Mailtext und weiteren Angaben berechnet, darunter der sichtbaren Absenderadresse. Zusätzlich verwendet das Tool geheime Daten, die beim Versanddienst bleiben.

Deshalb kann ein Betrüger nicht einfach einen passenden neuen Code für deine Domain erzeugen.

Diesen angehängten Code nennt man die DKIM-Signatur.

In der Mail steht außerdem, für welche Domain die Signatur erstellt wurde.

Google ruft aus dem DNS dieser Domain die Angaben ab, mit denen sich der Code überprüfen lässt. Sie ermöglichen die Kontrolle, reichen aber nicht aus, um selbst passende neue Codes zu erstellen.

Dann prüft Google: Passt dieser Code zu dieser Nachricht und zu den Angaben im DNS?

Wenn unterwegs beispielsweise jemand den Zahlungslink im geschützten Mailtext ausgetauscht hat, passt der Code nicht mehr.

DKIM kann also bestätigen, für welche Domain die Nachricht mit diesem Code versehen wurde und ob die geschützten Inhalte seitdem verändert wurden.

Aber unser Betrüger muss gar keinen Code für deinshop.de erzeugen.

Er richtet DKIM einfach für seine eigene Domain ein.

Für betrug-xyz.com.

In der sichtbaren Absenderadresse steht weiterhin newsletter@deinshop.de.

Google prüft die Signatur.

Sie ist gültig.

DKIM bestanden.

Wie kann das sein, wenn DKIM die sichtbare Absenderangabe doch berücksichtigt?

Weil DKIM prüft, ob sie noch zum berechneten Code passt. Es verlangt allein aber nicht, dass ihre Domain dieselbe ist wie die Domain der Signatur.

Unser Betrüger hat die fremde Adresse von Anfang an in die Nachricht geschrieben und den Code für seine eigene Domain erzeugt.

Der Code ist gültig.

Die behauptete Verbindung zum Shop ist es nicht.

Jetzt haben wir zwei bestandene Prüfungen.

SPF sagt: Dieser Server darf für betrug-xyz.com verschicken.

DKIM sagt: Die Signatur für betrug-xyz.com ist gültig.

Aber dem Menschen wird deinshop.de als Absenderdomain präsentiert.

Genau das muss verhindert werden.

Und dafür gibt es DMARC.

DMARC nimmt die Domain der sichtbaren Absenderadresse als Ausgangspunkt.

In unserem Beispiel deinshop.de.

Dann fragt es: Hat mindestens eine der beiden Prüfungen bestanden, und passt deren Domain zu dieser sichtbaren Domain?

Also entweder: SPF bestanden, und die Domain der Rücksendeadresse passt?

Oder: DKIM bestanden, und die Domain der Signatur passt?

Einer dieser beiden passenden Nachweise reicht für DMARC. Auch passende Unterteilungen wie news.deinshop.de können dabei dazugehören.

Aber betrug-xyz.com und deinshop.de passen eindeutig nicht zusammen.

Unser Betrüger besteht zwar SPF und DKIM für seine eigene Domain.

DMARC besteht er mit der gefälschten Shopadresse trotzdem nicht.

Das ist der entscheidende Punkt.

Es genügt nicht, irgendeine gültige Signatur oder irgendeinen erlaubten Versandserver vorzuweisen. Einer dieser Nachweise muss zur sichtbaren Absenderdomain passen.

Der Betreiber von deinshop.de kann außerdem im DNS veröffentlichen, wie empfangende Anbieter mit Nachrichten umgehen sollen, die DMARC nicht bestehen.

Dafür gibt es drei grundlegende Einstellungen.

None heißt: zunächst beobachten, ohne wegen DMARC eine besondere Behandlung zu verlangen.

Quarantine heißt: Solche Nachrichten bitte als verdächtig behandeln, typischerweise im Spamordner.

Reject heißt: Solche Nachrichten bitte ablehnen.

Die endgültige Entscheidung bleibt beim empfangenden Anbieter.

Zusätzlich kann der Domainbetreiber Berichte anfordern. Darin sieht er, woher Nachrichten mit seiner Absenderdomain kamen und wie die Prüfungen ausgegangen sind.

Eine wichtige Grenze bleibt trotzdem.

DMARC verhindert nicht, dass sich jemand eine ähnlich aussehende Domain besorgt. Etwa deinshop-service.de.

Und es verhindert auch nicht, dass jemand als Anzeigenamen „Deinshop Kundenservice“ einträgt, obwohl dahinter eine ganz andere Mailadresse steckt.

DMARC schützt die Verwendung deiner Domain. Es macht nicht jede Nachricht, die irgendwie nach deiner Marke aussieht, automatisch vertrauenswürdig.

So.

Jetzt lassen wir den Betrüger für einen Moment stehen.

Und wechseln zu deinem Marketingteam.

Ihr führt ein neues CRM ein, also ein System zur Verwaltung eurer Kundenkontakte.

Der Anbieter dieses Tools hat die Domain crm-anbieter.de. Eure eigene Domain lautet deinshop.de.

Im CRM tragt ihr als Absender newsletter@deinshop.de ein. Damit soll der Empfänger eure Mail sehen.

Aber diese Adresse einzutragen, reicht noch nicht aus, um den Versand für eure Domain vollständig einzurichten.

Nehmen wir an, das CRM verwendet für Zustellfehler weiterhin seine eigene Adresse: ruecklaeufer@crm-anbieter.de.

Google prüft SPF und stellt fest: Dieser Server darf für crm-anbieter.de verschicken.

SPF bestanden. Aber für crm-anbieter.de.

Auch den DKIM-Code erstellt das CRM in unserem Beispiel für crm-anbieter.de. Eure eigene Domain wurde dafür noch nicht eingerichtet.

Google prüft den Code.

DKIM bestanden. Wieder für crm-anbieter.de.

Dem Empfänger wird aber newsletter@deinshop.de als Absender angezeigt.

Genau da liegt das Problem: Die beiden bestandenen Prüfungen bestätigen crm-anbieter.de. Die Mail behauptet aber, von deinshop.de zu kommen.

DMARC verlangt, dass mindestens einer der erfolgreichen Nachweise zu deinshop.de passt. Das ist hier nicht der Fall. Die erfolgreichen Nachweise passen nur zu crm-anbieter.de, nicht aber zur Absender-Domain deinshop.de.

Kommt dir das bekannt vor?

Das ist genau die fehlende Verbindung, die wir gerade beim Betrüger gesehen haben.

Eure Nachricht ist ehrlich gemeint. Sie stammt tatsächlich aus eurem Unternehmen.

Aber der passende technische Nachweis fehlt.

DMARC kann eure Absicht nicht erkennen.

Je nach Regeln des Empfängers und eurer DMARC-Einstellung kann die Mail deshalb im Spam landen oder abgelehnt werden.

Die Lösung liegt meistens in einem Bereich des Tools, der Domain-Authentifizierung oder Absenderdomain einrichten heißt.

Dort lässt du das Tool für deine eigene Domain einrichten. Dazu gehören Angaben im DNS, die der Anbieter vorgibt.

Damit kann das Tool anschließend den passenden Nachweis für eure Domain mitliefern.

Du musst das als Marketer nicht selbst einrichten können. Aber du solltest wissen: Die gewünschte Absenderadresse einzutragen, reicht allein nicht.

Warum ist das für Newsletter inzwischen so wichtig?

Weil große Mailanbieter konkrete Anforderungen an Versender stellen.

Google verlangt für große Versender an persönliche Gmail-Postfächer SPF, DKIM und DMARC. Andere große Anbieter haben ähnliche Anforderungen.

„Für DMARC reicht einer“ heißt also nicht, dass du die übrigen Versandanforderungen ignorieren kannst.

Und damit kein falsches Bild entsteht: Diese drei Verfahren garantieren keinen Platz im Posteingang.

Wenn sich viele Empfänger beschweren und auf „Spam melden“ klicken, können deine Mails trotz korrekt eingerichteter Verfahren im Spam landen.

Für deinen Alltag heißt das: Wenn Empfänger deine Mails nicht wollen, lässt sich dieses Problem nicht durch perfekte DNS-Einträge lösen.

Was kannst du nach dieser Folge also konkret tun?

Beginne mit einer Bestandsaufnahme.

Welche Systeme verschicken überhaupt Mails mit eurer Domain als sichtbarem Absender?

Das Newsletter-Tool fällt dir wahrscheinlich sofort ein.

Aber was ist mit dem Shopsystem? Dem CRM? Dem Support-Tool? Der Terminbuchung? Dem Rechnungsprogramm?

Gerade die weniger sichtbaren Versandwege werden leicht vergessen.

Lass prüfen, ob eure Domain in diesen Tools richtig eingerichtet ist und ob tatsächlich verschickte Nachrichten die Prüfungen bestehen.

Und bevor ihr über DMARC die Ablehnung durchgefallener Nachrichten verlangt, muss klar sein, dass eure eigenen Versandwege zuverlässig funktionieren.

Wer zu früh auf reject schaltet, kann damit die Ablehnung eigener wichtiger Mails auslösen.

Schließlich sollte die Einrichtung eurer Absenderdomain ein fester Teil jeder neuen Tool-Einführung werden.

Bevor die erste echte Kampagne verschickt wird.

Bevor die erste Rechnung rausgeht.

Wenn du aus dieser Folge nur einen Zusammenhang mitnimmst, dann diesen:

Eine Mail kann SPF und DKIM bestehen und trotzdem eine fremde sichtbare Absenderdomain verwenden.

DMARC prüft, ob mindestens einer der erfolgreichen Nachweise zu dieser Domain passt.

Und genau diese Verbindung musst du auch deinen eigenen Versandtools ermöglichen.

Mach deshalb als Erstes die Bestandsaufnahme.

Vielleicht ist alles sauber eingerichtet.

Vielleicht findest du aber auch ein Tool, das seit Monaten in eurem Namen verschickt, ohne den passenden Nachweis mitzuliefern.

Dann weißt du endlich, wo du ansetzen kannst.

Du merkst: Manchmal liegt das Problem mit deiner Kampagne an einer technischen Einstellung, die du bisher gar nicht auf dem Schirm hattest.

Und das gilt auch für deine Website.

Was passiert eigentlich, wenn jemand sie aufruft? Was übernimmt der Browser? Was kommt vom Server? Und wo kommen die Skripte ins Spiel, die du für dein Marketing einsetzt?

Genau darum geht es in meinem Kurs „Was passiert im Browser“.

Ich zeige dir diese Abläufe Schritt für Schritt, ohne IT-Vorkenntnisse vorauszusetzen. Damit du besser verstehst, was hinter deiner Website passiert, und bei Problemen gezielter nachfragen kannst.

Den Kurs findest du auf trace5.co.

Wenn du Lust hast reinzuschauen, freue ich mich.

Wenn nicht: Auch gut - und bis zur nächsten Folge!