DKIM records can now be added to all our standard email services. DomainKeys Identified Mail is a way to digitally-sign emails, helping to prove that a sender is genuine. It’s a way of protecting you (and your contacts) against spoofing, phishing or impersonation – and it improves deliverability.
DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender’s public key published in the DNS. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed. Usually, DKIM signatures are not visible to end-users, and are affixed or verified by the infrastructure rather than the message’s authors and recipients.
DKIM is an “Internet standard”. It is defined in RFC 6376, dated September 2011; with updates in RFC 8301 and RFC 8463.
The need for email validated identification arises because forged addresses and content are otherwise easily created – and widely used in spam, phishing and other email-based fraud. For example, a fraudster may send a message claiming to be from sender@example.com, with the goal of convincing the recipient to accept and to read the email – and it is difficult for recipients to establish whether to trust this message. System administrators also have to deal with complaints about malicious email that appears to have originated from their systems, but did not.
DKIM provides the ability to sign a message, and allows the signer (author organization) to communicate which emails it considers legitimate. It does not directly prevent or disclose abusive behavior.
DKIM also provides a process for verifying a signed message. Verifying modules typically act on behalf of the receiver organization, possibly at each hop.
All of this is independent of Simple Mail Transfer Protocol (SMTP) routing aspects, in that it operates on the RFC 5322 message—the transported mail’s header and body—not the SMTP “envelope” defined in RFC 5321. Hence, DKIM signatures survives basic relaying across multiple MTAs.