Email Security Deep Dive: 13 Steps to Keep Your Emails Safe

The Email Security Checklist

1. Enable SPF (Sender Policy Framework)

What it is: SPF is like a guest list for your email domain. It tells the world that only specific servers are allowed to send email for your domain.

How it works:

• Publish an SPF record in DNS.
• When someone receives an email claiming to be from your domain, their mail server checks if the sending IP is listed in the SPF record.
• If the IP is not listed, the email is rejected or marked as spam.

Example SPF record:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all

Only servers in the specified IP range and Google’s mail servers can send emails for this domain. Others are rejected.

Points to Note:

• Prevents attackers from spoofing your domain and sending phishing or spam emails.

2. Enable DKIM (DomainKeys Identified Mail)

What it is: DKIM is a digital signature for each email, ensuring that the message hasn’t been tampered with.

How it works:

• Your mail server signs outgoing emails with a private key.
• Recipient mail servers verify the signature using your public key published in DNS.
• If the signature matches, the email is considered authentic and untampered.

Example DKIM record:

v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE

Scenario: If someone modifies the content of an email in transit, the DKIM signature breaks and the recipient sees the message as suspicious.

Points to Note:

• Ensures email integrity and authenticity.
• Improves domain reputation and email trustworthiness with providers.

3. Enable DMARC (Domain-based Message Authentication, Reporting & Conformance)

What it is: DMARC is a policy layer that combines SPF and DKIM, specifying what to do if authentication fails.

How it works:

• Define a rule: reject, quarantine, or allow emails that fail SPF/DKIM checks.
• Receive reports on failed authentication attempts.

Example DMARC record:

v=DMARC1; p=reject; rua=mailto:security@yourdomain.com

Scenario: Without DMARC, Gmail might accept spoofed emails. With DMARC set to reject, unauthorized emails are dropped before reaching the inbox.

Points to Note:

• Enforces consistent authentication policies across all receivers.
• Provides visibility into unauthorized email attempts.

4. Set up a Spam Filter

What it is: A mechanism that blocks junk emails and malware before they reach users.

How it works:

• Uses blacklists, heuristics, machine learning, and attachment scanning.
• Filters suspicious emails into spam/junk folders.

Example Filters: Barracuda, Mimecast, Proofpoint, Google Workspace built-in filter.

Points to Note:

• Reduces exposure to phishing and malware.
• Improves inbox hygiene and productivity.

5. Disable Relaying

What it is: Relaying allows outsiders to use your email server to send messages to third parties.

Bad Scenario:

• Your server is misconfigured as an open relay.
• Spammers use it to send millions of emails.
• Your domain/IP gets blacklisted, causing legitimate emails to bounce.

Points to Note:

• Always disable relaying unless explicitly allowing trusted servers.
• Prevents abuse and protects domain reputation.

6. Set a Throttling Policy

What it is: Rate-limits that prevent hacked or compromised accounts from sending mass spam emails.

Example Rules:

• Max 500 emails/day per user.
• Max 50 recipients/email.

Scenario:

• Alice’s account is hacked. The attacker tries to send 50,000 phishing emails.
• Throttling policy blocks after 500 emails, reducing potential damage.
• Example: If you send an email to 20 people in To, 15 in Cc, and 15 in Bcc, that totals 50 recipients → allowed. Sending to 60 recipients → blocked.

Points to Note:

• Prevents mass spamming if an account is compromised.
• Protects domain reputation and prevents blacklisting.
• Encourages using proper bulk mailing tools for legitimate campaigns (e.g., SendGrid, Mailchimp, Google Groups).

7. Restrict Local Email Domain

What it is: Prevents outsiders from sending fake emails that appear to come from your internal domain.

Scenario Explained:

Without Restriction (Bad Case):

• A hacker outside your company sends an email from ceo@company.com to finance@company.com.
• Your mail server delivers it because it looks like internal mail.
• The finance employee sees the fake CEO email and may wire money → this is called CEO Fraud / Business Email Compromise (BEC).

With Restriction (Good Case):

• The mail system only accepts emails claiming to be from @company.com if they come from official internal mail servers (e.g., Microsoft 365 or Google Workspace).
• The hacker’s email from an external server is blocked or flagged.
• Finance never sees the fake CEO email → attack fails.

Points to Note:

• Ensures only legitimate internal servers can send emails using your domain.
• Prevents CEO fraud, internal phishing, and business email compromise (BEC).

8. Set Attachment Restrictions

What it is: Block dangerous file types to prevent malware from entering your network.

Rules:

• Block extensions: .exe, .bat, .vbs, .jar, .scr
• Allow only safe extensions: .pdf, .docx, .png

Scenario:

• User receives invoice.pdf.exe disguised as a PDF.
• Without restrictions → malware executes on the system.
• With restrictions → email blocked at the gateway before reaching the user.

Points to Note:

• Since most malware is delivered via attachments, restricting risky file types is essential.
• Scan attachments to ensure even allowed file types are safe.

9. Ensure Log Visibility and History

What it is: Collect and monitor logs from mail servers to track activity and detect security incidents.

Example Logs:

• Was the email delivered?
• Did SPF/DKIM authentication fail?
• Who attempted to brute-force login?

Tools: Splunk, ELK, SIEM integration.

Points to Note:

