Google und andere Provider zwingen zum handeln

Unter anderem Gmail lehnt verstärkt Mails ohne gültigen DKIM-Eintrag und ohne SPF Eintrag ab, eine Zustellung an Empfänger bei Gmail ist somit nicht mehr möglich. Gmail setzt für den Empfang von E-Mails nun das DKIM-Verfahren zwingend voraus. (Nicht nur Gmail, sondern viele andere grosse Mail-Anbieter folgenden dieser Forcierung.) Dies muss nun bei jeder Absender Domain gesetzt sein.

Der Ablehnungsgrund von Gmail sieht dann in der Regel so aus:

host gmail-smtp-in.l.google.com[XXX.XXX.XXX.XXX] said:
550-5.7.26 This mail is unauthenticated, which poses a security risk to the
550-5.7.26 sender and Gmail users, and has been blocked. The sender must
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
550-5.7.26 DKIM checks did not pass and SPF check for [domain.de] didn ot
550-5.7.26 pass with ip: [195.30.XXX.XXX]. The sender should visit
550-5.7.26 https://support.google.com/mail/answer/81126#authentication for
550 5.7.26 instructions on setting up authentication.

DKIM, SPF, DMARC – Was war das nochmals bitte alles?

Stell dir vor, deine E-Mails sind wie Partygäste, und DKIM, SPF und DMARC sind die Türsteher, die sicherstellen, dass keine unerwünschten Eindringlinge auf deiner E-Mail-Party erscheinen.

SPF (Sender Policy Framework): SPF ist wie der erste Türsteher an deiner Party. Er überprüft die Gästeliste (in diesem Fall die Liste der erlaubten E-Mail-Server) und stellt sicher, dass nur die E-Mails reinkommen, die von einem autorisierten Absender-Server gesendet wurden. Wenn jemand versucht, eine E-Mail von einem nicht autorisierten Server zu senden, sagt der Türsteher: „Sorry, du stehst nicht auf der Liste. Abgelehnt!“

DKIM (DomainKeys Identified Mail): DKIM ist der zweite Türsteher und gleichzeitig der Sicherheitsfreak, der jede Einladung (E-Mail) auf Authentizität prüft. Er checkt die digitale Signatur der E-Mail und stellt sicher, dass sie nicht manipuliert wurde. Das ist so, als würde er den Briefumschlag aufbrechen und den geheimen Stempel auf der Einladung kontrollieren. Wenn der Stempel echt ist, sagt er: „Okay, du bist wirklich eingeladen. Komm rein!“ Wenn nicht, fliegt die E-Mail raus.

DMARC (Domain-based Message Authentication, Reporting & Conformance): DMARC ist der Chef der Türsteher und überwacht, ob SPF und DKIM ihre Arbeit richtig machen. Er legt die Regeln fest, wie mit verdächtigen E-Mails umzugehen ist, und erstattet dir Bericht darüber, wer versucht hat, unberechtigt auf deine Party zu kommen. Er entscheidet, ob verdächtige E-Mails in den Spam-Ordner wandern, komplett abgelehnt werden oder weitergeleitet werden. Er ist wie der Partykoordinator, der dafür sorgt, dass nur die echten Gäste Spaß haben, während die Störenfriede draußen bleiben.

Zusammen sorgen SPF, DKIM und DMARC dafür, dass deine E-Mail-Party sicher und frei von Spam, Phishing und anderen unerwünschten Eindringlingen bleibt.

Sender Policy Framework (SPF)

Das Sender Policy Framework (SPF) ist ein Verfahren, mit dem das Fälschen der Absenderadresse einer E-Mail verhindert werden soll, genauer das Versenden von E-Mail über nicht legitimierte Mail Transfer Agents (MTAs) (Mail-Server) unterbindet.

Bob fragt den SPF-Eintrag von Alice ab, der besagt, dass legitime Mail der Domain alice  ausschließlich von der Alice zugeordneten IP-Adresse kommen darf. Bob stellt einen nicht übereinstimmenden SPF-Eintrag fest und verwirft den Spam, anstatt ihn weiterzuleiten.

Beispiel SPF-Eintrag

Welche SPF Mechanismen bestehen?

Potenzielle Probleme, welche entstehen können

