Beyond the Send Button: How Your Emails Actually Reach Their Destination
Email just works.
You type an address, write your message, click send, and moments later it arrives at its destination thousands of miles away. But have you ever wondered what actually happens in those few seconds between clicking "send" and your message appearing in someone's inbox?
Understanding the basic infrastructure of email is becoming increasingly important for Access developers as Microsoft continues moving away from COM automation in Outlook. As alternatives like web APIs and services like Mailgun become necessary replacements, knowing how email actually works will help you implement these solutions more effectively.
Let's pull back the curtain on this everyday technology.
IP Addresses: The Internet's Phone Numbers
Every device connected to the internet has an IP address.
This address works exactly like a phone number. When you want to call someone, you need their unique phone number to connect. Similarly, when your computer needs to communicate with another computer on the internet, it needs that computer's unique IP address.
IP addresses look something like this:
192.168.1.12001:0db8:85a3:0000:0000:8a2e:0370:7334(for newer IPv6 addresses)
Just as phone numbers follow a specific format with area codes and local numbers, IP addresses follow strict formatting rules that help route information across the internet.
But here's the problem: remembering IP addresses would be like memorizing everyone's phone number. That's where our next component comes in.
DNS: The Internet's Phone Book
The Domain Name System (DNS) is essentially the internet's phone book.
When you type "gmail.com" into your browser, you're using a human-friendly name. But computers don't understand these names–they only understand IP addresses. DNS servers translate these human-readable domain names into the IP addresses that computers need.
Think of it this way: in the days before cell phones, when you needed to call a business or person, you'd look up their name in a physical phone book to find their number. These phone books were centralized, authoritative resources published by the phone company. Everyone in town used the same phone book, and you trusted that the numbers listed were correct.
DNS works in a similar way. When you send an email to someone@example.com, your computer first asks a DNS server, "What's the IP address for the mail server that handles example.com emails?" The DNS server responds with the appropriate IP address, and only then can your email begin its journey.
Just as phone books were organized by city or region (you'd use the Seattle phone book to find businesses in Seattle), DNS is also hierarchical. Different DNS servers are responsible for different domains, creating a global, distributed system of "phone books" that computers consult to find their way around the internet.
This centralized, authoritative nature of DNS becomes critically important when we discuss email security in our next article. The ability to trust these "phone book" entries is fundamental to knowing whether an email truly came from where it claims to have originated.
Email Servers: Digital Mail Rooms
Email servers are the mail rooms of the internet.
In theory, if I wanted to send a letter to Walter Hobbs at Greenway Press, I could look up Greenway Press in the phone book (DNS), get their address, and personally deliver my letter to their mail room. But that's incredibly inefficient.
Instead, most companies have their own mail rooms to handle outgoing correspondence. For smaller businesses, maintaining a full mail room operation is expensive and complex. That's where mail service providers come in.
Greenway Press is headquartered in the Empire State Building, which–if you didn't know–has a raucous mail room:
In a post-COM automation world, when we develop Access applications that send emails, we'll essentially be contracting with a specialized mail room service like Mailgun. We don't need to know the specific details of how to reach Walter Hobbs' mail server–we just need to know how to reach our contracted mail service.
As an Access developer, you configure your application with just one server address and port–Mailgun's. You hand your message to Mailgun with instructions like "Please deliver this to walter.hobbs@greenwaypress.com," and Mailgun handles all the complex logistics:
- Looking up the MX records for greenwaypress.com
- Establishing a connection to their mail server
- Negotiating the delivery protocols
- Ensuring the message is properly formatted
- Handling any delivery errors or retries
This is why services like Mailgun are so valuable as we move away from Outlook automation. They abstract away the complexity of email delivery, letting you focus on your application rather than the intricacies of email infrastructure.
The most common protocol used for this communication is SMTP (Simple Mail Transfer Protocol). Think of SMTP as the standardized procedures that mail room staff follow to ensure mail gets processed correctly. When your Access application communicates with Mailgun, it uses SMTP to "speak the language" of email delivery.
Just as the Empire State Building's mail room has specific procedures for sorting, routing, and delivering physical mail, email servers follow strict protocols to ensure digital messages reach their intended recipients.
The Journey of an Email
Let's walk through what happens when your Access application sends an email through a service like Mailgun:
- Your Access application prepares an email to
walter.hobbs@greenwaypress.com - Your code connects to Mailgun's SMTP server using the server address and port you've configured
- Mailgun accepts your message and takes over the delivery process
- Mailgun asks DNS, "Where should I deliver mail for greenwaypress.com?"
- DNS responds with the IP address of Greenway Press's mail server
- Mailgun connects to Greenway Press's mail server and transfers your message
- The receiving mail server places your message in Walter's mailbox
- When Walter checks his email, his email client retrieves your message from his mail server
This entire process typically happens in seconds, with your message potentially traveling through multiple servers and across vast distances. As an Access developer, you only need to worry about steps 1 and 2; Mailgun handles everything else.
A System Built on Trust
Here's something crucial to understand: the email system was designed in the early days of the internet when trust was assumed.
The original email protocols were created when the internet was primarily used by universities and government agencies. The designers never anticipated a world where people would try to impersonate others or send malicious content through email.
As a result, the basic email system has no built-in way to verify that senders are who they claim to be. When an email arrives claiming to be from "bank@example.com," the original system had no mechanism to verify this was actually true.
This fundamental trust-based architecture is why email security has been such a challenge. It's like designing a postal system where anyone can write any return address on an envelope with no verification (hmm...🤔).
In our next article, we'll explore how this trust problem was eventually addressed through security measures like SPF, DKIM, and DMARC–critical concepts for Access developers implementing modern email solutions through services like Mailgun.
Until then, remember that understanding these basics will help you navigate the changing landscape of email automation as Microsoft continues its move away from COM-based solutions toward web APIs and services.
Referenced Articles
Acknowledgements
- Article title generated with the help of Claude-3.7-Sonnet
- Article excerpt generated with the help of Claude-3.7-Sonnet
- Initial draft generated with the help of Claude-3.7-Sonnet
- Cover image generated by Imagen3