• Logs are vital for investigating phishing attempts and delivery issues.
• Helps meet compliance and auditing requirements.

10. Consider Email Encryption

What it is: Ensures that only intended recipients can read the email content.

Types:

• S/MIME (uses certificates)
• PGP (uses key pairs)

Scenario:

• A lawyer sends confidential case files via email.
• Encrypted email ensures that even if intercepted, the content is unreadable.

Points to Note:

• Email encryption ensures confidentiality for sensitive information.
• Critical for industries like finance and healthcare to comply with regulations like HIPAA.

11. Enable DNSSEC (Domain Name System Security Extensions)

What it is: DNSSEC secures DNS records to prevent attackers from redirecting traffic or tampering with email-related DNS entries (like SPF, DKIM, and DMARC).

How it works:

• DNS responses are digitally signed using public-key cryptography.
• Only authenticated responses from the domain’s authoritative DNS server are accepted.
• This prevents DNS spoofing and cache poisoning attacks.

Scenario Example:

• A user tries to visit www.example.com.
• Without DNSSEC: An attacker poisons the DNS cache and redirects the user to www.fake-example.com, which looks identical. The attacker can capture login credentials.
• With DNSSEC: The browser or email server verifies the DNS response signature. If the response is altered, it is rejected, preventing the user from being redirected to a malicious site.
• Similarly, email servers checking SPF/DKIM/DMARC records rely on DNS. Without DNSSEC, attackers could alter TXT records to bypass email authentication, leading to phishing and spoofing attacks.

Points to Note:

• Secures DNS records against tampering and spoofing.
• Protects email authentication mechanisms (SPF, DKIM, DMARC).
• Prevents attackers from redirecting users to malicious websites.

12. Educate Your Community

What it is: Security is not just technology; it starts with people. Educating users on safe email practices is critical to reduce phishing and malware risks.

Key Training Topics:

• How to recognize phishing emails and social engineering attempts.
• Which files are safe to send or receive via email and alternatives for large file sharing.
• How to avoid clicking malicious links and detect suspicious email behavior.
• What information is safe to share via email.

Points to Note:

• A culture of security awareness reduces human error and prevents data breaches.
• Periodic refresher training ensures practices stay up-to-date.
• Supports technological measures like spam filters and email restrictions.

13. Regularly Test Configurations

What it is: Regular testing ensures that email security settings remain effective over time and configuration changes do not create vulnerabilities.

Tools for Testing: MXToolbox, G Suite/Office 365 security scorecards, and email spoofing simulations.

How to Test:

• Run periodic SPF/DKIM/DMARC checks to confirm proper email authentication.
• Send test emails to verify spam filters and attachment restrictions are working.
• Monitor logs for unusual activity or policy violations.
• Compare current settings with company security policies to prevent configuration drift.

Points to Note:

• Continuous testing ensures potential vulnerabilities are discovered and fixed promptly.
• Helps maintain compliance with internal and external security policies.
• Supports consistent protection against phishing, spoofing, and malware delivery.

Preventing CEO Impersonation in Emails

Q: How can we prevent someone from impersonating our CEO via email?

A: The best approach is to implement SPF, DKIM, and DMARC. SPF defines which mail servers are allowed to send emails for our domain. DKIM adds a digital signature to verify the integrity of the message. DMARC enforces policies based on SPF and DKIM results, for example, rejecting emails that fail both checks.

Q: Can you give a concrete example of how this works?

A: Suppose a hacker tries to send an email from ceo@company.com to finance@company.com using a free Gmail account. Our SPF record only allows our Google Workspace servers. SPF fails, DKIM fails because the email doesn’t have a valid signature from our domain, and DMARC rejects the message. This prevents the fraudulent email from ever reaching finance.

Q: Why is this better than just telling employees to be careful?

A: Technical controls like SPF, DKIM, and DMARC stop attacks before employees even see them. Human caution is important, but relying solely on users is risky, because phishing emails can look very convincing—like an urgent wire transfer request from the CEO.

Q: What if the hacker uses a Gmail account that is part of Google Workspace?

A: It must be part of our authorized Workspace domain. SPF only allows our corporate Workspace servers. A free Gmail account or Workspace account from another domain will fail SPF and DMARC, and DKIM signatures from other domains won’t validate against our public key.

Q: Could an internal employee accidentally impersonate the CEO?

A: We can restrict local email domain sending rules. Emails claiming to be from @company.com must come from official internal mail servers. Even internal machines or scripts outside the mail server cannot send as the CEO, preventing internal spoofing or accidental misuse.

Q: How can we monitor if someone is trying to spoof our domain?

A: DMARC reporting provides aggregate (rua) and forensic (ruf) reports about emails failing SPF/DKIM. We can see attempts, source IPs, and take corrective actions, such as updating DNS or investigating potential attacks.

Q: How would you explain this to a non-technical executive?

A: I would say: “We have a digital gatekeeper for emails. It checks if an email truly comes from us and hasn’t been tampered with. If a fake email tries to impersonate the CEO, the system blocks it before anyone sees it, preventing fraud.”

In preparing this blog, I referred to a helpful GitHub repository: Email Security Checklist Repository .

Additionally, AI platforms helped me understand the concepts in depth, allowing me to explain each step in a simple and practical way.