Monitoring9 min readUpdated:

SMTP and email deliverability troubleshooting

Deliverability is a chain. Separate connection failure, SMTP rejection, queue delay and spam-folder placement before changing configuration.

“The email did not arrive” can describe several failures. The app may not have submitted it, the message may remain queued, receive an SMTP rejection, bounce after acceptance or land in spam.

Collect the message ID, exact time, sender, recipient and full log response first. Without them, symptoms are easily mistaken for causes.

Connection, port and TLS

Resolve recipient MX records and test outbound port 25. For submission use 587 with STARTTLS or 465 implicit TLS as documented. The certificate must match the hostname used by the client.

  • Do not test STARTTLS as immediate TLS on the same port.
  • Check sending-IP PTR.
  • Verify time synchronisation.

SMTP codes and queues

A 4xx response is generally temporary and retryable; 5xx is permanent. Read the full enhanced status code and the recipient provider policy.

Authentication and reputation

Check SPF/DKIM alignment with the From domain, DMARC policy, IP reputation and DNSBL status. Also assess content, volume and recipient-list quality.

  • Separate transactional and marketing streams.
  • Remove hard bounces and honour unsubscribes.
  • Monitor blocklist state changes.

Mail support evidence

  • Message-ID and send time.
  • Full SMTP status and response.
  • Received headers or bounce report.
  • SPF, DKIM, DMARC, PTR and DNSBL results.

Put it into practice

Check email security

Validate MX, SPF, DKIM, DMARC, MTA-STS and key domain dependencies.

Check email security

Frequently asked questions

Does one configuration fit every environment?

No. Inventory traffic, dependencies and the threat model first, then tighten controls. Verify each change externally and keep a rollback plan.

Where should I start?

Start with a tested backup, current patches and a smaller public attack surface. Then add monitoring and document an owner for every service.

How often should I repeat the review?

After every infrastructure or major-version change and at least quarterly. Monitor critical dependencies, certificates and backup outcomes continuously.