DKIM Explained – How It Works | Mailtrap
This video offers a step by step explanation on how DKIM protocol works for email authentication.
We answer the major questions concerning DKIM: what is DKIM, how do you create a DKIM record, and how it works to prevent email spoofing.
Along with other methods, such as SPF, BIMI, or DMARC, DKIM is one of the most common methods of email authentication. Below, we clarify why you should use DKIM DNS Text Record to improve email security and deliverability.
Contents
In just two minutes, you will learn the most important things you need to know about DKIM for email:
✅ What DKIM means and why it is important
✅ The pair of keys for signing the mail.
✅ What happens when you send the DKIM signed email
✅ How DKIM signature is verified and how it influences email deliverability.
Learn more about Mailtrap and start for free at 🔗 https://bit.ly/3LJgzOX
Stay tuned!
Subscribe to our YouTube channel and other pages in social media:
YouTube: https://bit.ly/3jU7IuS
Twitter: https://twitter.com/mailtrap
Facebook: https://www.facebook.com/Mailtrap
LinkedIn:https://www.linkedin.com/company/mail…
by Mailtrap
linux smtp server
hi.. can i use DKIM key to white label email correspondence > thank you
Very nice video! Can I have dkim and spf registers configured even if I don't have a A or NS register, right or? Thanks
We, at Mailtrap, are committed to enhancing your knowledge of email authentication. Dive into this tutorial to understand DKIM, how to create a DKIM record, and its role in preventing email spoofing. Do you have any other questions about DKIM? Let us know in the comments
Nobody explains this worth a hoot — nobody. Here's how it works:
The sending server has a private key associated with the domain in the sender's email address. As they send a message, first they compute a "hash" — a checksum of the message contents which could only be recreated from an exact copy of the message. If a single bit of the message were to be altered, the hashing algorithm would produce a completely different checksum. Finally, they encrypt the hash and attach it to the message.
The receiver reads the sender's domain in one of the email addresses on the message, and queries the sender's domain DNS for its public key. Making this public key available is how the sender's domain proves its relationship to the server that has the private key. The recipient uses the sending domain's public key to decrypt the sender's hash. Then the receiver performs its own hash of the message. If the two hashes match, two things are proven:
1. The message was sent from the sender's domain, proven because that domain's public key was able to decrypt the hash.
2. The message content is unaltered, proven because a new hash of the message exactly matches the hash that was originally encrypted by the sender.
I think there's an issue here with the following statement "With the newly acquired public key, the receiving server builds its own hashes and compares them with the ones received in the message." The public key in this instance can't be used to "build" the same hash and do a comparison right? Rather the public key is used to decrypt the "hash" in order to verify it was encrypted using the correspondent private key. If anyone could build the same hash using the public key that existed in the DNS record, anyone could pretend to be the sending server. Also the use of the word "hash" in this context is incorrect in my opinion, since it implies a one-way function. More correct would be using "cipher text" as it indicates it can be decrypted (in this case using asymmetric cryptography.
How it understands what is the public key hostname?