• Probleme bei Mail-Umleitung:
  Das empfangende System sieht in diesem Fall die Domain des Absenders in Verbindung mit der IP-Adresse des umleitenden Systems. Letzteres wird jedoch typischerweise nicht von den SPF-Regeln erfasst sein, sodass eine solche Mail bei einer SPF-Prüfung als unautorisiert eingestuft wird.
  SRS adressiert dieses Problem, indem es die Absenderadresse der weitergeleiteten E-Mails umschreibt. Die umgeschriebene Adresse stellt sicher, dass der Weiterleitungsserver als autorisierter Sender für die E-Mail erscheint, während gleichzeitig eine Möglichkeit geboten wird, die ursprüngliche Absenderadresse zu rekonstruieren. Dies hilft, die Kompatibilität mit SPF zu gewährleisten und die Zustellbarkeit von weitergeleiteten E-Mails zu verbessern. Microsoft hat SRS im September 2023 implementiert. Der Hersteller der IronPort hat leider keine Ambitionen dieses einzuführen.
  
• Probleme beim Versand über Webformulare:
  Das Problem betrifft Webformulare auf Websites, die es erlauben, eine E-Mail-Adresse als Absender anzugeben. Wenn jemand ein solches Formular ausfüllt und seine E-Mail-Adresse angibt, dann versucht das Webformular, eine E-Mail zu versenden, die so aussieht, als käme sie direkt von der Person, die das Formular ausgefüllt hat. Dies kann zu Problemen führen, wenn die angegebene Domain ein SPF (Sender Policy Framework) verwendet, das darauf ausgelegt ist, zu überprüfen, ob eingehende E-Mails tatsächlich von einem autorisierten Server der angegebenen Domain gesendet wurden. Da der Server des Webseitenbetreibers, der das Formular versendet, nicht als autorisierter Sender für die Domain der Absenderadresse gelistet ist, kann die E-Mail als SPF-Verstoß markiert und möglicherweise nicht zugestellt werden. Webserver sollten entsprechend ebenfalls berücksichtigt werden, bei der entsprechenden Autorisierung.

Behandeln der Problematik durch DKIM & DMARC

DomainKeys Identified Mail (DKIM) und Domain-based Message Authentication, Reporting, and Conformance (DMARC) sind beide Technologien, die entwickelt wurden, um die Authentizität von E-Mail-Nachrichten zu überprüfen und E-Mail-Spoofing sowie Phishing zu bekämpfen. Sie ergänzen das Sender Policy Framework (SPF) und bieten zusammen einen robusten Schutz gegen die Missbrauch von E-Mail-Systemen.

FAQ zu SPF

Können mehrere SPF-Einträge in unterschiedlichen TXT-Records veröffentlich werden?

Nein. Die Veröffentlichung muss in einem TXT-Record erfolgen. Mehrere Mechanismen können kombiniert werden, müssen aber in einem TXT-Record erfolgen.

Wie viele SPF-Einträge kann ich haben pro Domain?

Theoretisch unbegrenzt.  Es darf nicht mehr als 10 Lookups, also verkettete abfragen ohne Ergebnisse geben und es gilt ein Limit  von 255 Zeichen pro Sting, welches jedoch auf 2048 Zeichen durch Splitten des Strings erweitert werden kann.

DKIM

• DKIM steht für DomainKeys Identified Mail.
• E-Mail-Authentifizierungssystem, das mit Hilfe von kryptografischen Signaturen Integrität und Unleugbarkeit gewährleistet.
• Zusammen mit DMARC kann es helfen, eine robuste Infrastruktur zum Schutz vor Spoofing für Ihre E-Mails aufzubauen.
• Das DKIM-Protokoll erstellt eine kryptografische Signatur für jede Nachricht, die an die Empfänger gesendet wird, sowie eine Domänensignatur, die dem Nachrichtenkopf hinzugefügt wird.
• Anhand dieser Signatur kann der Empfänger überprüfen, ob die Nachricht tatsächlich von dem Inhaber der Domäne und nicht von einer anderen Person gesendet wurde.
• Sie verifiziert auch, dass die Nachricht auf ihrem Weg vom Absender zum Empfänger nicht manipuliert wurde.

Das System des Empfängers verfügt über einen privaten Key, dessen Public Key im öffentlichen DNS in Form eines TXT-Records publiziert ist. Mit Hilfe des Private-Keys signiert der Sender die Mail.

Der Empfänger bzw. dessen System ist in der Lage durch den öffentlichen Schüssel im DNS der Senderdomain, die Signatur zu prüfen. Grundlage von DKIM ist die Anwendung eines Schlüsselpaars, das aus einem privaten und einem öffentlichen Schlüssel besteht, ähnlich wie bei der asymmetrischen Verschlüsselung.

DKIM-Record

Wichtig für DKIM ist, dass pro Sendeumgebung je eine Pärchen bestehend aus Private-Key und Public-Key benötigt wird. Dies bedeutet, dass Exchange Online, das OnPremise GW sowie etwaige 3rd-Party Sendeumgebungen, wie bspw. Newsletter-Systeme wie MailChimp oder ähnliche je ein eigenes Pärchen benötigen.

Die Publikation unterschiedlicher Pärchen bzw. Separierung der unterschiedlichen Mail-Verandsysteme findet statt über sogenannte „Selectors“.

Wenn einen bestehender DKIM-Datensatz unter s1._domainkey.domain.com haben (wobei s1 der gewählte Selektor ist), können NICHT mehrere Datensätze für domain.com mit s1 als Selektor erstellt werden. So müssen neuen Einträge für domain.com jedes Mal auf eindeutige Selektorwerte verweisen (z. B. s2, s3, s4, s5 usw.), wie unten gezeigt: 

  s2._domainkey.domain.com
  s3._domainkey.domain.com
  s4._domainkey.domain.com
  s5._domainkey.domain.com

DKIM Signatur im Mail-Header für Selector „big-email“

v=1; a=rsa-sha256; d=example.com; s=big-email; h=from:to:subject; bh=uMixy0BsCqhbru4fqPZQdeZY5Pq865sNAnOAxNgUS0s=; b=LiIvJeRyqMo0gngiCygwpiKphJjYezb5kXBKCNj8DqRVcCk7obK6OUg4o+EufEbB tRYQfQhgIkx5m70IqA6dP+DBZUcsJyS9C+vm2xRK7qyHi2hUFpYS5pkeiNVoQk/Wk4w ZG4tu/g+OA49mS7VX+64FXr79MPwOMRRmJ3lNwJU=

Aufbau DKIM Signatur
v=: Zeigt die DKIM-Version an.
d=: Domainname des Absenders.
s=: Selektor für die DNS-Eintragsuche auf dem empfangenden Server.
h=: Liste der Header-Felder für die Signaturerstellung.
bh=: Hash des E-Mail-Textes für die Signaturberechnung.
a=: Algorithmus für die Signaturberechnung und Hash-Erzeugung.
b=: Digitale Signatur, erzeugt aus h und bh und mit dem privaten Schlüssel signiert.

DKIM Key im eigenen DNS veröffentlichen per TXT

DKIM Key per CNAME veröffentlichen

Probleme / Limitierung von DKIM

• DKIM-Signaturprobleme: Wenn eine E-Mail weitergeleitet oder umgeleitet wird, ändert sich möglicherweise der Header oder der Inhalt der Nachricht. Dies kann dazu führen, dass die ursprüngliche DKIM-Signatur ungültig wird oder nicht mehr verifiziert werden kann, da sie nicht mehr mit dem aktualisierten Inhalt übereinstimmt

• Header-Änderungen: Bei Weiterleitungen oder Umleitungen können E-Mail-Header wie „From“ und „To“ geändert werden. Wenn diese Header-Felder Teil der DKIM-Signatur sind, kann dies zu Problemen führen, da die Signatur nicht mehr mit den aktualisierten Header-Informationen übereinstimmt.

• Brechen der Signaturkette: Wenn eine E-Mail weitergeleitet wird und der ursprüngliche DKIM-Signaturheader nicht korrekt behandelt wird oder verloren geht, kann dies dazu führen, dass die Signaturkette gebrochen wird. Infolgedessen kann der empfangende Server die Echtheit der E-Mail nicht mehr verifizieren.

Behandlung des Problems bei Umleitung

• SRS (Sender Rewriting Scheme) kann dazu beitragen, Probleme bei der Umleitung von E-Mails in Bezug auf DKIM zu lösen, ähnlich wie bei SPF (Sender Policy Framework). DKIM-Signaturen umfassen normalerweise den „From:“-Header der ursprünglichen E-Mail, und wenn eine E-Mail weitergeleitet oder umgeleitet wird, kann sich dieser Header ändern, was die Gültigkeit der DKIM-Signatur beeinträchtigen kann.
• Durch die Anwendung von SRS wird die Absenderadresse (Return-Path) in weitergeleiteten E-Mails so umgeschrieben, dass sie von der weiterleitenden Domain stammt, anstatt von der ursprünglichen Quelldomain. Dadurch bleibt die Gültigkeit der DKIM-Signatur erhalten, da die umgeschriebene Absenderadresse nun mit der DKIM-Signatur übereinstimmt.
• Auf diese Weise trägt SRS dazu bei, die Integrität der DKIM-Signatur während des Weiterleitungsprozesses zu bewahren und sicherzustellen, dass die E-Mail erfolgreich authentifiziert werden kann, ohne die DKIM-Konformität zu beeinträchtigen

Leider ist die IronPort nicht in der Lage SRS und ARC verwenden. Der Hersteller hat leider keine Ambitionen dies zu implantieren. 

FAQ zu DKIM

FAQ für Servicebetreiber / Webmasters