E-Mails professionell versenden mit SPF, DKIM, DMARC und Co.

E-Mails zu versenden ist einfach. Und soll auch einfach sein. Die E-Mail wurde als offener Standard erfunden. Für ein Netzwerk, in dem jeder jeden kennt und jedem vertraut. So kann beispielsweise der Absender einer E-Mail festlegen, im Namen welcher Domain eine E-Mail versendet werden soll. Das hat bis heute viele praktische Vorteile. So darf z.B. nicht nur Ihr Mailserver E-Mails im Namen der Domain Ihres Unternehmen versenden, sondern auch

  • der Newsletterdienst
  • das CRM (Insightly, Salesforce, etc.)
  • die Webseite mit dem Kontaktformular
  • oder das Ticketsystem.

Anhand der vertrauenswürdigen Absenderadresse erkennen Ihre Kunden schnell, dass die E-Mail von Ihrem Unternehmen versendet wurde. Doch es gibt einen Haken:

Ohne weitergehende Maßnahmen ist es auch unberechtigten Dritten wie z.B. Betrügern und Hackern möglich, Ihnen und anderen E-Mails mit Ihrer Original-Mailadresse zu senden.

Das ist nicht nur ein Sicherheitsrisiko für diejenigen, die Ihrer Domain vertrauen. Denn eine Domain, in deren Namen Spam, Malware oder Phishingmails versendet werden, sinkt auch in der Reputation bei Spamfiltern und vor allem (!) Kunden.

SPF – Sender Policy Framework:
Wie die Besucherliste für Türsteher

Mit einem SPF-Eintrag kann der Inhaber einer Domain festlegen, welche Systeme im Namen einer Domain E-Mails versenden dürfen. Stellt das E-Mail-Programm des Empfängers fest, dass der Absender nicht berechtigt ist, E-Mails zu versenden, enden diese im Spamordner oder es wird zumindest eine Warnung angezeigt.

Technisch handelt sich bei einem SPF-Eintrag um einen einfachen TXT-Record im DNS der jeweiligen Domain. Er ist wie folgt aufgebaut:

v=spf1 include:_spf.google.com a ip4:9.9.9.9 -all

Er startet immer mit „v=spf1“.

Nach einem Leerzeichen beginnt bereits die Auflistung der zulässigen Absender-Systeme. In diesem Beispiel steht hier „include:_spf.google.com“ als Verweis auf einen anderen SPF-Eintrag, der von Google gepflegt wird. Er enthält alle IP-Adressen, über die Google E-Mails versendet. Jeder, der E-Mails im Namen seiner Domain über Google Workspace versendet, sollte diesen Include in seinen SPF-Eintrag aufnehmen.

Der nächste Bestandteil, das „a“, ist ein Platzhalter für den A-Record DNS-Eintrag der Domain. Üblicherweise also die Webseite. Dadurch sind dann auch von PHP-Skripten versendete E-Mails validiert.

Anschließend ist noch die IP-Adresse 9.9.9.9 als zulässiger Absender definiert. Das könnte beispielsweise ein System sein, das eine Web-Applikation hostet.

Es ist nur ein SPF-Eintrag pro Domain-Ebene zulässig. SPF wird nicht auf Subdomains „vererbt“, daher muss für jede Subdomain ein separater SPF-Eintrag erstellt werden.

Etwas tricky bei SPF ist, dass SPF nicht die für den Empfänger üblicherweise sichtbare Absenderdomain prüft, sondern die einer versteckten zweiten Absenderadresse.

Dem sogenannten „Envelope from“ oder „Return-Path“, der von Mailprogrammen meist nicht als Absender angezeigt wird, sondern nur für Mailserver relevant ist. An diese Mailadresse werden beispielsweise Bounces, also Unzustellbarkeitsberichte versendet.

Da die „Envelope From“-Adresse sich von der dem Empfänger angezeigten Absenderadresse unterscheiden kann, besteht mit SPF nur ein eingeschränkter Schutz vor E-Mail-Spoofing.

Der Spamfilter oder Mailserver des Empfängers nimmt die Prüfung des SPF-Eintrags vor. Er entscheidet letztlich auch, inwieweit er die Informationen in seine Entscheidung, ob es sich um Spam handelt oder nicht, einfließen lässt.

Bei automatisierten Weiterleitungen von E-Mails wirkt es für den letztendlichen Empfänger so, als ob ein unberechtigtes System die E-Mail versendet hat. Daher sind weitere Standards nötig, damit E-Mails auch in solchen Fällen zuverlässig zugestellt werden können.

