How to Audit Your Email Infrastructure for Security Weaknesses

Your email infrastructure is more exposed than you think. MX records are public. SMTP banners often reveal server software and versions. TLS configurations can be tested by anyone. Authentication records (SPF, DKIM, DMARC) are DNS queries away.

Attackers enumerate all of this before sending a single phishing email. You should audit it first.

This guide walks through a comprehensive email infrastructure audit using free, publicly available tools. No special access needed — everything here uses the same information an attacker would find.

What we are auditing

Layer	What to check	Tools
DNS records	MX, SPF, DKIM, DMARC	dig, nslookup, MXToolbox
SMTP server	Banner, TLS, open relay, ports	telnet, openssl, CheckTLS
IP reputation	Blacklists, reverse DNS	MXToolbox, MultiRBL
TLS configuration	Protocol versions, cipher suites, certificate	SSL Labs, testssl.sh
Authentication	SPF alignment, DKIM signing, DMARC policy	mail-tester.com, Google Postmaster
Exposure	Server versions, information leaks	Shodan, manual SMTP test

Step 1: Audit your MX records

MX records tell the world which servers accept email for your domain. They are the front door of your email infrastructure.

dig MX yourdomain.com +short

Expected output:

10 mx1.yourdomain.com.
20 mx2.yourdomain.com.

What to check

• Do you have multiple MX records? A single MX is a single point of failure. If that server goes down, all inbound email bounces. Always have at least two MX records with different priorities.
• Do the MX hostnames resolve? Run dig A mx1.yourdomain.com for each. An MX record pointing to a hostname that does not resolve means email delivery fails silently.
• Are there stale MX records? If you migrated from one provider to another, old MX records may still be present. Email will randomly go to the old server (round-robin between equal-priority records) or fall back to it if the primary is slow.
• MX records must point to A/AAAA records, never CNAMEs. This is an RFC requirement. Some DNS providers allow it, but it can cause unpredictable behavior with strict mail servers.

If you use Cleanbox Relay, your MX records should point to mx1.cleanbox.to (priority 10) and mx2.cleanbox.to (priority 20). Any old MX records from your previous setup should be removed.

Priority and failover

MX priority determines which server is tried first (lower number = higher priority). Sending servers connect to the highest-priority server. If it is unreachable, they fall back to the next.

Common mistake: setting both MX records to the same priority. This creates round-robin delivery — email is randomly distributed between both servers. This is fine for load balancing but can cause inconsistent behavior if the servers have different configurations.

Step 2: Audit your SPF record

dig TXT yourdomain.com +short | grep spf

Expected output:

"v=spf1 include:_spf.google.com include:_spf.cleanbox.to -all"

What to check

• Do you have exactly one SPF record? Multiple SPF records on the same domain cause both to fail. This is one of the most common misconfigurations. If you see two v=spf1 records, merge them into one.
• Does it end with -all (hard fail)? ~all (soft fail) is more permissive — unauthorized servers get flagged but not rejected. -all tells receivers to reject unauthorized senders. Use -all in production.
• Are all your sending services included? If you send email through Gmail, Mailchimp, SendGrid, and Cleanbox, all four must be in your SPF record. A missing include means legitimate email fails SPF.
• Are you under the 10-lookup limit? SPF allows a maximum of 10 DNS lookups. Each include: is one lookup, and each included record may contain further lookups. Exceeding 10 causes SPF to permanently fail. Check with MXToolbox SPF Checker.

For a detailed SPF setup guide, see The Complete Guide to Email Authentication.

Step 3: Audit your DKIM

DKIM is harder to check from the outside because you need to know the selector name. Check with your email provider:

# Common selectors to try
dig TXT google._domainkey.yourdomain.com +short
dig TXT selector1._domainkey.yourdomain.com +short
dig TXT default._domainkey.yourdomain.com +short

A valid DKIM record returns a long TXT string starting with v=DKIM1;.

What to check

