What Is Email Security? Controls, Threats and Gaps

Every other system a company runs can be closed to outsiders. The finance application takes input from people who were issued accounts. The code repository takes input from people who were added to it. Email takes input from anyone on earth who knows an address, holds it in a place where the recipient is expected to read and act on it, and does that for every employee at once. That is not a flaw somebody introduced. It is what the medium is for, and it is why an entire security domain exists to sit around it.

What Is Email Security?

Email security is the practice of protecting email as a system: the accounts people sign into, the domain names that appear in the From line, the servers that carry the messages, and the content inside them. The reason it has to be a practice rather than a feature is that the underlying protocol has no opinion about who you are.

Simple Mail Transfer Protocol will accept a message claiming to be from any address at any domain and pass it along. There is no built-in check that the sender owns the name they typed, and no encryption of the contents by default. Every mechanism people mean when they say email security is a retrofit bolted onto that. NIST says as much in the way it frames its own guidance: SP 800-177 Rev. 1, Trustworthy Email, recommends technologies "in support of core Simple Mail Transfer Protocol (SMTP) and the Domain Name System (DNS)" for authenticating a sending domain, securing transmission and protecting content. Support of, not part of.

That history explains the shape of the domain. Sender authentication lives in DNS records rather than in the mail protocol, content protection lives in a separate signing layer both sides have to set up, and filtering lives in a product somebody placed in the message path. None of it is on by default, and a company that has never touched any of it still sends and receives mail perfectly well, which is why so many organizations discover the gap only when somebody spoofs their domain or phishing lands in the finance inbox.

What Email Security Covers

Four jobs, and most buyers only think about the second one.

Authenticate the domain you send from. SPF, DKIM and DMARC records tell the rest of the internet which servers may send mail carrying your name, and what receivers should do with mail that fails. This protects your customers and partners from your brand, which is the part companies forget because the damage lands on somebody else.

Filter what arrives. Malware scanning and sandboxing of attachments, link inspection and rewriting, impersonation detection that reads the display name and the reply-to header, and spam classification. This is what most people picture, and it is roughly a quarter of the domain.

Defend the account. A mailbox is an identity as much as a message store. Multi-factor authentication, conditional access, alerting on new inbox and forwarding rules, and session monitoring all belong here because the mailbox is the target, even though the controls live in the identity provider.

Control what leaves. Data loss prevention on outbound messages, encryption for content that should not travel in the clear, and retention so messages can be produced later. Outbound is half the domain and gets a tenth of the attention.

The outermost and innermost layers are the two that cost the least and get skipped the most. A DMARC record is a DNS change. A report button is a configuration setting. Both do more for a small company than a second filtering product bolted in front of the first.

What Email Security Does Not Cover

Every vendor page lists what the domain includes. Almost none draws the edge, and the edge is where buyers get hurt, because a control that was never in scope still gets blamed when something goes wrong.

The device, once code is running on it. A filter that misses one malicious attachment has handed the problem to endpoint security, a separate domain with separate tooling. Email security stops delivery. It does not watch a process spawn.

Any channel that is not email. Social engineering moved onto phones, text messages and collaboration platforms years ago, and none of it passes through a mail filter. The 2026 Verizon Data Breach Investigations Report puts a number on how well that works: mobile-centric social engineering carries a success rate 40 percent higher than traditional email phishing. The best email security program in the world scores zero against a phone call.

The identity plane, when it is reached another way. An attacker who talks a help desk into a password reset, or walks an employee through an authentication prompt on the phone, is inside the mailbox and the wider tenant without a single message having been filtered, because nothing was sent.

Your suppliers' mailboxes. When the compromised account belongs to a vendor, the message arriving in your inbox is genuine mail from a genuine sender, correctly authenticated, sent by the wrong person. That is a vendor risk program problem as much as a filtering one, and it is growing: the same DBIR found third-party involvement in breaches up 60 percent year over year, now present in 48 percent of breaches.

Why Is Email Security Important?