DKIM – DomainKeys Identified Mail:
E-Mails digital unterschreiben

Mithilfe von DKIM werden E-Mails digital signiert. Das ist wie eine Versiegelung: der Empfänger kann prüfen, ob das Siegel echt ist und ob jemand unterwegs etwas manipuliert, also z.B. den Text der E-Mail verändert hat. Ein “gebrochenes Siegel” führt beim Empfänger zu einer Warnung im Mail-Programm oder sorgt für eine Klassifizierung als Spam.

Dabei wird die E-Mail mit einem privaten Schlüssel kryptografisch signiert, den nur die berechtigten Mailserver kennen dürfen. Das geschieht automatisch im Hintergrund, sobald DKIM aktiviert und eingerichtet wurde. Der zugehörige öffentliche Schlüssel wird als TXT-Record im DNS der jeweiligen Domain hinterlegt. So hat jeder Spamfilter oder Mailserver, der eine E-Mail empfängt, die Möglichkeit, die digitale Signatur zu prüfen.

Für die eigene Domain können beliebig viele öffentliche DKIM-Schlüssel hinterlegt werden. Jeder Dienst (Google Mail, Salesforce, Webseite,…) nutzt seinen eigenen privaten Schlüssel.

Um die verschiedenen DKIM-Schlüssel zu unterscheiden, verwendet man sogenannte „Selektoren“. Unter dem in der DKIM-Signatur angegebenen Selektor wird im DNS nach dem dazugehörigen öffentlichen Schlüssel gesucht.

Ein Vorteil von DKIM gegenüber SPF ist, dass die DKIM-Signatur bei automatischen Weiterleitungen erhalten bleibt.

DMARC – Domain-based Message Authentication, Reporting and Conformance:
Der doppelte Check gegen Fälschungen

Damit SPF und DKIM wirksam gegen gefälschte Absenderdomains eingesetzt werden können, erfolgen mit Hilfe von DMARC noch zwei weitere Überprüfungen:

Check 1: Ist die im Return-Path (Envelope-From) angegebene Domain die gleiche Domain, die auch im Mailclient des Empfängers als Absenderdomain sichtbar ist? Und ist das System, das diese Mail versendet hat, durch SPF berechtigt im Namen dieser Domain E-Mails zu versenden?

Check 2: Ist die in der DKIM-Signatur angegebene Domain die gleiche, die auch im Mailclient des Empfängers als Absenderdomain sichtbar ist? Und ist die DKIM-Signatur gültig?

Wenn beide Fragen in einem der beiden Checks mit „Ja“ beantwortet werden können, dann ist der DMARC-Check erfolgreich bestanden.

Wird keiner der beiden Checks erfolgreich bestanden, kann der Eigentümer der jeweiligen Domain eine von drei Empfehlungen setzen, die von den meisten Spamfiltern und Mailservern auch respektiert und umgesetzt wird:

  1. None (Nichts tun, nur Monitoring)
  2. Quarantine (Mail soll im Spamordner landen)
  3. Reject (Mail soll abgewiesen werden)

Doch DMARC kann noch mehr:
Es wäre ja super, wenn der Inhaber einer Domain auch Rückmeldungen bekommt, welche Systeme im Namen seiner Domain E-Mails versenden. Und ob die abgesendeten E-Mails beim jeweiligen Empfänger auch den DMARC-Check bestehen.
Denn wenn die eigenen validen E-Mails den DMARC-Check nicht bestehen, kann das negative Auswirkungen auf die Zustellbarkeit der E-Mails haben.

Daher besteht die Möglichkeit, im DMARC-Eintrag (ebenfalls ein öffentlicher Eintrag im DNS der jeweiligen Domain) eine Mailadresse zu hinterlegen. An diese kann ein Mailserver, der eine oder mehrere E-Mail von einer Domain mit einem DMARC-Eintrag erhalten hat, sogenannte DMARC-Reports versenden.

In den Reports steht, wie viele E-Mails ein Mailserver von einer bestimmten Domain erhalten hat und wie viele davon den SPF-, DKIM- und DMARC-Check bestanden haben und wie viele nicht. Diese Informationen können für das Troubleshooting verwendet werden, um folgende Frage zu klären: Haben wir alle unsere Systeme im Hinblick auf DMARC korrekt eingerichtet?
Da es ständig Änderungen geben kann, macht es Sinn, die Reports dauerhaft im Blick zu behalten.

