Let's say, for example, that I have a Gmail account. I compose and send an e-mail to info@somecompany.com. They aren't using Google services, just so that we can exclude "special cases" where they just keep the entire thing internal to their own network.

On a technical level, doesn't the e-mail client/software just look up somecompany.com's MX records and then connect directly to that IP address on the "e-mail port" and, assuming it is online and accepts the "handshake", just transfers the e-mail directly to it?

Why have I heard all my life that e-mails just get "flung out in cyberspace randomly" and bounced around the entire world, allowing everyone and their grandmother to read it before it finally gets routed to its final destination?

Is this a total misconception? Was it something that was done in the 1960s because they couldn't afford to have computers on at all times, so they had to do it like this? Is it by design in order to allow spying?

I feel ashamed for still not having a good grasp on this after all these years. I've probably tried to ask about this dozens of times over the years, but never got what I considered a clear and conclusive answer.

  • The key thing you need to know is that you can’t actually “connect directly” to an IP address. You can only connect directly to a machine that’s on the same network segment as your machine. The Internet protocols hide all that complexity from you.
    – Mike Scott
    Mar 3, 2020 at 22:01
  • Gmail sends encrypted if it can... the endpoint has to support it: support.google.com/mail/answer/6330403?hl=en
    – pcalkins
    Mar 3, 2020 at 23:34

3 Answers 3


There are a few layers to your question, which might be why you have not received a satisfying answer.

The first layer is simple: email sent from one email server to another is not normally encrypted. That means any server/router/node along the path can read emails. I'm not talking about email servers, just infrastructure.

The second layer is more complex. It is possible that your Gmail server sends the email directly to the recipient server, meaning only two email servers are involved. But there are so many other configurations that might also be involved:

  • Email server fabrics mean that there can be a cloud of servers at either end, with the ownership/control of any one server not contiguous (shared control, control in different countries/legal entities, etc.)
  • Mail relays might serve one end or another
  • Forwarders might be used on the user side, which compounds the possibilities
  • Email clients might have their own server fabric, so when you send the email to the recipient address, it might be served by different clients at the client-side after it hits the email server

Just keep the OSI model in mind. Yes, on one level, it can be one server talking to another. But the magic of stacks means there is a complex web at every layer and the connections between the layers can be equally complex.

  • 1
    "But the magic of stacks means there is a complex web at every layer " - including the physical layer. You never know which clients happen to be running an unencrypted email client 24/7 on their cellphones over open WiFi that happens to be run by Eve. Mar 3, 2020 at 22:14

To answer this question, we have to keep in mind the OSI layers.

You send an email through Gmail, so Google certainly gets in the path. Of course, since you are not Google, this means that the text of your email floats in a Web session (HTTPS) between you and Google's Gmail servers.

Gmail knows you want to send an email to somecompany.com, so it uses MX records to find the SMTP server's FQDN. This is done through DNS requests, which again float through the Internet, but this doesn't involve the text of your email nor, for that matter, your email address.

At that point, Gmail opens an SMTP session to that server and eventually sends the email, possibly through some relay (but not always). Again, this traffic floats through the Internet.

When I say "floats through the Internet", this means through a series of fiber optic cables, switches, routers, firewalls. The exact physical path depends on lots of things.

Of course, any of these steps along the path is potentially subject to (more or less targeted) surveillance by any sufficiently powerful entity like the NSA.

But, in general (barring things like BGP hijackings or major cable faults), your email from New York to San Francisco, through an American provider (Google) and without using relays, doesn't pass through Russia, or Iran. So those governments don't have access to your email, at least not via direct access to your path. They of course could have backdoors in any equipment or server along the path, including your PC of course. But that's another story.


Another interesting way your email can get to somebody is... Through AV and email protection services. If for some reason your email is considered suspicious, its attachment can be sent to a sandbox or a Virustotal-like service, which can be either on-prem or "in cloud".


Your E-mail (like all data) is getting chopped to bits and transmitted as packets down a protocol stack ending in IP.

In a net-neutral world, those IP packets (generally, notionally) will take the lowest-latency route to their destination. Like cars on a road, the lowest-latency route can differ from packet to packet. Sometimes the road is open and a packet (or stream of them) can get from origin to destination in a hop or two. Sometimes its congested, and so it becomes faster to take a few extra turns (hops) on smaller roads to go around the traffic. Post Ajit Pai, many carriers prioritize in-network packets and de-prioritize cross-network packets. AT&T wants you to have the best experience possible with their streaming TV offering, but if a Comcast-originated packet hits AT&T pipes, well... but that's a different issue.

You're fundamentally correct in assessing your packets go out, bounce around and eventually end up at their final destination, where they are ordered (and if dropped, re-requested) by TCP, then passed up a protocol stack to whatever service lives on the other end for storage, re-transmission, or display.

Along the way those packets pass through equipment, and some that equipment can "look into" the payloads of your packet(s). If the data is unencrypted, that's easy. If you're using a secure service like gmail the payloads (data) would be encrypted before transmission, so they'd be hard to read for anyone but a state actor (or hacker using state tools). But the metadata required to route that message is top-of-packet and un-encrypted, so it's easy to see a packet went from say, Chicago to New York, even if its contents are encrypted.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.