The Hidden Life of an Email: Alice Writes, Bob Reads

It feels like magic: you type something, hit Send, and seconds later your friend replies, “Got it.”

But what actually happens in those seconds?

When I was setting up Inovus Labs’ custom email system (check out my blog at **Inovus Blogs**: [From One to Infinity: Hacking Email Routing for Unlimited Users]), I became obsessed with this question. To find out, I followed a single message — an email sent by Alice from her Gmail account to Bob’s Outlook account — and mapped out every checkpoint it crossed.

What I discovered is that an email isn’t just a message. It’s a journey across protocols, DNS servers, cryptographic signatures, and filters. Most people never see this world, but it’s there every time you click Send.

So here’s the story of one email: from Alice at Gmail to Bob at Outlook.

Step 1: Alice Hits Send

Alice writes a quick note: “Hey Bob, are we still on for tonight?” She clicks Send in Gmail.

Behind the scenes, Gmail wraps that message with hidden metadata:

• Message-ID: a unique fingerprint for the message.
• Return-Path: where bounces should go if delivery fails.
• Reply-To: where replies should land (can be different from “From”).
• MIME structure: telling Outlook how to render plain text, HTML, or attachments.

👉 See it yourself: In Gmail, click ⋮ → Show original. You’ll see dozens of headers you never knew existed.

Step 2: Leaving Gmail — SMTP Takes Over

Alice’s Gmail app sends her message to Google’s Mail Submission Agent using SMTP. SMTP is the postman of the internet.

It literally says things like:

MAIL FROM:<alice@gmail.com>
RCPT TO:<bob@outlook.com>
DATA
...message...
.
QUIT

Once Alice’s Gmail server has it, the message enters Google’s massive sending infrastructure. Think of it as Alice dropping her letter at her local post office.

Step 3: Finding Bob — DNS & MX Lookup

Now Google needs to know where to send mail for outlook.com. It queries the Internet’s phonebook: DNS.

• DNS reveals the MX records for outlook.com.
• These usually point to Microsoft servers like outlook-com.olc.protection.outlook.com.
• Alongside, TXT records define SPF, DKIM keys, and DMARC policies for Microsoft.

This is the crucial step where Google learns: “Ah, to reach Bob, I must hand this to Microsoft’s mail servers.”

👉 Try it: Run dig mx outlook.com in a terminal. You’ll see the Microsoft MX servers that Gmail talks to.

MX Servers of inovuslabs.org

Step 4: Proving Trust — SPF, DKIM, DMARC … and BIMI

Before Microsoft accepts Alice’s email, it wants proof. Is this really Gmail sending on behalf of Alice?

• SPF: Microsoft checks if the sending IP belongs to Google and is authorised to send mail for gmail.com.
• DKIM: Gmail has cryptographically signed Alice’s message. Microsoft verifies the signature with a public key in DNS.
• DMARC: Microsoft checks if either SPF or DKIM aligns with Alice’s visible From: alice@gmail.com.

Alice passes all three. But there’s a new player too: BIMI (Brand Indicators for Message Identification) — lets brands publish a DNS record pointing to an SVG logo. If that domain also buys a Verified Mark Certificate (VMC), providers like Gmail will show the sender’s official logo in the inbox list.

Recently, Gmail introduced a new feature: the blue verification checkmark. If a sender has proper DMARC enforcement, BIMI, and a VMC, Gmail will display a tiny blue tick beside their name, indicating to users: “This sender is who they claim to be.”

Alice doesn’t have a logo or VMC — she’s just writing as herself. But if she were sending from a brand, Bob might see not just her email, but her company’s logo and a shiny blue tick of trust.

👉 Tip: Open a promotional email in Gmail from a big brand (say, PayPal or Google itself). If they’ve done BIMI + VMC, you’ll see their logo and a checkmark. That’s email identity done right.

👉 Pro tip: In Outlook, you can also view headers (File → Properties). You’ll see the same spf=pass dkim=pass dmarc=pass judgments that Gmail shows.

Step 5: The Journey Across Servers

Now Alice’s email travels across Google’s servers, out through the internet, and into Microsoft’s mail system.

Each server that handles it leaves a Received: stamp with a timestamp and IP address. Reading them bottom-up is like following a trail of passport stamps. You can literally see the path the message took.

Sometimes, Microsoft might slow things down with techniques like greylisting, telling Google to “try again later” if it doesn’t recognise the sender. Google, being a good citizen, retries until it’s accepted.

Step 6: Outlook’s Filters and Firewalls

Even after passing SPF/DKIM/DMARC, Bob’s mail isn’t in his inbox yet. Microsoft has its own filters:

• Spam and phishing detection powered by ML.
• Blacklist checks for bad domains or IPs.
• Malware scanning on attachments.
• User reputation (if lots of people block Alice, she’s in trouble).

Outlook is stricter than Gmail in some ways. Sometimes even perfectly valid emails land in “Junk.” But Alice’s short note passes easily.

Step 7: Accepted or Bounced

Microsoft now decides:

• 250 OK: accepted, queued for Bob.
• 4xx: temporary fail, Google retries later.
• 5xx: permanent failure, and Alice’s Gmail gets a bounce from mailer-daemon.

Example of a bounce mail from mailer-daemon

Luckily, Bob exists, so Microsoft responds with 250 OK. The email is accepted into Bob’s mailbox.

Step 8: Sitting in Bob’s Mailbox

The message is now stored on Microsoft’s Exchange servers, waiting for Bob’s Outlook app to fetch it.

This happens through IMAP, the protocol that keeps everything in sync. When Bob reads a message on his phone, IMAP makes sure it shows up as read on his laptop, too. Flags like unread, replied, or moved to a folder all live on the server, not just on one device.

Older systems used POP3, which simply downloaded mail and often deleted it from the server. That worked in the days of single desktops, but it broke the moment you wanted your inbox to sync across phone, laptop, and web.

That little bold “unread” marker in Outlook isn’t magic — it’s IMAP quietly keeping Bob’s inbox consistent everywhere.

Step 9: Bob Reads Alice’s Note

Bob opens Outlook. The client fetches Alice’s message, parses the MIME structure, and displays it. If there were images or attachments, Outlook would decide whether to auto-load or block them for safety.

To Bob, it just looks like: “Hey Bob, are we still on for tonight?”

But beneath that one line was a relay race across Google, DNS, cryptographic checks, Microsoft’s filtering layers, and mailbox protocols.

What I Learned From Alice’s Email

Following Alice’s Gmail-to-Outlook message was eye-opening.

• I learned how to trace Received headers like a travel log.
• I saw how SPF, DKIM, and DMARC silently judge every message.
• I realised bounces aren’t errors, they’re teachers.
• And I finally understood why some emails just vanish into Junk despite being “valid.”

It turned something invisible into something you can actually follow, like footprints in the sand.

Why This Journey Matters

For me, this wasn’t just curiosity. At Inovus, we needed to understand these details to develop our “infinite aliases” hack using Zoho and Cloudflare. That hack only worked because I finally knew how Return-Path differs from From, why DKIM signatures survive forwarding, and why Outlook sometimes marks clean mail as Junk.

This blog is the technical half of that story. The other half — the hack itself — lives in From One to Infinity. Together, they show both sides: the community experiment and the plumbing beneath it.

And that’s the beauty of email. It’s decades old, older than the web itself, but it’s still the backbone of online identity. Every signup, password reset, or official conversation still rides this same journey.

So the next time you hit Send, remember: your email is about to go on an adventure — across DNS, trust gauntlets, filters, and inbox flags — before it lands where you wanted it.

And if it doesn’t? Well, check the headers. They tell the story.