SMTP Server Setup

What an SMTP server does

An SMTP server takes mail from your applications, newsletter platform or users and delivers it to recipients’ mail providers. A sending-only server has no mailboxes; its whole purpose is to hand messages over cleanly and keep trying sensibly when a receiver asks it to wait.

Getting it running is quick. Getting it right takes more care: authentication so receivers trust it, pacing so they don’t throttle it, queue settings so temporary failures are retried and permanent ones stop, and security so nobody else can use it to relay mail.

We build these servers to be diagnosable at the worst possible moment. Mail problems have a habit of appearing late at night or in the middle of a launch, and the difference between a five-minute fix and a lost evening is usually whether the logs clearly say what happened to a given message.

Signs you need a proper SMTP setup

• Your website or app sends mail through a local server nobody configured, and messages go missing.
• Large sends leave a queue that takes hours to drain, with many deferrals.
• You can’t tell from the logs why a particular message wasn’t delivered.
• Your newsletter platform needs a delivery server, and you want one you control.
• Your hosting provider has warned you about abuse from the server.

What’s included

• Postfix installed and configured as a dedicated sending server.
• Authenticated submission on port 587 with TLS, and relay restricted to known clients.
• DKIM signing, SPF and DMARC records aligned with your From domain.
• Reverse DNS and HELO hostname matched for each sending IP.
• Connection concurrency and rate limits tuned per receiving domain.
• Queue lifetimes and retry intervals set so mail isn’t dropped or retried forever.
• Structured logging and a simple way to trace any message by its queue ID.
• A firewall and brute-force protection on the submission port.

How we deliver it

1. Agree expected volume, peak rates and which applications will send through the server.
2. Provision the server and confirm port 25 and PTR control with the host.
3. Install and configure the MTA, authentication and TLS.
4. Publish DNS records and verify them externally.
5. Send test mail to major providers and inspect the authentication results in the headers.
6. Connect your applications with individual credentials so any misuse can be traced and revoked.
7. Document the configuration, including where to look when mail is delayed.

Rate, queue and logging decisions

Receivers each have their own tolerance for connections and messages per minute. A single global rate is either too slow for some or too aggressive for others, so we set limits per destination and let the server back off when it sees temporary failures. Temporary errors (4xx) are retried on a schedule; permanent errors (5xx) are returned as bounces and fed to your suppression list.

For deeper tuning, see Postfix configuration. For ongoing visibility, see email queue monitoring.

What affects timeline and cost

• Expected volume and whether multiple IPs are needed.
• Number of applications and domains sending through the server.
• Whether transactional and marketing mail need separate paths.
• Integration work on your applications or platform.
• Warm-up, if the IPs are new.

Common SMTP setup mistakes

Shared credentials across every application, so one leaked password exposes everything. Open relay rules left over from testing. Logs rotated away within a day. No DKIM because “SPF was enough”. Queue lifetimes so long that stale password-reset emails arrive days late. We check for each of these on every build.

Explore the rest of our email infrastructure services, read the email infrastructure guide, or contact us.

Frequently asked questions