Email Configuration Check: Test Your Mail Server

A mail server configuration check is the email equivalent of a server health check — running specific tests against specific layers to confirm everything works. Most senders only test the obvious surface (does mail get delivered?) and miss the deeper configuration issues that erode reputation over months. This guide walks through the full audit.

The layers to test

Layer	What to check	Tools
DNS records	MX, SPF, DKIM, DMARC, PTR	MXToolbox SuperTool, dig
SMTP transport	Ports, TLS, AUTH, RCPT TO	swaks, telnet
Authentication validity	Signature, alignment, pass	Mail-Tester, Mailhardener
End-to-end delivery	Test send to real recipients	Seed accounts, Mail-Tester
Blocklist status	IP and domain reputation	HetrixTools, Spamhaus
Bounce handling	Hard/soft bounce processing	ESP logs, MTA queue

Skip a layer and you'll have blind spots.

Layer 1: DNS records

Check each required record exists and is correctly formatted.

MX records

dig MX yourdomain.com +short

Should return your mail-receiving server(s) with priority values. Missing MX = inbound mail doesn't route.

SPF

dig TXT yourdomain.com +short | grep spf

Should return one v=spf1 ... record. Common issues: missing record, multiple records (RFC violation), too many DNS lookups (>10 = fails), missing ~all or -all qualifier.

See SPF setup and SPF flattening.

DKIM

dig TXT selector._domainkey.yourdomain.com +short

Replace selector with your DKIM selector (commonly default, google, mail, or ESP-specific). Should return a v=DKIM1; ... record with the public key. Missing or malformed = DKIM fails on all sends.

See DKIM setup and DKIM key rotation.

DMARC

dig TXT _dmarc.yourdomain.com +short

Should return v=DMARC1; p=quarantine; rua=mailto:... (or p=reject). p=none is monitoring-only and doesn't trigger enforcement signals at ISPs.

See DMARC setup and DMARC none to reject.

PTR (reverse DNS)

dig -x 198.51.100.42 +short

Should return a hostname that resolves back to the same IP (forward-confirmed reverse DNS, FCrDNS). Missing or mismatched PTR is a common reason for SMTP rejections.

Layer 2: SMTP transport

Test that the mail server responds correctly on the right ports with the right TLS configuration.

Port reachability

nc -zv mail.yourdomain.com 25
nc -zv mail.yourdomain.com 587
nc -zv mail.yourdomain.com 465

Confirm each expected port responds. Port 25 for MTA-to-MTA relay; 587 for authenticated submission (preferred); 465 for legacy implicit-TLS submission.

TLS

openssl s_client -connect mail.yourdomain.com:465 -showcerts
openssl s_client -starttls smtp -connect mail.yourdomain.com:587

Check: certificate is valid (not expired, matches hostname), TLS version is 1.2 or 1.3, certificate chain is complete.

For MTA-STS / TLS-RPT, also verify those records:

dig TXT _mta-sts.yourdomain.com +short
dig TXT _smtp._tls.yourdomain.com +short

See MTA-STS setup.

Full SMTP transaction with swaks

swaks --to [email protected] \
      --from [email protected] \
      --server mail.yourdomain.com:587 \
      --tls \
      --auth-user user \
      --auth-password pass \
      --header "Subject: Configuration test"

Full transcript shows EHLO, AUTH, MAIL FROM, RCPT TO, DATA, response codes. Identifies any failure point.

Practitioner note: swaks is the most-undervalued tool in email diagnostics. A single command tests TLS, auth, RCPT TO, and content delivery while showing the complete SMTP transcript. I use it constantly during deliverability audits to isolate which layer is failing. Most senders never install it because their ESP hides the SMTP layer entirely.

Layer 3: Authentication validity

DNS records present is not the same as authentication passing on real sends. Validate end-to-end:

• Mail-Tester — send a test message, get full SPF/DKIM/DMARC validation in the report
• Mailhardener — ongoing authentication monitoring with DMARC report aggregation
• MXToolbox SuperTool DMARC report — checks alignment on a sample message
• Aspmx.l.google.com Authentication-Results — actually send to a Gmail account you control, view full headers

The Authentication-Results header in the actual delivered message is the ground truth.

Layer 4: End-to-end delivery

Send test messages to seed accounts across major ISPs. Confirm:

• Message arrives (not bounced)
• Message lands in Inbox (not spam/junk)
• Authentication-Results show pass for all three
• Display formatting renders correctly
• Links work

Manually check Gmail, Outlook.com, Yahoo, Apple Mail at minimum. Free if you maintain your own seed accounts; paid tools (GlockApps) automate.

Layer 5: Blocklist status

1. MXToolbox blacklist check on sending IP
2. MXToolbox blacklist check on sending domain
3. Spamhaus direct check
4. HetrixTools ongoing monitoring

See RBL test guide and email blacklists guide.

Layer 6: Bounce handling

Confirm:

• Hard bounces (550) suppress the recipient immediately
• Soft bounces (4xx) retry per RFC timing (typically 4 attempts over 48 hours)
• Bounce processing is enabled in your ESP (check settings)
• Feedback loop registrations are active for major ISPs (FBL with Yahoo, JMRP with Microsoft, Postmaster Tools with Google)

See bounce handling best practices and email bounces explained.

Common configuration issues found in audits

From client audits, the most common issues:

Issue	Frequency	Severity
DMARC at p=none (monitoring only)	Very common	High
SPF too many DNS lookups	Common	High
Missing PTR / FCrDNS mismatch	Common	High
DKIM key on wrong selector	Common	High
TLS certificate expired	Occasional	High
MTA-STS not deployed	Very common	Medium
Bounce processing disabled	Occasional	High
Authenticated submission on port 25 (should be 587)	Occasional	Medium
Multiple SPF records (RFC violation)	Common	High
DMARC missing rua= for aggregate reports	Very common	Medium

Practitioner note: The fastest sender-side wins I find in configuration audits are: rotating DMARC from p=none to p=quarantine after 30 days of monitoring (improves Gmail reputation), deploying MTA-STS (gives ISPs confidence in your TLS), and adding the rua= reporting endpoint (so you can see who is sending as you). Each takes under an hour to implement and DNS-level.

A complete check workflow

DNS layer (10 min):
- dig MX, SPF, DKIM, DMARC, PTR
- MXToolbox SuperTool overall check

SMTP layer (15 min):
- nc port reachability test
- openssl s_client TLS test
- swaks full SMTP transaction test

Authentication layer (5 min):
- Mail-Tester end-to-end check

Delivery layer (15 min):
- Send to 5-7 seed accounts across ISPs
- Verify inbox placement and Authentication-Results

Blocklist layer (5 min):
- MXToolbox blacklist check
- HetrixTools status review

Bounce handling (10 min):
- Confirm ESP bounce settings
- Verify FBL/JMRP/Postmaster Tools active

Total: 60-90 minutes for a thorough configuration audit.

For broader context see email deliverability guide, deliverability audit DIY checklist, and email authentication guide.

If you need help running a full mail server configuration audit or fixing the issues found, book a consultation. I do configuration audits weekly for senders dealing with deliverability problems.

Sources

• RFC 5321 — SMTP
• RFC 7489 — DMARC
• RFC 8461 — MTA-STS
• swaks Documentation
• MXToolbox SuperTool
• Mail-Tester Documentation

---

v1.0 · May 2026