Email Security: The Basics of Protecting Your Organization & Yourself

Cybersec Café #66 - 05/06/25

Email has been around for forever. Its invention is often credited to Ray Tomlinson, who in 1971 sent the first message using the now-iconic “@” to separate the user from the machine name.

Decades later, email is more essential than ever - it’s the backbone of business and communication around the world. And because of that, it remains one of the most abused attack vectors in the cybersecurity landscape.

Why?

Because technology is hard. People are easy.

And while we spend countless hours hardening our environments, email is often the weakest link - it’s embedded in every function of the business, its inner workings are finicky, and an attacker can wreak havoc in just one click.

That’s why every Security Engineer should have an understanding of how email works under the hood and be able to educate others on how to recognize and avoid phishing attacks.

The last thing you want is to secure your entire corporate stack, only for Karen in Marketing to let the hackers in the front door with a single click.

Here’s exactly what you need to do to protect your organization’s email, and your personal inbox.

How Email Works

Before we get into the more technical details, it’s important to understand the two types of email traffic and what each means from a security perspective:

• Ingress - These are the emails coming into your organization. From a security perspective, your responsibility is to protect your users from receiving malicious mail. In an ideal world, all potentially harmful emails would be stopped at the gateway - filtered, scanned, and removed before ever reaching an inbox. Even if something slips through, rescans from tooling should catch and quarantine it before it causes damage.

• Egress - These are the emails leaving your organization. From a security perspective, your responsibility is to protect your organization’s reputation by only allowing authorized, properly signed email to be sent from your domain. When customers receive an email claiming to be from your domain, they should have peace of mind that it actually came from you.

Protocols

Email relies on a few core protocols to get messages from sender to recipient.

After a user drafts an email and clicks send, the email client uses SMTP (Simple Mail Transfer Protocol) to deliver the message to the sender’s email server.

SMTP then looks up the recipient’s domain in DNS (Domain Name Server) to locate the destination server and hands off the message.

The recipient email server stores the email until the recipient retrieves it with their email client. They can use POP (Post Office Protocol) which downloads the email to the recipient device and typically deletes it from the server, or IMAP (Internet Message Access Protocol) which keeps the email on the server and allows the user to access it.

Records

For a while, email worked just fine without much security. Then threat actors realized just how easy it was to spoof messages, and the game changed.

To combat this, a series of DNS records were introduced over time, slowly building a layered approach to email security.

SPF (Sender Policy Framework) was first proposed in 1997 by Jim Miller, but was not publicly adopted until 2003.

SPF allows the domain owners to specify which servers are authorized to send emails on their behalf. It is limited to 10 total entries, which was thought to be sufficient at the time of its invention. But modern businesses often require more, and since then, tools have been created to bypass this restriction.

Here’s an example SPF record:

v=spf include:_spf.google.com include:mail.zendesk.com ~all

• This tells recipients that Google and Zendesk are authorized to send mail on behalf of the domain.

• ~all vs -all: Both were used before DMARC came along, but discarding mail based on SPF was causing too much legitimate mail to be dropped, so most receivers end up using SPF for anti-spam instead.

  • ~all notates a softfail, meaning not authenticated but still accepted

  • -all notates a fail, meaning reject unauthenticated mail

DKIM (DomainKeys Identified Mail) was developed in 2004 by merging Yahoo’s DomainKeys with Cisco’s Identified Internet Mail, and was published by the IETF in 2007 as a standard.

DKIM uses cryptographic signatures to verify that an email has not been tampered with in transit and that it came from an authorized sender. These records will vary based on selectors and keys, but most platforms walk you through setting them up.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) development efforts began in 2010 by a group of different organizations and vendors, and was officially published as a standard in 2012.

DMARC builds on SPF and DKIM by letting domain owners set policies on what to do with emails that fail authentication, and receive reports about those failures. This is done in the form of a policy tag:

• p=none: No enforcement, just monitor.

• p=quarantine: Directs unauthenticated emails to be sent to spam or quarantine folders.

  • pct=25: Dictates what percentage of the mail sent will have the policy applied (defaults to 100% if not set).

• p=reject: Instructs email servers to block unauthenticated mail completely.

Here’s a sample DMARC record:

v=DMARC1; p=quarantine; pct=30; rua=mailto:dmarc-reports@example.com;

BIMI (Brand Indicators for Message Identification) is the newest of the group, with the first formal spec being published in 2019, and officially gaining traction by 2021.

It is a standard that allows businesses to display their brand logo next to emails in supported email clients as a way to visually verify sender authenticity.

Domain Reputation

All of these records work together to influence your domain reputation, which is a measure of how trusted your domain is by Email Service Providers (ESPs) and anti-spam services.

Domain Reputation directly impacts email deliverability and influences whether your emails land in inboxes, get dumped into spam, or get blocked altogether.

Having a strong domain reputation means your emails are likely legitimate and secure. A poor reputation can lead to your emails being flagged, even if they’re harmless..

That’s why proper configuration matters. By authenticating all outbound email with the right DNS records, you help ESPs draw a clear line between real and fake - boosting your deliverability and protecting your brand.