Because email is where money moves and where trust is assumed. A finance team that receives an invoice by email treats it as an instruction. A new employee who receives an onboarding link by email clicks it. The medium carries an implicit authority that no other input channel has, and attackers price that accurately.

The second reason is reach. Every other system has a subset of staff who use it. Email has all of them, including the contractor who joined last week and the executive who will not sit through a course, which makes it one of the few places where a single configuration change moves the risk for everyone at once.

The third reason is that the sending side is now a business requirement, not just a defense. Google's email sender guidelines require every sender to set up SPF or DKIM, transmit over TLS, and keep the spam rate reported in Postmaster Tools below 0.3 percent. Senders of 5,000 or more messages a day to Gmail accounts must also publish DMARC, align the From domain with the SPF or DKIM domain, and support one-click unsubscribe. A company that ignores email authentication is now choosing worse deliverability as well as a spoofable domain.

Common Email Security Threats

The catalog is long, and the useful way to hold it is by what the attacker is after: your click, your money, your credentials or your attention.

Phishing and spear phishing

A message that impersonates something familiar to get a credential or a click. Bulk phishing goes to thousands and converts on volume. Spear phishing is written for one person from public detail about their job, their vendors and their colleagues, and whaling is the same aimed at an executive. All three are one problem with different budgets behind them, and the tells that give a message away shift as the writing gets better.

Business email compromise

The most expensive category by a wide margin, and the one filters handle worst, because the successful version contains no attachment, no link and no malware. It is a plain text message about a payment, sent from a lookalike domain or from a real compromised mailbox inside a real thread. Business email compromise defeats content inspection by having no malicious content to inspect.

Malware and ransomware delivery

An attachment that carries code, or a link to a page that delivers it. Document formats supporting macros and embedded scripts are the durable vehicles, because they arrive looking like work. Plenty of ransomware intrusions still begin with a file somebody opened, which is why attachment sandboxing, detonating the file in an isolated environment before delivery, is a real control.

Domain spoofing and impersonation

Three distinct tricks that get lumped together. Exact-domain spoofing forges your actual domain in the From line, and DMARC at enforcement stops it. Lookalike domains register something one character away, and DMARC does nothing about them because the attacker owns that domain legitimately. Display name impersonation puts a real person's name on a free mail account, which is neither and defeats both.

Account takeover

A mailbox with valid credentials on it is worth more than any single message: the attacker gets the archive, the address book, the thread history and the ability to send as someone the recipients already trust. Credential stuffing supplies the passwords in bulk when people reuse them, and a fake sign-in page or a help desk call supplies them one at a time.

Spam and graymail

Unwanted bulk mail is a productivity problem now more than a security one, and classifiers handle it well. It matters here for one reason: a noisy inbox trains people to clear messages fast without reading them, and speed is the condition every other attack on this list depends on.

Data leaving by email

The threat that arrives from inside. A spreadsheet attached to the wrong recipient, a customer list forwarded to a personal account before somebody resigns, a report sent to a partner who should never have seen the raw data. Outbound inspection belongs to email security because email is the easiest exfiltration route in any company and requires no tooling at all.

How Email Security Works

A message travels a defined path, and every product in this domain is a decision about where in that path to stand.

The sender's server looks up your domain's MX record in DNS, connects to whatever that record points at, and delivers the message over SMTP. Whatever sits at the address in that record sees the mail first. After delivery, the message lands in a mailbox inside your provider, where a different class of product can reach it through an API.

In front of the MX record. A secure email gateway changes your DNS so mail reaches it before your provider. It inspects, decides, and forwards what survives, so it can block a message before anyone sees it. It cannot see internal mail between two of your own employees, because that traffic never leaves the tenant, and it is a second place where mail can queue when it breaks.

Inside the tenant. API-based products connect to Microsoft 365 or Google Workspace with permissions rather than DNS. They see the message only after delivery, and they see everything: internal mail, mailbox rules, sign-in patterns, and old mail they can search retroactively. Their action is retraction rather than blocking, so there is a window, usually seconds, when the message sits in the inbox.

