Email Security Checklist

This is a work-in-progress. Most of what is contained here were originally culled from my experience over the years. I have slowly been going back and trying to find backup documentation, validate assumptions, and ensure I’m up to date. The ‘checklist’ is vendor-agnostic at this point and geared more towards the protocols in general, with a focus on security and resiliency.


  • Pick an MTA that supports the options described below, and configure them appropriate to your situation.
  • Leave room for exceptions as not everyone on the internet will come close to running a complaint MTA. You will always have a critical business partner that just doesn’t care.
    • When making exceptions, try not to make global exceptions like whitelisting a domain. Be as granular as possible by whitelisting the sender’s specific mail server, or an individual address.
    • Exceptions for non-compliance to RFCs should not exempt the message from passing thru higher-level security scans such as malware, phishing filters, etc.

Client Security

  • Require strong passwords (KC)
  • Use multifactor authentication when appropriate - webmail, etc. (KC)
  • Use TLS to secure all client access methods (not just web) (NIST)
  • User awareness

Server Security

  • Deploy behind firewall/IPS
    • At least deploy a host firewall and possibly HIDS (NIST)
  • Deploy in a DMZ, behind a firewall and not NAT’d from the local network
  • Ensure logging is configured and forwarded to a centralized logging server
  • Multiple DNS Servers
    • Find supporting information
  • MX Records
    • According to RFC5321 section 2.3.5, MX records must point to one or more A/AAAA records, and cannot be CNAME records. The sending MTA will loop the destination’s MX records in order of ascending priority until a connection can be made and the message successfully transferred (RFC5321 section 5)
    • While SMTP does have a store-and-forward design, servers will typically purge undeliverable email after a certain period of time has passed. Having at least two MX records ensures that email can be delivered to an online server.
    • Resilience Strategies
      • At least 2 MX records in different subnets, similar to how DNS recommends servers in difference subnets for DoS protection.
      • A primary MX and a backup MX which could be another service provider paid to store your mail if you go offline.
  • Reverse DNS matches Forward DNS (KC)
  • SPF Record (KC)
  • DMARC Record
  • DomainKeys/DKIM (KC)
  • RFC
  • Prefer (or enforce) TLS transmission (KC)
  • Enforce relay control (KC)
  • Rate Control/Tarpitting
  • Verify FROM
  • Verify RECEIVED BY Headers
    • RDNS lookups - reject if (KC)
  • RBL lookups - reject/flag (KC)
  • SPF lookups - flag/reject
  • DKIM/DomainKeys - flag/reject
  • Content Filtering (Chris)
    • Attachment blocking (Chris) - block executables and common malware vectors
      • Use both file extension and file headers to determine file type - foils renamed files
      • Executables - EXE, BIN, COM (others)
      • Scripts - BAT CMD PS1
      • Screen Savers - SCR
      • Flash/Shockwave
      • Windows Help Files - HLP and newer version?
      • Compiled HTML - MHT, MHTML files
      • Advanced level - stripping based on regex’s for commonly used schemes to hide dangerous extensions from users (but this really wont be needed if you are doing the basics)
  • Malware scanning (KC)
    • Strip known malware (matching sigs) (Chris)
    • Scan within archive/zip files (Chris) - multilevel
    • Mark encrypted attachments as suspect? (Chris) - worth the discussion as malware vector but also common for security
    • AdvancedConsidering deploying unknown files in a sandbox

      Find RFC/Documentation backup

  • Enforce the use of TLS (KC)
  • Strong Passwords (KC)
    • Require strong passwords which have not been used in a known breach.
  • Backup/Recovery
    • Perform a routine configuration backup - at least before each time you change the configuration. Store the configuration off-server for security.
    • Perform a routine data backup of all mailbox contents.
  • Patching - routinely patch the server (NIST)
  • Prevent password guessing (NIST)
    • Account lockouts, etc.
    • Consider fail2ban on linux machines (Chris)
  • After-reception attack prevention
    • Scan mailboxes on a routine basis and remove malware. This will provide malware protection for messages received before the attachment or sender was determined to be dangerous.
  • NIST
  • KC (by Kim Crawley)