---

- Today’s Sponsor -

Email is just the beginning. Your digital footprint spans far beyond your inbox - passwords, accounts, devices, and habits all play a role in your personal attack surface. SecuriBeat breaks down your entire personal security landscape into 15+ categories with clear, guided actions that actually make a difference. Understand your risk. Track your progress. Be proactive, not reactive, and start locking down your digital footprint today.

---

So, What Does It All Mean?

I know I just threw a lot at you, and while it may seem like there’s a lot going on, the big picture isn’t as bad as it may seem.

Let’s break it down by looking at what this means for ingress and egress email

Ingress vs Egress

For Ingress (incoming) email, smaller companies typically get by just fine with the built in protections provided by major ESPs like Gmail. These systems can scan and flag a good chunk of malicious mail out of the box.

Still, no filter is perfect. That’s why regular phishing awareness training for employees is essential, as it’s your next line of defense when something inevitably does slip through.

For larger organizations, relying solely on your ESP isn’t enough. You’re a bigger target, and you need to act as such. You’ll want a dedicated email gateway to inspect and filter mail before it ever reaches your employees. These gateways apply scoring algorithms to all mail and give you granular control over rules to determine what you want to allow in.

For Egress (outbound) email, your DNS records are critical. They signal to recipient mail servers whether an email claiming to come from your domain is actually legitimate.

Misconfigured records can lead to cases like threat actors spoofing your domain to phish your customers or legitimate mail getting dropped.

Either scenario hurts your brand. Getting these records right protects both your customers and your reputation.

What is Important for Organizations and End Users

If your organization sends a high volume of email, it’s crucial to work towards a p=reject DMARC policy. This ensures that only fully authenticated, legitimate emails reach recipient mailboxes.

Even with a p=quarantine policy, depending on your enforcement percentage, it’s entirely possible that illegitimate emails are making it through, or worse, that legitimate emails are getting blocked.

But don’t overlook a move to p=reject - it’s a methodical operation that shouldn’t be rushed. It requires careful monitoring, incremental enforcement, and consistent validation to ensure your records are dialed in.

If an organization doesn’t tighten up their records, it puts end users at risk of getting phished.

Sure, some phishing emails are easy to spot. But phishing isn’t just shady links and broken English from a so-called Nigerian prince anymore. Modern phishing campaigns are becoming extremely sophisticated, and without strong records, they can appear to come directly from your organization.

Locking down your records not only protects your users, but preserves a reputation.

What You Can Do as a Security Engineer

1. Remove SPF from Non-Sending Domains
   If a domain you control doesn’t send mail, it shouldn’t have an SPF record. Including SPF on a non-sending domain implies that mail is expected from it, which opens the door for spoofing. Removing the SPF record tells receiving mail servers to reject messages outright. It may sound obvious, but I’ve seen it happen before.

2. Verify and Align Your Sending Domains
   For domains that do send mail, ensure your SPF, DKIM, and DMARC records are properly configured. Start with SPF and make sure every listed sender is legitimate and expected. Then move to DKIM, confirming that each authorized mail source is signing messages and that the public keys are published correctly in DNS. Finish with DMARC, and set an enforcement policy that reflects your organization’s readiness.

3. Progress Toward p=reject Safely
   Begin moving towards a p=reject DMARC policy in a controlled, data-driven manner. Use a DMARC monitoring tool to analyze email, validate legitimate traffic sources, and identify any unknown senders before tightening enforcement. This transition can be complex, especially for larger organizations. So focus on measuring trends over time, resolving anomalies, and gradually increasing enforcement without setting a rigid timeline.

Education is Key

As with most things in security, education is huge. It’s important to consistently educate both your employees and your customers on how to stay vigilant against email-based threats.

I like to share two simple but powerful rules when it comes to email

1. Always Scrutinize, Never Trust: Just like everything in cybersecurity, a healthy level of skepticism goes a long way.

2. Never Click an Email Link: It’s just not worth it. Instead, open a new browser tab and type it in yourself. If it’s legitimate, prompts for what were in the email will be waiting for you.

If you’re ever unsure about an email, then I like to teach people my Headers Technique - a quick way to verify authenticity beyond just glancing at the “From” address.

And no, this isn’t just the basic “look at the sender” tip, because if a domain hasn’t secured their records it can still be spoofed.

Here’s how using Gmail:

1. Open the Email

2. Click the three-dot “More” menu

3. Select “Show Original”

You can now see the raw email headers. Look for the SPF, DKIM, and DMARC authentication results. If all three pass, then you can have increased confidence that the email is legitimate.

But remember, this isn’t foolproof. Sophisticated attacks can still sneak through these checks under the right conditions, and legitimate email can also still fail them.

So always trust your intuition and proceed with caution.

-

Now you’re armed with the knowledge to protect your organization, your users, and yourself - not just as a Security Engineer, but a cybersecurity enthusiast with an understanding of the inner workings of email.

Use this knowledge for good, and continue to fight against threat actors trying to scam innocent people every day.

---

Securely Yours,

Ryan G. Cox

---

Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.

Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.

. . .

Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!