Zusätzlich erkennt man als Inhaber einer Domain anhand der DMARC-Reports auch, ob die Domain für E-Mail-Spoofing-Attacken missbraucht wird.

So ist der DMARC-Eintrag ausgebaut:

v=DMARC1; p=reject; rua=mailto:[email protected]

Er wird für den Hostnamen „_dmarc“ eingerichtet und vererbt sich auch an die Subdomains.

Hinter „p=„ wird definiert, wie mit E-Mails umgegangen werden soll, die den DMARC-Check nicht bestehen.

Hinter „rua=„ wird die Maildresse angegeben, an die die DMARC-Reports gesendet werden sollen. Dass sollte eine dediziert dafür eingerichtete Mailadresse sein oder die Mailadresse eines DMARC-Tools, das diese Reports automatisiert aufbereitet.

BIMI – Brand Indicators for Message Identification:
Ihr Firmenlogo in E-Mail-Programmen

BIMI ermöglicht, dass im Posteingang der E-Mail-Empfänger ein von den Domaininhabern registriertes Markenlogo angezeigt wird. Zwingende Voraussetzung ist, dass die jeweilige E-Mail den DMARC-Check bestanden hat.

Damit können Unternehmen im Posteingang der Empfänger positiv hervorstechen, für Vertrauen sorgen und die Öffnungsrate von Mails signifikant erhöhen. Die formellen Voraussetzungen sorgen für eine technisch verlässliche Zustellung.

Folgende Voraussetzungen müssen für die Anzeige des Logos erfüllt werden:

  1. Die Domain des Absenders
    nutzt DMARC mit einer Quarantine- oder Reject-Policy.
  2. Die jeweilige E-Mail
    besteht den DMARC-Check
  3. Der E-Mail-Provider sowie der Mailclient des Empfängers
    unterstützten die Anzeige von BIMI-Logos. Da sich der Standard noch in einer frühen Phase befindet, unterstützen es bislang nur wenige, wie z.B. Google Mail, Apple Mail und Yahoo.
  4. BIMI wurde für die Domain eingerichtet und ein von einer entsprechenden Zertifizierungsstelle signiertes Logo wurde bereitgestellt

Typische Probleme
bei SPF, DKIM und DMARC

Fehlerhafte Konfigurationen können dazu führen, dass eigentlich valide E-Mails beim Empfänger häufiger als Spam klassifiziert werden.

Hier sind einige Beispiele:

  • Mehrere SPF-Einträge auf einer Domain-Ebene
    Es ist nur ein SPF-Eintrag pro Domain-Ebene zulässig. Ansonsten weiß das empfangende System nicht, welcher der SPF-Einträge gültig ist. Zu beachten ist auch, dass SPF-Einträge nicht an Subdomains vererbt werden. Für Subdomains sind daher separate SPF-Einträge notwendig.
  • Es fehlen Systeme im SPF-Eintrag (z.B. Webserver)
    Viele Unternehmen haben keinen Überblick darüber, welche Systeme E-Mails im Namen ihrer Domain versenden dürfen. Durch die Auswertung von DMARC-Reports erhalten Unternehmen hier mehr Transparenz und können ihre SPF-Einträge entsprechend ergänzen.
  • Mehr als 10 DNS-Auflösungen in einem SPF-Eintrag. Um Mailserver bei der Überprüfung von E-Mails nicht übermäßig zu belasten, werden maximal 10 DNS-Auflösungen pro SPF-Eintrag unterstützt. Daher sollte der SPF-Eintrag nicht mit Includes überfrachtet werden. Auch ein Monitoring des SPF-Eintrags selbst ist empfehlenswert. Denn wenn einer der Includes weitere DNS-Namen ergänzt, wirkt sich das auch auf den eigenen SPF-Eintrag aus.
  • Der öffentliche DKIM-Schlüssel wird nicht im DNS hinterlegt
    Wer DKIM-Signaturen auf die eigenen Domains bei Mailservern oder Cloud-Diensten aktiviert, muss auch den dazugehörigen öffentlichen DKIM-Schlüssel im DNS der Domains hinterlegen. Ansonsten können die Empfänger die Signatur nicht überprüfen und der DKIM-Check schlägt fehl. Oft werden öffentliche DKIM-Schlüssel auch als CNAME-Eintrag hinterlegt.
  • Der verwendete E-Mailprovider unterstützt kein DKIM (z.B. GoDaddy, DomainFactory,…)
    In diesem Fall verbleibt als Schutz vor E-Mail-Spoofing oder als Grundlage für den DMARC-Check lediglich die Nutzung von SPF. Da SPF meist keine automatisierten Weiterleitungen übersteht, ist damit zu rechnen, dass E-Mails häufiger im Spamordner landen oder abgewiesen werden.
  • Häufig zu sehen ist, dass bei einer Domain ein DMARC-Eintrag angelegt wird, aber die DKIM-Signaturen der Newsletter- oder CRM-Dienste sind auf die Default-Domain der jeweiligen Anbieter ausgestellt. Da der versteckte Absender (Envelope-From) bei diesen Diensten ebenfalls mit einer anderen Domain sendet, schlagen in solchen Fällen dann meist beide Alignment-Checks (DKIM und SPF) fehl und damit auch der DMARC-Check.

