Startseite » DKIM, DMARC, SPF » DKIM, DMARC, SPF – Jetzt handeln!

DKIM, DMARC, SPF – Jetzt handeln!

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.

DKIM-, SPF- und DMARC-Checker

Dieses Tool überprüft, ob Ihre Domain korrekt für DKIM, SPF und DMARC konfiguriert ist. Geben Sie Ihre Domain ein und klicken Sie auf "Prüfen", um die Ergebnisse zu sehen.

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?

MechanismenErläuterung
allDieser Mechanismus passt auf alle IP-Adressen. Er wird typischerweise am Ende eines SPF-Records verwendet, oft mit einem Qualifikator, um die Standardbehandlung für nicht anderweitig erfasste Adressen festzulegen.
includeErlaubt die Einbeziehung der SPF-Regeln einer anderen Domain. Dies wird oft verwendet, wenn E-Mail-Dienste von Drittanbietern genutzt werden.
Ipv4, ipv6Spezifizieren  IP-Adressbereiche, die E-Mails im Namen der Domain senden dürfen.
A,MX,PTRDiese Mechanismen erlauben E-Mails von Hosts, die durch A-, MX- bzw. PTR-DNS-Einträge für die Domain spezifiziert sind.
SPF Mechanismen

Welche SPF Qualifikationen steuern die Behandlung?

MechanismenErläuterung
+ (Pass)Impliziert eine positive Übereinstimmung; E-Mails werden akzeptiert. Dies ist der Standardqualifikator, wenn kein anderer angegeben ist.
– (Fail)Signalisiert, dass E-Mails, die den Bedingungen entsprechen, abgelehnt werden sollten. Direktive definiert nicht autorisierte Sender.
~  (SoftFail)Gibt an, dass E-Mails, die den Bedingungen entsprechen, verdächtig sind, aber nicht unbedingt abgelehnt werden sollten. die Direktive definiert nicht autorisierte Sender, der Empfänger soll diesen Fehlschlag aber großzügig behandeln
?  (Neutral)Zeigt an, dass keine spezifische Politik angewandt wird; das Ergebnis der Überprüfung sollte weder als pass noch als fail betrachtet werden. Direktive definiert Sender, über deren Legitimität nichts ausgesagt werden soll
SPF Qualifikationen
Sinnvolle Qualifikatoren
  • – (Fail): Dieser Qualifikator ist sinnvoll für Organisationen, die eine strenge E-Mail-Sicherheitspolitik verfolgen und genau wissen, welche Mailserver E-Mails in ihrem Namen senden dürfen. Er hilft, Spoofing und Phishing effektiv zu verhindern, indem er eine klare Anweisung gibt, E-Mails, die nicht den SPF-Regeln entsprechen, strikt abzulehnen.
  • ~ (Softfail): Geeignet für Organisationen in der Übergangsphase zur Implementierung von SPF oder wenn Unsicherheit über alle genutzten Mailserver besteht. Softfail signalisiert Empfängern, dass eine E-Mail verdächtig ist, ohne sie direkt abzuweisen, was nützlich sein kann, um Fehlkonfigurationen ohne schwerwiegende Konsequenzen zu identifizieren.
Weniger sinnvolle Qualifikatoren
  • + (Pass): Da dies der Standardqualifikator ist, wird er selten explizit verwendet, außer in spezifischen Fällen, in denen man explizit die Akzeptanz bestimmter E-Mails signalisieren möchte. In den meisten SPF-Records wird die positive Autorisierung implizit durch das Fehlen eines Qualifikators oder durch die direkte Angabe der Mechanismen erreicht.
  • ? (Neutral): Dieser Qualifikator ist in der Praxis weniger nützlich, da er keine definitive Aussage über die Legitimität von E-Mails macht. Er kann in Situationen verwendet werden, in denen eine Organisation keine spezifische SPF-Politik durchsetzen möchte oder kann, aber seine Anwendung sollte wohlüberlegt sein, da er weder zur Sicherheit beiträgt noch Spoofing effektiv verhindert.

