SMTP Logging Best Practices: What to Record, Store, and Review

SMTP logs are the most useful diagnostic tool you have for email infrastructure — and one of the most commonly neglected. When delivery fails, when you suspect abuse, or when an audit turns up an anomaly, the logs are where you find answers. But logs are only useful if they're capturing the right things, stored long enough to be searchable, and structured in a way that makes investigation practical.

This guide covers what SMTP logging should capture, how to store it, and how to actually use it when something goes wrong.

What SMTP Logs Should Capture

A well-configured mail server logs each stage of the SMTP transaction. At minimum, your logs should record:

• Connection details: timestamp, source IP, destination IP, port, and TLS status
• Authentication events: AUTH attempts (success and failure), username used, mechanism used
• Envelope data: MAIL FROM address, RCPT TO addresses, message ID
• Delivery outcome: accepted, deferred, bounced, or rejected — with the specific reason code and message
• Queue events: when a message was queued, when delivery was attempted, how many retries occurred
• Error codes: 4xx and 5xx responses with the full text

What logs should not capture: message body content, subject lines, or attachment data. Storing message content in logs creates privacy and data protection problems and is rarely necessary for operational purposes. The envelope and delivery metadata is almost always sufficient for diagnostics.

Log Levels: Finding the Right Verbosity

Most mail server software (Postfix, Exim, Sendmail, Haraka) offers configurable log verbosity. Too little and you can't diagnose problems. Too much and the logs become noise — and storage costs spike.

A reasonable production configuration:

• INFO level for normal operations: connection accepted, message queued, delivery success
• WARN level for soft failures: deferred delivery attempts, TLS negotiation fallback, quota warnings
• ERROR level for hard failures: authentication failures, 5xx rejections, queue overflow
• DEBUG level: only enable temporarily when actively diagnosing a specific problem. Debug logs are high-volume and should never run continuously in production.

Review your log volume regularly. If you're generating more than you can practically store and search, tighten verbosity. If a delivery problem takes more than 15 minutes to diagnose because the logs don't have enough detail, increase it.

How Long to Keep SMTP Logs

Retention for SMTP logs should align with your operational needs and compliance obligations:

• 90 days minimum for operational diagnostics. Most delivery problems are identified within days, but some — like reputation degradation or low-volume spam from a compromised account — take weeks to surface.
• 12 months for organizations subject to regulatory oversight or with SLAs that require proof of delivery.
• 7 years in certain financial, healthcare, or legal contexts where email delivery records are part of audit trails.

Whatever retention period you choose, document it and enforce it consistently. Logs kept indefinitely become an uncontrolled data store that's hard to search and expensive to maintain.

Diagnosing Delivery Failures With Logs

When a message doesn't arrive, the most important thing is to identify where in the chain it failed. Start with the message ID — every email has one, generated by the sending server, visible in the email headers. Search your logs for that message ID to trace its path.

The log will show you:

• Was the message accepted into the queue?
• Did delivery attempt? How many times?
• What response did the receiving server return?
• Was it a temporary or permanent failure?

From the response code and message in the log, you can identify whether the problem is a blocklisting, a recipient address issue, a TLS failure, or an authentication rejection. The SMTP error codes guide is useful to keep alongside log analysis sessions.

Security Investigations and Log Analysis

SMTP logs are a critical tool for detecting compromised accounts and abuse. Patterns worth monitoring for:

• Unusual volume spikes from a specific account or IP
• AUTH failures followed by a success (credential stuffing attempt)
• New source IPs authenticating to existing accounts
• MAIL FROM addresses that don't match the authenticated user
• High rates of RCPT TO rejections (dictionary harvesting)

These patterns are hard to spot by reading logs manually. Set up log parsing to generate alerts when thresholds are crossed — for example, more than five consecutive AUTH failures from the same IP, or a single account generating more than 500 outbound messages per hour.

This connects directly to the security hardening covered in the SMTP relay security checklist.

Structured Logging and Centralized Log Management

Flat-file logs stored on the mail server are fine for small setups. As infrastructure grows, they become unwieldy. Structured logging — where log entries are formatted as key-value pairs or JSON rather than free-form text — makes logs searchable and parseable by log management tools.

Shipping logs to a centralized system (an ELK stack, a cloud log service, or a SIEM) gives you:

• Full-text search across all servers from one interface
• Dashboard visibility into delivery rates, error rates, and queue depth
• Alerting on log patterns without manually parsing files
• Controlled retention with automatic expiry

Even if you're not ready for a full SIEM, shipping logs to a centralized store is worth the investment. Log analysis during an incident on a single server is manageable; across five servers it becomes a serious time sink.

Log Rotation

Unmanaged log files grow without limit. Configure log rotation to split logs into daily or weekly files and automatically compress old entries. Most Linux systems handle this with logrotate, which can be configured to keep logs for a specific number of days and compress anything older than 24 hours.

Make sure log rotation doesn't interfere with log shipping — if your log aggregator reads from a file handle, rotation that moves the file can cause it to miss entries. Use logrotate's copytruncate option or configure your log shipper to follow rotated files correctly.

For complete visibility into your email infrastructure's health, SMTP logs pair naturally with the operational monitoring covered in the email operations KPIs guide. If you're using MailDog's SMTP relay, delivery logs and event data are available through the dashboard and API.