Mit einem regelmäßigen Monitoring der DMARC-Reports und der DNS-Einträge können die oben genannten Probleme frühzeitig erkannt werden.

Google mit Workspace und Gmail
als Vorreiter

Nur bei wenigen Providern ist die Unterstützung von Standards wie DMARC so ausgeprägt wie bei Google.

Beispielsweise versenden die Google Mailserver DMARC-Reports. Das ist ein großer Troubleshooting-Vorteil für diejenigen, die Google als Mailservice nutzen. Denn wenn beispielsweise der Webserver nur E-Mails an eigene Domains sendet, die empfangenden Mailserver jedoch keine DMARC-Reports versenden, dann taucht der eigene Webserver nicht als versendendes System in den DMARC-Reports auf. Das erhöht das Risiko, dass der Webserver beispielsweise im SPF-Eintrag vergessen wird.

Google stellt auch ausführliche Anleitungen zur Konfiguration von DKIM und SPF zur Verfügung. Auf der Gmail Weboberfläche kann man sich anzeigen lassen, auf welche Domain die DKIM-Signatur in der E-Mail ausgestellt wurde.

Google respektiert auch die DMARC-Policies der Absenderdomains. Wenn die Policy auf „reject“ steht und der DMARC-Check einer E-Mail schlägt fehl, dann weißt Google diese Mail auch wirklich ab und schiebt sie nicht nur in den Spamordner. Das senkt das Risiko der Empfänger, auf E-Mails mit einem gefälschten Absender hereinzufallen.

Und Google gehört zu den Maildiensten, die das BIMI-Logo neben einer korrekt validierten E-Mail anzeigen.

Empfehlungen

SPF ist bereits heute weit verbreitet und immer mehr Mailprovider erwarten, dass eingehende und ausgehende E-Mails auch mit einer DKIM-Signatur versehen sind. Es gibt beispielsweise kaum noch einen Newsletter ohne DKIM-Signatur.

Wem die zuverlässige Zustellbarkeit von E-Mails oder der Schutz vor Missbrauch der eigenen Domain ein Anliegen ist, sollte sich zusätzlich DMARC beschäftigen und es zunächst im Monitoringmodus betreiben. Wenn aus den DMARC-Reports hervorgeht, dass SPF und DKIM durchgehend korrekt umgesetzt sind, kann die DMARC-Policy auf “quarantine” und später “reject” hochgestuft werden.

Dann ist auch eine wichtige Voraussetzung für den Einsatz von BIMI geschaffen. BIMI eignet sich aufgrund der Kosten eher für mittlere und größere Unternehmen. SPF, DKIM und DMARC sollten hingegen bei jeder Domain zum Einsatz kommen.

DMARC wird zusammen mit SPF und DKIM immer häufiger in Sicherheitsstandards als Anforderung genannt. Beispielsweise als Standardmaßnahme im IT-Grundschutz des BSI und beim Regelwerk PCI DSS 4.0 für alle Unternehmen, die Kreditkartendaten verarbeiten.

Ziehen Sie den Wechsel Ihres Hostinganbieters in betracht, wenn er wie GoDaddy und DomainFactory kein DKIM unterstützt.

Links und weitere Artikel

Externe Artikel zum Thema Mail-Sicherheit mit SPF, DKIM, DMARC

Hilfeartikel von Google

Diesen Artikel teilen

Über den Autor:

Avatar-Foto
Thomas Fauser ist IT-Sicherheitsexperte und unterstützt mit DMARC24 Unternehmen bei der fachgerechten Implementierung und dem Monitoring von SPF, DKIM und DMARC. DMARC24 | Thomas Fauser bei LinkedIn
Nach oben