TechKnowSurge
VideoSecurityFree

Email Security

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.

Complete this video to capture a CTF flag worth 1 point.

About this video

Email infrastructure is one of the few channels that organizations deliberately leave open to inbound external traffic, which makes it a high-value target for attackers. A single malicious email that prompts a user to click a link or open an attachment can install malware and propagate a compromise across an entire network. Understanding the architecture of email delivery—spanning the Mail User Agent, Mail Submission Agent, Mail Transfer Agents, and Mail Delivery Agent—is foundational to identifying where vulnerabilities exist and where controls must be applied. SMTP handles message transfer at every relay hop along the path, while POP3 and IMAP serve the retrieval function when end users connect to collect their messages. By default, none of these protocols provide encryption, meaning messages travel in cleartext and are readable by anyone with access to traffic along the route. Equally significant, these protocols include no native mechanism for verifying that a sender is actually who they claim to be, allowing any party to spoof a legitimate domain or user address without detection at the protocol level. This absence of authenticity controls is the root cause of widespread email spoofing and phishing, and it also contributes directly to spam, since mail relays will accept and forward messages regardless of whether the claimed sender is genuine. Addressing these gaps requires a layered approach: replacing plaintext protocol variants with their encrypted equivalents, deploying Sender Policy Framework to validate authorized sending servers, using DomainKeys Identified Mail to cryptographically sign messages and confirm they have not been altered in transit, and configuring Domain-based Message Authentication Reporting and Conformance to enforce and monitor those authentication policies. Email gateways add a further layer of defense by filtering spam and malicious content before messages reach end users. Even with all these controls in place, email should be treated as an inherently limited channel for sensitive data transmission.

What you'll learn

What's covered

Email Security

Key terms

Simple Mail Transfer Protocol
SMTP
A TCP-based application-layer protocol used to send email messages between mail servers and from mail clients to outbound mail servers, typically on port 25 (server-to-server) or port 587 with TLS (client submission). SMTP only handles sending mail; retrieval is handled by separate protocols such as IMAP or POP3.
Spoofing
An attack where an adversary impersonates a trusted entity by falsifying data such as an IP address or email address.
Confidentiality
The principle that information is accessible only to those authorized to access it.
Integrity
The assurance that data has not been tampered with and remains accurate and complete.
Encryption
The process of converting readable data into an unreadable format using an algorithm and key to prevent unauthorized access.
Mail User Agent
MUA
The client-side software that allows a user to compose, send, and receive email messages.
Mail Transfer Agent
MTA
A server component responsible for relaying email messages between mail servers using SMTP.
Mail Delivery Agent
MDA
The component that receives email from a mail transfer agent and stores it in the recipient's mailbox until retrieved.
Domain Name System
DNS
A hierarchical naming system that translates human-readable domain names into IP addresses.
Sender Policy Framework
SPF
Sender Policy Framework is an email authentication protocol that allows domain owners to specify which mail servers are authorized to send email on their behalf, helping receiving servers identify and reject spoofed messages.
DomainKeys Identified Mail
DKIM
DomainKeys Identified Mail is an email authentication mechanism that uses asymmetric cryptography to sign outgoing messages, allowing receivers to verify that the email was not altered in transit and originated from an authorized sender.
Domain-based Message Authentication, Reporting, and Conformance
DMARC
Domain-based Message Authentication, Reporting, and Conformance is an email authentication protocol that builds on SPF and DKIM to enable domain owners to specify how unauthenticated emails should be handled and to receive reports on message authentication activity.

Topics

Email Security Smtp Spf Dkim Dmarc Encrypted Protocols Network Security Email Authentication

Transcript

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?

How email flows

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.

SMTP

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.

Confidentiality and integrity

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.

Authenticity

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.

Spam

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?

Making email more secure

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.

About TechKnowSurge

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 →