Best Practices

  • Für die meisten Organisationen ist es sinnvoll, mit ~all (Softfail) zu beginnen, um die SPF-Konfiguration zu testen und sicherzustellen, dass legitime E-Mails nicht versehentlich blockiert werden. Nach einer gründlichen Überprüfung und sobald man sich der Vollständigkeit und Korrektheit der SPF-Konfiguration sicher ist, sollte auf -all (Fail) umgestellt werden, um eine stärkere Schutzmaßnahme gegen unautorisierte E-Mail-Sendungen zu bieten.
  • Der Einsatz von ?all (Neutral) wird in der Regel nicht empfohlen, da er die Wirksamkeit des SPF-Records zur Bekämpfung von E-Mail-Spoofing stark einschränkt.
  • Die explizite Verwendung von + als Qualifikator ist meist überflüssig, es sei denn, es gibt spezielle Gründe, bestimmte Direktiven hervorzuheben.

Limitierungen des SPF-Eintrags

  • DNS-Lookup-Limit für Include-Verkettungen: Es gibt ein Limit von 10 DNS-Lookups, die während der Überprüfung eines SPF-Records durchgeführt werden dürfen. Dies umfasst Lookups, die durch include, a, mx, ptr Mechanismen und Modifikatoren verursacht werden. Wenn mehr als 10 solche Lookups benötigt werden, resultiert dies in einem Fehler. Die ip4 und ip6 Mechanismen zählen nicht zum DNS-Lookup-Limit, da sie direkt IP-Adressen spezifizieren und keine zusätzlichen DNS-Abfragen erfordern.
  • Maximale Länge des SPF-Records: Der gesamte SPF-Record, einschliesslich IPv4- oder IPv6-Einträge (ip4 oder ip6), ist durch die maximale Länge von DNS-TXT-Records begrenzt, die 255 Zeichen pro String beträgt, aber mehrere Strings können in einem einzelnen DNS-Eintrag verwendet werden, sodass die effektive Obergrenze 2048 Zeichen beträgt.
  • Nur Absender-IP-Adresse wird geprüft:
    SPF überprüft, ob die IP-Adresse des sendenden Servers in der SPF-Record der Absenderdomain autorisiert ist. Dies schützt nicht gegen Fälle, in denen der „From“-Header der E-Mail manipuliert wurde, um den Empfänger zu täuschen, da SPF nicht die im „From“-Header angegebene Domain überprüft.
  • Limitierte Informationen über den Absender
    SPF bietet keine Methode zur Überprüfung der Integrität des Inhalts der Nachricht. Ein Angreifer könnte theoretisch von einer autorisierten IP-Adresse senden, aber den Inhalt der Nachricht manipulieren.
SPF Maximum Character Limit
Bad SPF Record: Single string over 255 charactersGood SPF Record: Multiple strings under 255 characters
“v=spf1 ip4:64.20.227.128/28 ip4:208.123.79.32 ip4:208.123.79.1 ip4:208.123.79.2 ip4:208.123.79.3 ip4:208.123.79.4 ip4:208.123.79.5 ip4:208.123.79.6 ip4:208.123.79.7 ip4:208.123.79.8 ip4:208.123.79.15 ip4:208.123.79.14 ip4:208.123.79.13 ip4:208.123.79.12 ip4:208.123.79.11 ip4:208.123.79.10 ip4:208.123.79.9 ip4:208.123.79.16 ip4:208.123.79.17 include:_spf.google.com include:_spf.ladesk.com -all”“v=spf1 ip4:64.20.227.128/28 ip4:208.123.79.32 ip4:208.123.79.1 ip4:208.123.79.2 ip4:208.123.79.3 ip4:208.123.79.4 ip4:208.123.79.5 ip4:208.123.79.6 ip4:208.123.79.7 ip4:208.123.79.8 ip4:208.123.79.15 ip4:208.123.79.14 ip4:208.123.79.13 ip4:208.123.79.12” “ ip4:208.123.79.11 ip4:208.123.79.10 ip4:208.123.79.9 ip4:208.123.79.16 ip4:208.123.79.17 include:_spf.google.com include:_spf.ladesk.com -all”

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

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