Neither position sees the future. A link that resolves to a harmless page at delivery can be swapped for a credential harvester an hour later, which is why time-of-click inspection exists: the delivered link points at the vendor, which checks the destination again when the person actually clicks.

What Are SPF, DKIM and DMARC?

Three DNS records doing three different jobs, and the reason people find them confusing is that only the third one connects to what a human actually sees.

SPF, Sender Policy Framework, is a DNS list of the servers permitted to send mail for your domain. It checks the envelope sender, a hidden address rather than the From line in the mail client, and it breaks on forwarding because the forwarder is not on your list.

DKIM, DomainKeys Identified Mail, is a signature added to the message by your sending server and verified against a public key you publish in DNS. It proves the domain signed the message and that the signed parts were not altered on the way, and it survives forwarding, which SPF does not.

DMARC, Domain-based Message Authentication, Reporting and Conformance, ties the first two to the From address the reader sees. It requires that SPF or DKIM passed and that the domain which passed matches the visible From domain, a condition called alignment. It then tells receivers what to do with failures, at three settings: none, quarantine or reject, and asks them to send aggregate reports to an address you nominate, which is how you find who is sending as you before you turn enforcement on.

The federal government treated this as basic hygiene nearly a decade ago. CISA's Binding Operational Directive 18-01 gave agencies 90 days to offer STARTTLS on internet-facing mail servers and to publish valid SPF and DMARC records with a policy of at least p=none and a reporting address, then one year to reach a DMARC policy of reject on all second-level domains and mail-sending hosts. The staged path in that directive is still the right sequence for a private company: publish at none, read the reports until you know every legitimate sender, then move to quarantine and reject.

Types of Email Security Solutions

The market sells overlapping slices, and the honest first question is what your existing subscription already includes.

The last row deserves more weight than the market gives it. Security awareness training is sold on click rates, and click rate is the less useful of the two numbers. Report rate turns a workforce into a sensor network: one person reporting a message at nine in the morning lets a responder pull the same message from forty other mailboxes before lunch.

How Email Encryption Protects a Message

Two different things get called email encryption, and they protect against different attackers.

Transport encryption is TLS negotiated between mail servers, usually through STARTTLS. It protects the message while it moves between two servers, and it is opportunistic by default, meaning that if the far end does not offer TLS, most senders deliver in the clear rather than fail. MTA-STS and DANE exist to close that downgrade, by letting a domain publish that it requires TLS. What transport encryption does not do is protect the message at rest on either server, or from anyone with access to either mailbox.

Message-level encryption encrypts the content itself, with S/MIME or PGP, so that only the holder of the recipient's private key can read it. NIST's Trustworthy Email guidance covers both halves, recommending TLS for transmission security and S/MIME for the encryption and authentication of message content. This is real end-to-end protection, and the reason it stayed rare is key management: both sides need certificates, key distribution has to work, and lost keys mean lost mail. Most organizations that need this outcome use an encryption portal instead, where the recipient collects the message from a web page after authenticating.

Neither kind helps with the failure that actually happens most. Encryption protects a message from someone in the middle. It does nothing when the message was addressed to the wrong person on purpose or by accident, and nothing when the attacker is signed into the mailbox and reading everything the owner can read.

Email Security Best Practices

Ordered by how much risk each one removes for the effort, rather than by how it looks on a checklist.

How to Choose an Email Security Provider

Start from the gap rather than the category. A company being spoofed needs DMARC enforcement and a reporting platform, and a new filter will not help. A company losing money to invoice fraud needs a payment verification process and internal-mail visibility, not better attachment sandboxing. A company whose staff cannot report anything needs a button and a triage owner. Buying the wrong slice is the expensive mistake here, and it happens because vendors in all four slices describe themselves with the same two words.

Then ask what the product can see from where it sits, what it does with a message it judges bad after delivery, how it handles a compromised internal sender, and what happens to mail flow during its own outage. Ask how quarantine release works too, because a filter people cannot get their real mail out of gets bypassed within a month.