Spam und UCE - Filter: DKIM
Andere Bezeichnungen: Identified Internet Mail, IIM, DomainKeys Identified Mail
Viele Spammer verstecken sich hinter falschen Absenderadresse, was letztlich den angeblichen Absender stört. Rückläufer, unzustellbarkeitsmeldungen aber auch die Frage der Authentizität u.a. kosten Zeit und Bandbreite. Daher möchte der Absender sicherstellen, dass niemand mit seinem Namen etwas sendet. Hierzu gibt es mehrere Ansätze.
So nutzen SPF und RMX die IP-Adresse des einliefernden Gateways zur Validierung. Problem hierbei ist aber, dass eben ein Server und nicht die Mail selbst validiert werden kann. DKIM ist ein Ansatz, bei der die Mail digital signiert wird, so dass jede Station und sogar der letzte Mailserver prüfen kann, ob die Mail verändert wurde und die Domäne des Absender korrekt ist. Nebenbei wird so sichergestellt, dass die Mail wirklich vom Mailserver des Absenders signiert werden musste.
Exchange Online kann Mails per DKIM signieren
und das sollten Sie möglichst auch tun:
DKIM mit Office 365
Exchange On-Premises kann es nicht selbst. Aber auf
https://GitHub.com/Pro/dkim-exchange gibt es einen
Transport Agent und vorgeschaltete Spamfilter wie z.B.
NoSpamProxy können dies
natürlich auch.
So funktioniert es
DKIM funktioniert über eine asymmetrische Verschlüsselung der kompletten Mail.
- PublicKey im DNS
Im DNS wird ein Public Key für die Domäne des Senders hinterlegt. Dazu wird entweder ein TXT oder der eigens definierte Resource Record (RR) "_domainkey" genutzt.
Hier eine Ausgabe von Yahoo, einer der treibenden Institutionen hinter Domainkey/DKIM. Interessant ist, dass viele andere Firmen, die DKIM angeblich können, per DNS keine Abfrage gestatten. Gerade Cisco hat z.B. noch keinen "_domainkey"-Eintrag (Stand 28. Mai 2007)
> set q=any > _domainkey.yahoo.com _domainkey.yahoo.com text = "t=y; o=~; n=http://antispam.yahoo.com/domainkeys" _domainkey.yahoo.com internet address = 66.94.234.13 _domainkey.yahoo.com internet address = 216.109.112.135
- Sender: Signierung der Mail (Body und Header)
Der sendende Mailserver signiert die Mail indem ein Hashwert gebildet und mit dem private Key verschlüsselt am Anfang des Headers addiert wird.
- Empfänger testet
Der annehmende Mailserver sieht anhand des Headereintrags diese Einstellung, liest den PublicKey per DNS aus und prüft die Signatur des Header. Passt sie, dann ist die Absenderadresse korrekt, ansonsten ist es ein Versuch mit einer falschen Absenderadresse zu senden.
Da im Header auch die "FROM"-Adresse des Absenders mit drin ist und der zum Public Key der Domäne passende Private Key sicher kein Spammer hat, kann niemand eine falsche FROM-Adresse verwenden. Und wenn schon einmal sicher ist, dass der Absender nicht gefälscht ist, dann lassen sich auch schnell Datenbanken mit "guten und schlechten" Absendern erstellen. Also eine Art Reputation für Absender.
Yahoo nutzt aktuell dieses Verfahren, bei dem ausgehende Mails mit einer Signatur gesendet werden.
Mit einer passenden Software könnten Sie dann prüfen, ob eine Mail, die angeblich von Yahoo kommt, auch wirklich von Yahoo ist. Das hilft, damit ein Spammer nicht mehr eine Yahoo Adresse fälscht.
Die Argumente
Was so einfach aussieht ist bei weitem nicht so einfach.
- Ende zu Ende Signatur
Der Absender signiert die Mail und der Empfänger prüft. Es ist dabei keine Erweiterung des SMTP-Standards erforderlich, da die komplette Verarbeitung Teil der "Mail" ist. Es ist daher auch nicht relevant, welche und wie viele Relays dazwischen sind. - Kostengünstig das keine CA
Jeder Mailversender kann sich selbst ein Schlüsselpaar erstellen, die Mails mit DKIM signieren und im DNS den dazu gehörigen Public Key bereit stellen. Das spart Kosten, da keine "teure" CA involviert sein muss. - Neuer Angriff: DNS-Spoofing
Allerdings kann damit wirklich jeder ohne Validierung Mails versenden, so lange er nur den Public Key im DNS unterbringen kann oder dem Empfänger eben das vorgaukelt. Bei DNS ist es nun mal so, dass ein Server nicht den DNS-Server der anderen Domäne fragt, sondern meist über Forwarder des Providers geht. Diesem System kommt dann eine besondere Rolle zu. Wird dieser Service "gehackt", dann haben Spammer offene Türen. - Bedingter Schutz da nur "Positiv Kennung"
Nur weil ein Spammer oder Virus sich nicht mehr hinter einer falschen Mailadresse verstecken kann, wird er nicht aufhören zu spammen. Zumal in der RFC auch drin steht, dass man keine Mail ablehnen sollte, wenn DKIM nicht verfügbar ist oder gar fehl schlägt. DKIM bestätigt also nur beim Erfolg, dass der Absender auch tatsächlich von der Domäne gekommen ist. - Key-Generierung und DNS
Der Absender muss ein Schlüsselpaar generieren, was schon an sich fehleranfällig ist und den Public Key richtig im DNS eintragen. Um den Public Key im DNS eintragen zu können, muss der Absender dies auch können. Viele Webhoster erlauben noch nicht diese Eintragungen. Ich frage mich, warum ich den Domainkey nicht einfach z.B.: auf meinem Webserver als Zertifikat, XML-Datei o.ä. hinterlegen kann. Den Inhalt des Webserver kann ich sicher einfacher selbst pflegen. - Newsletter und "Resend"
DKIM hat zum einen den Vorteil, dass eine Mail von einem Absender durch einen Listserver tausendfach an die Teilnehmer der Loste versendet werden kann. Die Mail selbst ändert sich ja nicht, was bei SPF ein Problem ist. Aber dies ist zugleich auch das Risiko. Ein Angreifer muss nur eine Mail von ihnen erhalten und kann diese millionenfach versenden. Der original Sender kann sich nicht dagegen wehren, und der Empfänger kann natürlich behaupten, dass Sie wirklich der Absender sind. Wenn ich jemandem schaden wollte, dann warte ich nur auf eine Mail von diesem Absender mit gültigem DKIM. Zumindest wenn ein Dienstleister tausende Empfänger mit einem Rundschreiben versendet, kann es kaum rausfinden, welcher Empfänger die Mail "weiter gegeben" hat. - Reihenfolge der Header
Es gibt Mailserver, die die Reihenfolge der Header neu aufbauen. In diesem Fall "bricht" natürlich die Signatur. Dies ist gerade bei Spamfiltern, Virengateways etc. der Fall, die damit sicherstellen wollen, dass die Mail komplett demontiert, geprüft und konform zusammen gesetzt wurde. - Public Key Austausch
Laut RFC sollte die Prüfung der Signatur möglichst früh erfolgen. Es kann ja sein, dass ein Sender seinen Schlüssel ändert. Zwar kann man im DNS auch mehrere Public Keys hinterlegen, aber es kann passieren, dass eine Validierung beim Empfänger fehlschlägt, weil der Sender schon den Key geändert hat oder der DNS Cache noch nur die alten Keys bereitstellt. - Relay Bye Bye ?
Bei der Übertragung fügt jeder Server in der Regel einen Eintrag für den Hop im "Header" dazu. Das bedeutet aber auch, dass die Signatur des Headers dann nicht mehr stimmt.
Auf der Infoseite zu Yahoo steht dazu "..and the private key is made available to their DomainKey-enabled outbound email servers". Dies bedeutet, dass ich einen meiner privaten Schlüssel den ausgehenden Mailservern, z.B.: auch einem ausgehenden Relay beim Provider übergebe.
In der RFC steht aber, dass nur die Zeilen nach dem DKIM-Header bezogen werden. Ein Addieren von Zeilen davor ist wohl unkritisch. - Kein Early Reject möglich
Abgesehen davon, dass die RFC abrät, Nachrichten mit einer fehlgeschlagenen DKIM-Prüfung abzulehnen ist eine früher Ablehnung nicht möglich. Zudem der Header der Mail übertragen werden, ehe Sie geprüft werden kann.
Vermutlich wird es noch lange dauern, bis dieses Verfahren effektiv zum Schutz beiträgt. Ich persönlich gebe da SPF oder CallerID bessere Chancen, auch wenn Yahoo solch ein Verfahren durchführt.
Persönliche Meinung
Nur weil Cisco und Yahoo einen Standard aus der Taufe heben, muss dies nicht besser oder schlechter als der Versuch von Microsoft und anderen sein, SPF/SenderID zu pushen. Das Problem bleibt, dass sowohl Absender als auch Empfänger diese Tests alle erst implementieren müssen. Dies wird sicherlich "Jahre" dauern und es ist nicht mal sicher, dass dies die Spamflut eindämmt. Es kann allerdings helfen, dass Firmen, die die Identität der Absender prüfen möchten und Absender, die DKIM implementieren, hier den Vorteil haben, gefälschte Mails (Phishing) zu erkennen bzw. korrekte Mails deutlich machen zu können.
Ich persönlich würde mich freuen, wenn alle Firmen einen DKIM-Key im DNS veröffentlichen und ihre Mail signieren, aber ich befürchte, dass dies nur eine Minderheit letztlich tut und damit das Verfahren nur geringe Vorteile bringt. Interessanter wäre hier wirklich die digitale Signierung der Verbindungen TLS oder der Mails selbst (SMIME), auch wenn dazu offizielle Zertifikate erforderlich wären.
Allerdings geben ich SMIME oder TLS auf dem Gateway eher eine Chance, weil damit Mails mit einem sehr viel länger bekannten Standard digital signiert werden und die Signatur über ein von einer CA ausstellten CA erfolgt. Der empfangende Mailserver muss also nicht erst im DNS nach dem Public Key schauen, sondern hat ihn schon in der Signatur samt Aussteller. Und wenn der empfangende Mailserver dies noch nicht kann, dann kann immer noch der Client die Prüfung vornehmen. Es ist also sehr viel einfacher, über den Weg gefälschte Absender zu erkennen und abzulehnen.
DKIM prüfen
Wenn Sie die Header eine Mail haben, und eine DKIM-Signatur prüfen wollen, dann machen Sie das besser nicht von Hand sondern mit einem Tool oder einer Library. Es ist schlicht unmöglich manuell aus dem DKIM-Eintrag die Felder zu extrahieren, darüber Hashwerte zu erstellen und die Signatur mit dem per DNS erhaltenen öffentlichen Schlüssel zu verifizieren. Das "Header From"-Feld ist übrigens immer Teil der Signatur, auch wenn es nicht explizit aufgeführt wird. Eine Mail kann auch mehrere Signaturen haben und sie können alle prüfen. Allerdings werden vielleicht nicht alle Signaturen auch gültig sein. Die RFC6376 schreibt dazu
- The order in which Verifiers try DKIM-Signature
header fields is not defined; Verifiers MAY try signatures
in any order they like.
- Survivability of signatures after transit is not
guaranteed, and signatures can fail to verify through no
fault of the Signer. Therefore, a Verifier SHOULD NOT treat
a message that has one or more bad signatures and no good
signatures differently from a message with no signature at
all
- When a signature successfully verifies, a Verifier will
either stop processing or attempt to verify any other
signatures, at the discretion of the implementation.
https://www.rfc-editor.org/rfc/rfc6376.html#page-44
Aber solange eine Signatur ein "PASS" liefert, gibt es einen Mailserver in der Kette, der dem Absender soweit vertraut dass er die FROM-Adresse mit signiert hat. Der Signierer muss dazu nicht einmal eine Schlüssel der Absender-Domain haben:
1.1. Background
... DKIM does not define any meaning to the occurrence of a
match between the content of a "d=" tag and the value of,
for
example, a domain name in the RFC5322.From field,..
Quelle: RFC 6377 DomainKeys Identified Mail (DKIM) and
Mailing Lists
Allerdings kommt da irgendwann dann DMARC ins Spiel, welches hier eine andere Funktion vorgibt. Sobald es für die Absenderdomain einen DMARC-Eintrag gibt, kommt ein "Alignment" zum Tragen und eine Mail wird nur dann nicht als "Fail" klassifiziert, wenn SPF oder DKIM ein PASS liefern, wobei die DKIM-Prüfung strenger gehandhabt wird:
(SPF=PASS or DKIM=PASS) AND (header-from and envelope-from is aligned or DKIM domain d= aligned with header-from).
Verifiers MUST confirm that the domain
specified in the "d=" tag is the same as or a parent domain
of the domain part of the "i=" tag.
The domain part of the (i=) address MUST be the same as, or
a subdomain of, the value of the "d=" tag.
https://www.rfc-editor.org/rfc/rfc6376.html
Hier ein paar Links zu Webseiten und Libraries zur DKIM-Verifizierung.
- MimeKit
https://GitHub.com/jstedfast/MimeKit - Mail::DKIM::Verifier - verifies a DKIM-signed message
https://metacpan.org/pod/Mail::DKIM::Verifier - Thunderbird Addon: DKIM Verifier
https://addons.thunderbird.net/en-US/thunderbird/addon/dkim-verifier/
Es gibt verschiedene Webseiten, an die Sie eine Testmail senden können und ihnen dann einen Report zurück senden. Dies ist hilfreich, wenn sie DKIM; SPF, DMARC für ihren eigenen Server einsetzen und daher darüber senden.
- DKIM Validator
https://tools.sparkpost.com/dkim
Für schnelle Analysen habe ich die Seite "appmaildev.com" gefunden. Hier können Sie auch einen Header per Web-Formular hochladen.
- SPF/DKIM/DMARC/DomainKey/RBL Test by Uploading Email Content
https://www.appmaildev.com/en/dkimfile - How can I verify inbound message DKIM validation failures
https://www.mailenable.com/kb/content/article.asp?ID=ME020680 - Test DomainKeys/DKIM Signature
https://www.emailarchitect.net/domainkeys/doc/?ct=object_test
Einsatz unter Exchange
Keine Exchange On-Premises-Version unterstützt aktuell DKIM.
Exchange Online hingegen kann schon DKIM signieren. Siehe
auch
DKIM mit Office 365
Das bedeutet aber nicht, dass Sie nicht dennoch ihre ausgehenden Mails per DKIM signieren können. Sie müssen aber entweder Exchange um eine passende Zusatzsoftware erweitern oder auf dem Weg nach extern könnte ein Mailrelay, z.B. ein vorgelagerter Spamfilter, in ihrem Auftrag eine DKIM-Signatur anbringen, ehe die Mail durch das Internet zum Ziel übertragen wird.
Sie können also auf jedem Exchange Server einen Transport Agent installieren oder auf dem Weg nach extern ein passendes Produkt kaufen:
- NoSpamProxy (Eigenwerbung)
www.nospamproxy.com
Kann auch DKIM signieren und eingehend DKIM/DMARC verifizieren. - SPF, DKIM, DMARC and Exchange Online
https://blogs.technet.microsoft.com/fasttracktips/2016/07/16/spf-dkim-dmarc-and-exchange-online/ - Exchange DKIM Signer
https://GitHub.com/Pro/dkim-exchange - EmailArchitect DKIM for Exchange Server and IIS SMTP Service
https://www.emailarchitect.net/domainkeys
DKIM/SPF/DMARC Verification and Authentication in Exchange Server - Tutorial
https://www.emailarchitect.net/domainkeys/kb/dkim_exchange_2007_2010_2013.aspx - DomainKeys Library
https://websvc06.cern.ch/mmmservices/Antispam/DomainKeysLibrary.aspx
C#-Musterimplementation als ISmtpInCommandSink - DomainKeys C-Library. leider 2007 schon eingestellt
http://domainkeys.sourceforge.net/
Die meisten Firmen werden aber meist sowieso ein Gateway zwischen Internet und Exchange betreiben, so dass die Funktion auch dort implementiert werden kann. Entsprechende Unterstützung bietet aktuell z.B. Sendmail, mdaemon, SpamAssasin, Postfix und andere
DKIM und Office 365
Office 365 Unterstützt sowohl DKIM als Verifikation für eingehende Mails als auch die Kennzeichnung beim Versand von ausgehenden Mails. Dazu muss der Administrator im DNS einen Verweis auf die Office 365 Keys addieren und natürlich in der Powershell DKIM aktivieren.
- Enhanced email protection with DKIM and
DMARC in Office 365
https://blogs.office.com/2015/01/20/enhanced-email-protection-dkim-dmarc-office-365/ - Office 365 – SPF, DKIM and DMARC in
Exchange Online
Part 1 http://blogs.perficient.com/microsoft/2015/12/office-365-spf-dkim-and-dmarc-in-exchange-online-part-1-of-2/
Part 2 http://blogs.perficient.com/microsoft/2015/12/office-365-spf-dkim-and-dmarc-in-exchange-online-part-2-of-2/ - Set-DkimSigningConfig
https://technet.microsoft.com/en-us/library/mt694160(v=exchg.160).aspx
Set-DkimSigningConfig -Identity contoso.com -Enabled $false
Leider ist aktuell die DKIM-Umsetzung beim Durchleiten von Mails defekt, denn Exchange online addiert nicht nur die Standardfelder, sondern berücksichtigt auch noch das Feld "X-MS-Exchange-SenderADCheck" in der Signatur. Genau das Feld wird von Exchange Online beim Empfang einer Mail aber von 1 auf 0 gesetzt, da der Absender ja nicht verifiziert ist. Wenn diese Mail dann umgeleitet wird, bricht die DKIM-Signatur.
- X-MS-Exchange-SenderADCheck und DKIM
- Weiterleitungen
- Verteiler und SPF/DKIM/DMARC
- Mailingliste mit DMARC, DKIM, SPF, ARC
DKIM und Strafverfolgung
Stellen Sie sich vor, jemand nutzt Mail für Erpressung, Droh-Mail, antisemitische Äußerungen o.ä. Wenn Sie Mail dann per DKIM signiert ist, dann lässt sich beim Empfang schon prüfen, ob Absender und Inhalt unverändert sind. Allerdings fügt kein Endanwender diese Signaturen an. Es ist immer der Mailserver, der für die Domain zuständig ist und den privaten Schlüssel hat. DKIM ist also nicht mit SMIME zu verwechseln. Der Absender könnte immer noch sagen, er war es nicht, weil beim Provider jemand die Mail eingekippt hat oder sein Konto kompromittiert war.
Hinzu kommt dass das Schlüsselpaar zur Signierung auch einfach gewechselt werden kann. Vielleicht haben Sie vor einigen Tagen oder Wochen eine DKIM-signierte Mail bekommen und damit hat ihr empfangender Mailserver die Signatur geprüft und das Ergebnis im Header addiert. Diese Eintragungen kommen aber von ihren Server und könnten also auch von ihnen gefälscht werden.
Wenn der Absender aber nach dem Versand das Schlüsselmaterial getauscht hat, können Sie die DKIM-Prüfung nicht wiederholen. Angeblich soll dies auch schon mal einem Politiker zum Verhängnis geworden sein, dass die DKIM-Signatur auch später immer noch verifizierbar ist.
Das soll nun aber nicht als Aufruf verstanden werden, die DKIM-Zertifikate im Abstand weniger Tage immer wieder zu tauschen.
- Emails: Lawyer who met Trump Jr. tied to Russian officials
https://apnews.com/article/d093a02a3d8a4e1b8dc7f5d19475899b
2020 konten Mails "von Hunter Biden" anhand der immer noch verifizierbaren DKIM-Signatur im zugeordnet werden - DKIM verification script
https://github.com/associatedpress/verify-dkim
Shell-Script, um mit DKIMVERIFY viele EML-Dateien nach dem DKIM-Status zu sortieren.
Weitere Links
-
DKIM mit Office 365
Exchange Online kann Mails per DKIM signieren und das sollten Sie möglichst auch tun - EXO Antispam-Support zu Exchange Online und SPF, DKIM, DMARC, ARC, SRS, u.a.
- DMARC
- DMARC-Validation
- Spam und UCE - Filter: SPF, SenderID
- Spam und Phishing
- RFC 4871 Identified Mail (DKIM) Signatures
http://www.ietf.org/rfc/rfc4871.txt - http://www.dkim.org
-
DKIM Core Technical Specification
https://dkimcore.org/specification.html -
Exchange DKIM Signer
https://GitHub.com/Pro/dkim-exchange
Exchange On-Premises kann kein DKIM aber gibt es einen Transport Agent und vorgeschaltete Spamfilter wie z.B. NoSpamProxy können dies natürlich auch. -
Exchange Server und DKIM
https://www.frankysweb.de/exchange-server-und-dkim/ -
NoSpamProxy Serie zu "Absenderreputation und E-Mail-Sicherheit"
Teil 1: Authenticated Received Chain (ARC)
https://www.nospamproxy.de/de/authenticated-received-chain-arc/
Teil 2: Sender Policy Framework (SPF)
https://www.nospamproxy.de/de/sender-policy-framework-spf/
Teil 3: DomainKeys Identified Mail (DKIM)
https://www.nospamproxy.de/de/domainkeys-identified-mail-dkim/
Teil 4: Domain-based Message Authentication, Reporting and Conformance (DMARC)
https://www.nospamproxy.de/de/domain-based-message-authentication-reporting-conformance-dmarc/
Teil 5: DNS-based Authentication of Named Entities (DANE)
https://www.nospamproxy.de/de/dns-based-authentication-of-named-entities-dane/ -
Exchange Server und DKIM
https://www.frankysweb.de/exchange-server-und-dkim/ -
SPF/DKIM/DMARC/DomainKey/RBL Test by Uploading Email Content
https://www.appmaildev.com/en/dkimfile -
On-Premises Exchange: DKIM and DMARC setup
https://social.technet.microsoft.com/wiki/contents/articles/35595.On-Premises-exchange-dkim-and-dmarc-setup.aspx - Wikipedia Artikel
http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
http://en.wikipedia.org/wiki/DomainKeys - Showing a question mark ‘?’ in the sender photo when a message is not
authenticated
https://blogs.msdn.microsoft.com/tzink/2017/09/05/showing-a-question-mark-in-the-sender-photo-when-a-message-is-not-authenticated/ - Mit Absenderreputation gegen E-Mail-Phishing
http://www.it-administrator.de/themen/sicherheit/fachartikel/256646.html - Emails: Lawyer who met Trump Jr. tied to Russian officials
https://apnews.com/article/d093a02a3d8a4e1b8dc7f5d19475899b
2020 konten Mails "von Hunter Biden" anhand der immer noch verifizierbaren DKIM-Signatur im zugeordnet werden - DKIM verification script
https://github.com/associatedpress/verify-dkim
Shell-Script, um mit DKIMVERIFY viele EML-Dateien nach dem DKIM-Status zu sortieren. - E-Mails signieren mit DKIM
http://www.heise.de/netze/artikel/E-Mails-signieren-mit-DKIM-221505.html - DKIM bei Office 365 in Planung
http://blogs.office.com/2014/10/15/evolving-exchange-online-protection-eop-protect-tomorrows-threats/
http://success.office.com/en-us/roadmap - DomainKey Implementor's Tools and Library für email servers & clients
http://domainkeys.sourceforge.net/ - Yahoo DomainKey
http://antispam.yahoo.com/domainkeys - Heise Meldung zu Spammer, die damit schon Yahoos Server missbrauchen.
http://www.heise.de/newsticker/Spammer-machen-sich-Yahoos-Authenticated-Mail-zunutze--/meldung/107610 - E-Mails signieren mit DKIM - Kryptographie gegen Phishing und Spam
http://www.heise.de/netze/artikel/E-Mails-signieren-mit-DKIM-221505.html - BATV Bounce Address Tag Validation
http://mipassoc.org/batv/ - DKIM Connector open Source Project
http://dkim-connector.agitos.de/trac/ - http://www.heise.de/newsticker/meldung/60185
- Cisco hat die Signierung von Absendern als Schutz propagiert
Identified Internet Mail
http://www.identifiedmail.com - DomainKeys Library
https://websvc06.cern.ch/mmmservices/Antispam/DomainKeysLibrary.aspx
https://websvc06.cern.ch/mmmservices/Antispam/DomainKeys.aspx
C#-Musterimplementation als ISmtpInCommandSink - What is a DNS DKIM record?
https://www.cloudflare.com/learning/dns/dns-records/dns-dkim-record/ - Heise Newsticker zu DKIM
http://www.heise.de/newsticker/meldung/90281
http://www.heise.de/newsticker/meldung/62500 - DKIM Kategorie bei o-o-o-s
http://o-o-s.de/?cat=64 - SENDERID, SPF, DKIM AND DMARC IN EXCHANGE 2016
https://jaapwesselius.com/2016/08/19/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-i/
https://jaapwesselius.com/2016/08/22/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-ii/
https://jaapwesselius.com/2016/08/23/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-iii/