Ja. Dies ist auch erforderlich. Pro Selektor erfolgt die Veröffentlichung in einen je eigenen TXT-Record.

Wofür brauche ich mehrere Selektoren?

Nicht alle Dienste erlauben das Nutzen eines eigenen Private-Keys sondern der Serviceprovider stellt diese aus. Damit mehrere Serviceprovider für eine übergreifende Domain autorisiert werden können, bedarf in der Regel jeder Service / autorisierter Sender einen eigenen Eintrag, damit ein jeweiliges Pärchen aus Public- und Privatekey gegeben ist.

Macht DKIM die Verwendung von SPF überflüssig?

Nein, DKIM macht SPF nicht überflüssig. DKIM gewährleistet die Integrität von E-Mails, aber nicht die Autorisierung des Absenders, wie es SPF tut. Es ist wichtig zu beachten, dass nicht alle Empfänger DKIM berücksichtigen. Daher bleibt in solchen Fällen die Frage der Autorisierung des Absenders unbeantwortet. Aus diesem Grund

Muss ich DKIM zwingend implementieren?

Ja. Google und viele andere „Big-Player“ bestehen seit März 2024 auf eine DKIM signierte Mail. Insbesondere bei grösseren Mail-Sendeumgebungen, wie jene von Newsletter-Systemen wie MailChimp aber auch ein grösseres Versendevolumen, wie bei der Stadt Zürich zu rechnen ist, ist die Verwendung unausweichlich um eine Mailzustellzuverlässigkeit zu gewährleisten.

FAQ für Servicebetreiber / Webmasters

Ich habe eine Website und möchte über diese Mails versenden – Was muss ich berücksichtigen?

Mails sollten im Namen der Organisation verschickt werden – Nicht im Namen des Senders des Kontaktformulars. Das Feld „ reply-to“ darf wiederum den Namen des Senders aufweisen, somit erhält der urspüngliche Sender eine Mail beim Antworten auf seine Mail.

Über welche Mail-Infrastruktur versende ich?

Sofern die Application es unterstützt, sollte der Versand über Exchange Online oulook.office.com:587 mittels O-Auth Authentifizierungerfolgen. Hierfür eigenet sich das Client-Secret-Verfahren einer AppRegistierung: https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth.

Wenn der Web- oder Applicationsserver E-Mails senden soll, müssen SPF- und DKIM-Konfigurationen berücksichtigt werden. Es ist wichtig, die verantwortlichen Stellen innerhalb der Stadt Zürich zu kontaktieren, um die entsprechenden DNS-Einträge vorzunehmen. Vor dem Versand von DKIM-signierten E-Mails muss der entsprechende Public-Key veröffentlicht werden.

Welche Herausforderung bestehen in Zusammenhang mit Exchange Server 2016 / 2019?

Solange der Nachrichtenfluss zentral über ein Mail-Gateway, bspw. IronPort stattfindet, kann an der Stelle eine DKIM-Signierung erfolgen – Diese betrifft dann nicht nur Mails, welche von EXO stammen, sondern auch solche, die von Exchange 2016/2019 versendet werden. Nativ unterstützt Exchange 2016/2019 kein DIKIM. Es ist nur über 3rd-Party oder über ein GW implementierbar.

Foto des Autors
Autor

Nils Lappenbusch

Ich bin seit 2012 in der IT tätig. Seit 2020 bin ich Microsoft certified Trainer (MCT). Meine Schwerpunkte momentan liegen im Bereich Microsoft 365, Exchange 2016/2019. Die Begleitung der Einführung und Migration in die Cloud sind für mich spannende Aufgaben.

3 Gedanken zu „DKIM, DMARC, SPF – Jetzt handeln!“

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.