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

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.

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.

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 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

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.

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.

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.