Email Security Audit: How to Test Your Email Security Posture

Most organizations assume their email security is adequate until a phishing campaign successfully spoofs their domain or a deliverability problem surfaces. Proactive email security auditing catches these gaps before attackers exploit them. This guide walks through a complete audit methodology using freely available tools and manual DNS checks, organized into the sections that matter most.

Audit Scope and Preparation

Before running any tests, enumerate what you are auditing:

1. All domains you own — including parked domains, older brands, and subdomains that send email
2. All mail sending services — your primary mail server, transactional email providers (SendGrid, Postmark, Mailchimp), CRM systems (Salesforce, HubSpot), ticketing systems, monitoring alerts
3. Inbound mail infrastructure — MX records, spam filtering, anti-malware
4. Client-side controls — end-user email clients, mobile device management, phishing awareness training

Run the audit from an external perspective (no special access). Your goal is to replicate what an attacker sees and what receiving servers check.

Step 1: DNS Authentication Records

Check SPF

Tool: MXToolbox SPF Analyzer at mxtoolbox.com/spf.aspx

Enter your domain and review:

• Does the record exist?
• Is it using -all (hard fail) or ~all (soft fail)? Hard fail is recommended.
• How many DNS lookups does it require? SPF has a 10-lookup limit. More than 10 causes permerror.
• Are all your sending services included?

Manual check:

dig TXT yourdomain.com | grep "v=spf1"

Common issues found:

• Missing include: for a transactional email service added recently
• SPF record not updated after migrating mail providers
• Multiple SPF records (only one is allowed; extras are silently ignored or cause errors)

Check DKIM

DKIM requires knowing your selectors. For Google Workspace the default is google, for Microsoft 365 it is selector1 and selector2. For custom setups you need to know your configured selector name.

# Replace 'google' with your selector, 'yourdomain.com' with your domain
dig TXT google._domainkey.yourdomain.com

Expected output contains v=DKIM1; k=rsa; p=<long-base64-string>.

Tool: MXToolbox DKIM Lookup at mxtoolbox.com/dkim.aspx — enter your domain and selector.

If the record does not exist or the public key does not match your mail server's private key, DKIM will fail.

Check DMARC

dig TXT _dmarc.yourdomain.com

Tool: MXToolbox DMARC Lookup at mxtoolbox.com/dmarc.aspx

Audit checklist:

• Does the record exist?
• Is p= set to reject or at minimum quarantine? p=none provides zero protection.
• Is rua= pointing to an active mailbox or reporting service?
• Are you receiving and reviewing DMARC aggregate reports?
• Does the policy cover subdomains (sp=reject)?

Check BIMI (if applicable)

dig TXT default._bimi.yourdomain.com

BIMI requires DMARC at enforcement level. If you are publishing BIMI without p=reject, the logo will not display in most clients.

Check MTA-STS

MTA-STS enforces TLS for inbound connections. Check if you have a policy:

dig TXT _mta-sts.yourdomain.com
curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

A missing MTA-STS policy means inbound mail can be downgraded from TLS to plaintext by a man-in-the-middle attacker.

Step 2: Send a Test Message and Score It

Tool: mail-tester.com

mail-tester.com generates a unique address. Send a real email from your domain to that address, then view your score and detailed report. The report covers:

• SPF, DKIM, DMARC pass/fail and alignment
• Spam scoring from SpamAssassin
• Message formatting issues (HTML/text ratio, broken links, missing unsubscribe)
• Blacklist checks for your sending IP
• DNSBL status

A score below 8/10 indicates deliverability problems. The detailed breakdown shows exactly which checks failed and why.

What to look for:

• DKIM: dkim=pass with your domain in header.i=
• SPF: spf=pass with alignment
• DMARC: dmarc=pass
• SpamAssassin score below 5 (ideally below 2)

Step 3: MX Record and Inbound Configuration Audit

Tool: MXToolbox Email Health Check at mxtoolbox.com/emailhealth.aspx

This runs 30+ checks including:

• MX record validity and priority
• Whether MX hosts resolve and accept connections
• Reverse DNS (PTR record) for your sending IPs — many spam filters require PTR records
• Whether your mail server is listed on major blocklists (Spamhaus, Barracuda, SURBL, etc.)
• TLS availability on your mail server

Blocklist check

If you find your sending IP is on a blocklist:

1. Identify why you were listed — most blocklist sites explain the listing reason
2. Clean the issue (compromised account sending spam, misconfigured relay, etc.)
3. Submit a delisting request through the blocklist's removal process
4. Most legitimate listings clear within 24–48 hours after the source of abuse is resolved

Step 4: Review Mail Server Headers

Analyze the full headers of a message you sent and received to verify authentication results end-to-end.

In Gmail: open the message, click the three-dot menu, select "Show original."

In Outlook: open the message, File > Properties, view Internet headers.

What to read:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=mail2026 header.b=AbCdEfGh;
  spf=pass (google.com: domain of you@yourdomain.com designates 203.0.113.10 as permitted sender);
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

All three should show pass. If any show fail, softfail, or neutral, that is the issue to fix.

Also check the Received: chain to verify TLS was used at each hop:

Received: from mail.yourdomain.com ... (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)

Missing TLS indicates an unencrypted SMTP hop.

Step 5: Check Parked and Subdomain Policies

A common oversight: protecting your primary domain but leaving parked domains and subdomains unprotected. Attackers specifically look for these.

Run checks for every domain you own:

# For each domain
for domain in yourdomain.com olderbrand.com parked-domain.net; do
  echo "=== $domain ==="
  dig TXT $domain | grep "v=spf1"
  dig TXT _dmarc.$domain
done

Every domain that does not send email should have:

v=spf1 -all
_dmarc.domain.com  TXT  "v=DMARC1; p=reject;"

Step 6: Review Forwarding and Inbox Rules

Account compromise often involves an attacker setting inbox rules to silently forward all email to an external address. Audit these regularly.

In Google Workspace Admin Console: Reports > User reports > Account activity > Forwarding.

In Microsoft 365:

Get-Mailbox -ResultSize Unlimited | Where-Object {$_.ForwardingSmtpAddress -ne $null} | Select-Object Name, ForwardingSmtpAddress
Get-InboxRule -Mailbox * | Where-Object {$_.ForwardTo -ne $null} | Select-Object Name, MailboxOwnerID, ForwardTo

Any external forwarding you did not explicitly set up should be treated as a potential compromise indicator.

Step 7: Document and Prioritize Findings

After running all checks, categorize findings by severity:

• Critical: No DMARC, p=none, no DKIM, domain on blocklist
• High: SPF missing -all, DMARC at quarantine but not reject, parked domains unprotected
• Medium: SPF lookup count near limit, DKIM key shorter than 2048-bit, no MTA-STS
• Low: Missing BIMI, mail-tester score between 8–9, DMARC not covering subdomains

Run this audit quarterly. Email sending infrastructure changes (new SaaS tools, new offices, provider migrations) break authentication records silently, and a quarterly audit catches drift before it becomes a deliverability or spoofing problem.