• Is DKIM enabled? If no DKIM record exists for any selector, your outbound email is not signed. This is a significant deliverability and security gap.
• Is the key long enough? RSA keys should be at least 1024 bits (2048 is recommended). Short keys can be cracked. Look for the p= value in the DKIM record — a very short base64 string suggests a weak key.
• Do all sending services have their own DKIM? Each service (Google Workspace, Mailchimp, etc.) should sign with their own DKIM key. Multiple DKIM signatures are fine and encouraged.

Step 4: Audit your DMARC

dig TXT _dmarc.yourdomain.com +short

Expected output:

"v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"

What to check

• Do you have a DMARC record? No DMARC record means no protection against domain spoofing. Anyone can send email pretending to be from your domain.
• What is the policy?
  • p=none — Monitor only. No protection. Useful during initial setup but should not stay here permanently.
  • p=quarantine — Failed emails go to spam. Good intermediate step.
  • p=reject — Failed emails are bounced. Maximum protection. The goal state.
• Are you receiving reports? The rua= tag specifies where aggregate reports are sent. If missing, you are flying blind — you do not know who is spoofing your domain.
• Is sp= set for subdomains? Without sp=, subdomains inherit the main policy. Attackers often spoof subdomains (hr.yourdomain.com) to bypass DMARC on the root domain.

For the full DMARC nuance, including why strict rejection is not always right (forwarding scenarios), read our dedicated article.

Step 5: Audit your SMTP server

Connect directly to your mail server to see what it reveals:

telnet your-mx-hostname 25

The server responds with a banner:

220 mail.yourdomain.com ESMTP Postfix (Ubuntu)

What to check

• Does the banner reveal software and version? "Postfix (Ubuntu)" tells an attacker exactly what software you run and which OS. They can look up known vulnerabilities for that specific version. Configure your server to show a generic banner:

  # Postfix: in main.cf
  smtpd_banner = $myhostname ESMTP
  
  # Exim: in exim.conf
  smtp_banner = $primary_hostname ESMTP

• Is it an open relay? An open relay accepts and forwards email from any sender to any recipient. Spammers exploit open relays to send millions of emails through your server. Test:

  telnet your-mx-hostname 25
  EHLO test
  MAIL FROM:<attacker@evil.com>
  RCPT TO:<victim@gmail.com>

  If the server responds 250 OK to a recipient outside your domain, you have an open relay. This is critical — fix immediately.
• Does EHLO reveal capabilities you do not need? Some servers advertise features like VRFY (verify if a user exists) and EXPN (expand mailing list members). Disable these — they help attackers enumerate valid email addresses.

Step 6: Audit TLS configuration

Test your mail server's TLS configuration:

openssl s_client -connect your-mx-hostname:25 -starttls smtp

Or use the online tool: CheckTLS.com

What to check

• Is TLS enabled at all? If the server does not advertise STARTTLS, all email is transmitted in plain text. This is a critical finding.
• Which TLS versions are supported? TLS 1.0 and 1.1 are deprecated and have known vulnerabilities. Only TLS 1.2 and 1.3 should be enabled. Check:

  # Test for old TLS versions (should FAIL)
  openssl s_client -connect your-mx-hostname:25 -starttls smtp -tls1
  openssl s_client -connect your-mx-hostname:25 -starttls smtp -tls1_1

  If either connects successfully, disable those versions.
• Is the certificate valid? Check the certificate chain: is it expired? Is the hostname matching? Is it self-signed? Self-signed certificates provide encryption but no identity verification — a man-in-the-middle can substitute their own certificate.
• Are weak cipher suites enabled? RC4, DES, 3DES, and export-grade ciphers are broken. Use modern cipher suites only (AES-GCM, ChaCha20-Poly1305).

For background on TLS in email, see The Importance of TLS Encryption in Email.

Step 7: Audit IP reputation

Check your mail server's IP against blacklists:

• MXToolbox Blacklist Check — Checks 80+ blacklists at once
• MultiRBL — Checks 200+ blacklists

What to check

• Is your IP on any blacklists? Even one listing can significantly impact deliverability. Each blacklist has its own delisting procedure. See How DNSBL blacklists work for details.
• Does your IP have valid reverse DNS (PTR)?

  dig -x YOUR_IP +short

  The result should be a hostname that matches your mail server. Missing PTR records are flagged by most spam filters.
