Sending Emails – How Is It Done Under the Hood?
email or Electronic Mail is just like a sending letters through post office. For this article we will take a real life scenario for posting mails physically to the recipent.
Real-life posting :
Bob lives in Kolkata, pincode 700119, and his old friend Alice stays in Delhi, pincode 110011. After a long time, Bob decided to finally write a letter to Alice. So one day he went to his nearest post office, bought an envelope and stamp, wrote the letter, sealed it properly, and dropped it into the letter box.
From there, the journey of the letter actually starts.
First, the letter is collected from the local post office and taken to the Sub Post Office (SO) or Branch Office (BO) that handles sorting for that area. After that, it goes to the Mail Office / Mail Processing Centre (MPC), where thousands of letters come every day.
Here, the postal workers and sorting machines check the pincode written by Bob. The pincode helps the system know the exact region, district, and delivery post office the letter should go to. Since Bob wrote 110011 for Delhi, the system identifies that the letter must travel from Kolkata to Delhi. They don’t “check if the recipient exists,” but they check if the pincode is valid and if the address is complete enough for delivery.
Once sorted, the letter is put into a mail bag and sent out of Kolkata—sometimes by train, sometimes by flight, depending on the mail type and timing.
When the mail reaches Delhi, it again enters a Delhi Mail Processing Centre, where it is sorted according to local areas and post offices. The pincode 110011 is mapped to the nearest Delivery Post Office, and the letter is forwarded there.
At this final post office, the letter is arranged in the beat of a postman/peon who handles that locality. The postman takes the letter in his daily round, goes door to door, and finally reaches Alice’s address. He knocks, confirms her name, and hands over the letter to her — completing the whole journey.
Electronic mail sendings :
Let’s replace Bob with an email address: sender@example.com, and Alice with recipient@receive.com.
Here, example.com and receive.com are two completely different domains — and later in this article, you’ll understand exactly why that matters.
SMTP Handshake
Now, when you tap Send in your email client (your MUA — Mail User Agent), the real journey starts. Your MUA connects to the SMTP server belonging to the sender’s domain. This is where the SMTP Handshake happens — basically a small conversation between your device and the mail server to start the session.
SMTP usually works on port 25, but depending on the situation or server rules, it can also use 465, 587, or 2525.
After the handshake, the SMTP server checks whether the sender and recipient are from the same domain.
If both emails use the same domain, the server simply hands the message over to the domain’s internal IMAP/POP3 server.
If the domains don’t match, then the server needs to find out where to deliver the email.
To do that, the SMTP server performs a DNS lookup for the recipient’s domain. It looks for the MX record — this record tells which mail server handles incoming emails for that domain. For example, for receive.com, the MX might be something like:
But this isn’t the final destination yet. The SMTP server now checks the A record of mail.receive.com, which gives the actual IP address of the mail server. Once it gets that, your message can be forwarded to the receiving server.
However, here’s the catch:
If proper authentication records are not set up, your message may land in the recipient’s Spam folder.
Why does that happen?
Because you haven’t set up SPF, DKIM, and DMARC yet — the three major DNS-based email authentication systems.
SPF (Sender Policy Framework)
SPF is a TXT record in your domain’s DNS.
It tells the world: “These are the servers allowed to send email on behalf of my domain.”
If a mail server sends emails for your domain without appearing in this SPF list, receiving servers consider the message suspicious.
DKIM (DomainKeys Identified Mail)
If SPF fails or cannot fully verify the sender, DKIM comes into play.
DKIM adds a digital signature to your outgoing email. The public part of the cryptographic key is stored as a DNS TXT record.
It works almost like an SSH public key — allowing the receiving server to verify two things:
The email was genuinely sent by a server authorized by your domain.
The email wasn’t modified or tampered with during transit.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is the rulebook.
It tells the receiving mail server what to do if SPF and DKIM fail.
Your DMARC TXT record can instruct:
“If authentication fails, still deliver the email.”
“If it fails, move it to spam.”
“If it fails, reject it completely — do not deliver.”
DMARC also sends reports so domain owners can track who is sending emails on their behalf.
Final Delivery — IMAP and POP3
Once these checks are passed (SPF, DKIM, DMARC), the receiving mail server accepts the email and stores it. From there, the email becomes available to the user through IMAP or POP3.
IMAP syncs emails between the server and all devices.
POP3 downloads the mail to the user’s local machine.
And that’s how sender@example.com reaches recipient@receive.com successfully.
Source : Mailtrap