Warming up a custom SMTP domain: what's different from OAuth warm-up

Warming up a mailbox connected over OAuth and warming up a domain sending through custom SMTP — SendGrid, Amazon SES, Mailgun, Postmark, or a self-hosted relay — follow the same volume-ramp logic underneath, but the connection itself works differently and gives you less for free.

What's different about SMTP/IMAP warm-up

OAuth-connected providers (Gmail, Outlook/Microsoft 365) give a warm-up tool a direct, authenticated view into the mailbox through the provider's own API, including some read access to how mail is labelled on arrival. A custom SMTP setup has no equivalent single API — sending goes through SMTP, and verifying what actually arrived requires a separate IMAP connection into a receiving mailbox. That means warm-up visibility on the SMTP side depends entirely on how completely the tool polls IMAP, not on anything the sending provider exposes directly.

Ports and settings you need

Confirm these with whichever relay you're using — SendGrid, SES, Mailgun, and Postmark all publish their own exact hostnames and port requirements, and a custom self-hosted relay needs its own TLS certificate configured correctly before any of this works.

Setting the ramp schedule

The ramp logic itself doesn't change: start at low daily volume, increase gradually over two to four weeks, hold or slow down if bounce or complaint rate rises. What does change is that a custom SMTP domain, especially a newly configured relay, often has zero sending history anywhere, so treat it with the same caution as a brand-new domain even if the underlying infrastructure (SES, SendGrid, etc.) is well-established — the reputation that matters is tied to the sending domain and IP, not just the platform's general standing.

Monitor reputation and placement

Because there's no provider-side dashboard equivalent to Gmail's inbox giving you placement for free, monitoring an SMTP-warmed domain depends more heavily on:

• IMAP polling of seed mailboxes to check actual placement
• Bounce and complaint feedback loops configured correctly with the relay (SES and others support feedback loop subscriptions — set these up before you need them, not after a problem)
• Blocklist lookups, since a flagged IP on a shared-sending relay can affect you even if your own sending pattern is clean

Common SMTP mistakes

- Sending from port 25 and getting silently blocked by the sending network
- No IMAP verification set up, so "it sent" is mistaken for "it arrived in the inbox"
- Using a shared IP pool from the relay without checking that pool's existing reputation
- Skipping DKIM signing because the relay's default setup didn't enable it automatically
- Ramping the same day the domain was first configured, with zero sending history anywhere

Check DKIM signing specifically — some relays require you to generate and publish a DKIM key yourself as a separate step from basic account setup, and skipping it means mail may send successfully over SMTP but fail authentication checks on arrival.

What doesn't change

Volume discipline, authentication correctness, and genuine engagement matter exactly as much for an SMTP-warmed domain as for an OAuth-warmed mailbox. The connection method is different; the thing you're trying to build — a domain and IP with a consistent, trustworthy sending history — is the same.

Testing the connection before relying on it

Before trusting an SMTP/IMAP warm-up setup with real volume, send a handful of test messages manually and verify, by hand, that they arrive, pass authentication checks, and show up correctly in the IMAP-connected receiving mailbox. This catches configuration mistakes — a wrong port, a certificate issue, a DKIM key that wasn't actually published — while the cost of a mistake is a handful of test messages rather than a ramping campaign that silently never reached its intended placement.

Shared infrastructure and its reputation baggage

A relay like SendGrid or Mailgun on a shared IP pool carries some reputation inherited from other senders using that same pool, which is outside your control. If deliverability seems unexpectedly poor despite a clean domain and correct authentication, check whether your relay offers a dedicated IP option, and check the relay's own status or abuse pages for known issues with the shared pool you're on — this is a genuinely different failure mode from anything about your own sending practices.

MailPilot connects to custom SMTP/IMAP relays including SendGrid, Amazon SES, Mailgun, Postmark, and self-hosted setups, ramps volume on the same schedule logic it uses for OAuth-connected mailboxes, and checks SPF, DKIM, and DMARC so a skipped authentication step gets caught before it becomes a delivery problem.