• Does the PTR match the EHLO hostname? Your server announces itself as mail.yourdomain.com in the EHLO command. The PTR record should resolve to the same hostname. A mismatch is suspicious.
• Are you on a shared IP? On shared hosting, other users on the same IP can damage its reputation. If your IP is on a blacklist and you are not sending spam, someone else on the same server probably is. Consider a dedicated IP or use a relay service to separate your reputation from your hosting.

Step 8: Audit for information exposure

Check what information about your email infrastructure is publicly discoverable:

Shodan search

Search Shodan for your mail server IP. Shodan indexes SMTP banners, TLS certificates, open ports, and server software. An attacker can find your exact Postfix version, your OS, and which ports are open without sending you a single email.

DNS enumeration

Check what subdomains are discoverable. Tools like dnsenum, subfinder, or online services can find subdomains that reveal your infrastructure: mail., smtp., webmail., autodiscover. (Exchange), imap..

Email header analysis

Send yourself an email and examine the headers. Do they reveal:

• Internal IP addresses (RFC 1918 ranges like 10.x.x.x or 192.168.x.x)?
• Internal hostnames (server names, Active Directory domains)?
• Software versions (X-Mailer, X-Originating-IP)?

For a guide on reading headers, see Understanding Email Headers: A Complete Guide. For what metadata reveals, see What Your Email Metadata Reveals About You.

Step 9: Send a test email

The simplest audit: send a test email and analyze the results.

• mail-tester.com — Send an email to their address and get a 0-10 score with specific issues identified (SPF, DKIM, DMARC, blacklists, content)
• learndmarc.com — Specifically for testing authentication (SPF, DKIM, DMARC alignment)
• Google Postmaster Tools — If you send to Gmail users, this shows your domain reputation, spam rate, and authentication pass rates over time

The audit checklist

Check	Tool	Pass criteria	Severity if failing
Multiple MX records	dig MX	2+ records, different priorities	Medium (availability)
SPF record exists	dig TXT	One v=spf1 record, ends with -all	High (deliverability + spoofing)
SPF under 10 lookups	MXToolbox	<= 10 DNS lookups	High (permanent SPF failure)
DKIM enabled	dig TXT selector._domainkey	Valid DKIM record, 2048-bit key	High (deliverability)
DMARC at reject	dig TXT _dmarc	p=reject with rua= reporting	High (spoofing protection)
No open relay	telnet test	Rejects external-to-external	Critical (abuse)
Generic SMTP banner	telnet	No software version in banner	Low (information leak)
TLS 1.2+ only	openssl / CheckTLS	TLS 1.0/1.1 disabled	Medium (encryption)
Valid certificate	openssl	Not expired, hostname matches	Medium (trust)
Not on blacklists	MXToolbox / MultiRBL	Clean on all major lists	High (deliverability)
Reverse DNS matches	dig -x	PTR matches EHLO hostname	Medium (deliverability)
VRFY/EXPN disabled	telnet	Commands rejected	Medium (enumeration)
No internal IPs in headers	Header analysis	No RFC 1918 addresses leaked	Low (information leak)

How often to audit

Trigger	What to check
Quarterly (routine)	Full checklist above
After adding a sending service	SPF record (new include), DKIM (new selector)
After server migration	MX records, PTR record, TLS certificate, SMTP banner
After a deliverability drop	Blacklists, SPF/DKIM/DMARC alignment, Google Postmaster
After a security incident	Open relay test, banner exposure, credential leaks

The shortcut: use a relay

Many of these audit items become irrelevant when you route inbound email through a relay service like Cleanbox Relay. The relay's MX records, TLS configuration, IP reputation, and SMTP hardening are managed for you. Your actual mail server is hidden behind the relay and only accepts connections from the relay's IPs (enforced via the verification token).

This does not eliminate the need to audit your outbound configuration (SPF, DKIM, DMARC still matter for email you send). But it dramatically reduces the inbound attack surface.

For the complete relay setup, see Setting up Relay for your domain. For building a comprehensive email security stack, see Building an Email Security Stack for Small Businesses.