Email is a primary attack vector for network intrusion, and the standard protocols that power it—SMTP, IMAP, and POP3—transmit messages without encryption, integrity checks, or sender verification by default. Securing email infrastructure requires layering encrypted protocol variants, authentication frameworks like SPF, DKIM, and DMARC, and email gateway filtering to address confidentiality, authenticity, and spam.
Email Security
One of the ways an adversary can get into our network is through the email system. If you think about it, it's one of the only open areas that just allows traffic to come into our network. And all they need to do is get somebody inside the system to click, and then it installs stuff on their machine and compromises the rest of the network. So one of the things that we should do is think about email security. How can we lock things down?
Before we get into all the flaws around email and how we fix them, let's first talk about email and make sure we have a good understanding of how email flows.
In our example right here, we've got two domains, domain.com and example.com, and we've got two users. This is Sally, and her email is [email protected]. And this is Bob, and Bob is [email protected].
Sally wants to send Bob an email. What she's going to do is open up whatever client she has on her machine. This is a client that's going to help her compose email, so this is what we call a mail user agent. The mail user agent is that software on this machine that's actually going to send this email. So she types up the message, puts in Bob's address into this email, and she hits send.
Well, that has to go somewhere. It has to go into the mail system. So we've got a mail submission agent right here. That's going to be coded into, or configured on, her machine. Her client that she has typed the email out says, okay, this is where the first step is, that mail submission agent.
Now realize that the way this is all set up could vary a little bit. So maybe it's a separate MTA as it is an MSA. That's how I've got it set up. Maybe that's the same machine. So the way this looks could look a little different, but this mail submission agent needs to start sending it along its way.
So it's going to send it to a mail transfer agent. Essentially, this is just mail relay. There could be one mail relay in all of this, or there could be hundreds of mail relays in all of this, and there probably is going to be at least a couple involved in here. So in our diagram right here, we have a couple of mail transfer agents.
What happens on the mail transfer agent? Well, they need to know where they're going to send it. They need to send it to this domain; they know they need to send it to example.com. What they're going to do is they're going to look up in DNS for an MX record, and that MX record is going to point to this MTA, this mail transfer agent. So it's going to get back an IP address of that mail transfer agent, and that's how it knows where to send it along its way.
So this mail transfer agent will then send it along its way. It's going to go through the internet and then arrive here at the MTA, which is the IP address associated with that MX record. That MTA is going to send it to the mail delivery agent. Here again, it could be all the same box, or we could have separate boxes, just depending on the setup.
Now we have it on the mail delivery agent, and there is where it's going to just sit. It's going to just sit because this MUA, this mail user agent, might not be on the network at that time. So Bob might be at home, he might be just not connected, maybe his machine's turned off. He's going to come in, connect to the network, open up the client, and then when he opens up the client, it will sync and download his email. And now we have the mail delivered to Bob.
So let's talk about our first protocol here: Simple Mail Transfer Protocol, or SMTP. SMTP does the bulk of the transferring back and forth. When we send a mail, what happens from the client to the MSA? It's going to send it through SMTP, that protocol. When it goes from the MSA to the MTA, then it will do SMTP. When it sends from MTA to MTA, SMTP, and then MTA to MDA, that's going to be SMTP. So it's going to be using SMTP all along the way as it hits all these mail relay agents.
There's a little difference here at the end, though, because what happens with SMTP is it just gets essentially shoved or pushed. It gets pushed along the way, and it just assumes, well, the next server is going to be up and running, so we're going to push it to the next server and just send it along its way. So the servers need to be up and running.
But Bob doesn't necessarily have his machine up and running all the time, so this can't just shove it or push it to Bob over here. Instead, what needs to happen is when Bob gets online and opens up that client, it needs to go retrieve it. For that purpose, we need to have a different protocol, a retrieval protocol. That's where POP version 3 and IMAP come into play. They act a little bit differently, but essentially they are what is mainly going to be the protocols for retrieving that mail.
Here's where we encounter the first issue: confidentiality and integrity. All of the protocols that we've mentioned by default, SMTP, IMAP, POP version 3, all of these are really not sent in secure. They are sent in the open, which means that anybody that is sitting along the way can open up and read those messages and be able to view them, because there is no encryption, there's nothing involved in that. And also they could be changed, because there's no mechanism for integrity.
The other issue we have with all of this is there's no checks and balances for authenticity, or at least not that we've talked about so far. Any of these mail relays can connect to any mail relays and send mail. So we need a way to make sure that the messages that are being sent are truly being sent from the domain that they say they're being sent from.
Traditionally the way email works is that anybody could just claim that they're anybody. I could put on here that I'm from [email protected], and there's not really a checks and balances, natively speaking, that checks that to make sure that I truly am from domain.com and I truly am Sally. So we need an authenticity piece to all of this to make sure that the messages that are being sent are actually authentic.
This leads to another problem, of spam. Whether those messages are authentic or not, we could just send any messages and they have to be received and sent to the user. So how do we deal with spam?
Now, I'm just going to put this out there that I don't think email is actually a secure form or way of transferring data, no matter what. So even with all of these security measures, I'd watch out. But there are ways to make it more secure. And what are those?
Number one is we can secure the protocols. We can secure the SMTP, POP version 3 and IMAP protocols, and we do have secure forms of those protocols, so we should be using those secure forms.
Then we also have sender policy framework, DomainKeys Identified Mail, or DKIM, and we've got domain-based message authentication reporting and confirmation, or DMARC. So these are three mechanisms in place for us to do things like authenticity and confirm authenticity.
And then the other thing we can do for the spam is some sort of email gateway. So these are the things that we're going to want to implement to at least lock down email a little bit more.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →