DKIM is discussed extensively by several sources, and this isn't an extensive breakdown of it, ultimately I have working knowledge of it so consider this my idiots guide to the galaxy. DomainKeys Identified Mail (DKIM) as a technology allows us to digitally sign each email that is sent. As it leaves the mail server / MTA signs each email with a private key based on the hash of the contents. The recipient mail server / MTA receives this DKIM signed email, and then proceeds to check the DKIM selector record for the associated sender. If a public key is provided for the selector when queried, this is then used to check against the hash in the signed email. If they match, the email is known to be valid, and not tampered with. Depending on the DMARC policy, and SPF record - this can be used to further verify the sending source of the email. Ultimately DKIM by itself does not provide any immediate benefits or direct protection from spoofing, just an indicator that the source is verified, and passed the digital signatures. It isn't typically presented to an end user. ## So what is the benefit? When combined with SPF and DMARC it can become a powerful addition to the toolkit at ensuring only authenticated sources get through to email accounts. This is part of the layered approach to security. ### The downside? Each additional MTA/Sender usually requires another DNS record to be created to allow the signature to occur. This can result in a decent amount of work to identify the parties, and get the appropriate records in place. Especially with shadow IT. The systems involved may additionally not be compatible with DKIM, therefore the only form of validation can be in the SPF record. --- [[Epistemic status|Colophon: Brewing]]