OAuth or SMTP for warm-up? What each connection method costs you

If you are warming a Gmail or Microsoft mailbox, connect it over OAuth. If you are warming a relay — Amazon SES, SendGrid, Mailgun, Postmark, your own MTA — you will use SMTP for sending, and you need a separate IMAP connection somewhere to see where mail actually lands. The difference is not cosmetic: a sending-only connection cannot tell you whether a message reached the inbox or Junk, which is the only thing a warm-up measurement is for.

What each method can and cannot do

OAuth is also the safer grant in the sense that matters operationally: you can revoke one application without touching the account, and you can see what you have granted. A shared password cannot be scoped and cannot be revoked selectively.

Legacy access is closing, unevenly

Basic authentication and app passwords have been progressively shut off across the major providers, and the direction of travel is one way. Microsoft has been retiring basic auth for mail protocols in Exchange Online over several years, and Google requires OAuth for API access while continuing to allow app passwords in narrower circumstances than it used to. The practical consequence is that a warm-up or sequencing tool wired up with an app password is a tool that will stop working on a schedule you do not control, usually on the morning of a campaign.

Legacy access still exists for a reason, though. Plenty of regional hosts, appliances and scanners speak only SMTP with a password, and if you are warming a custom relay there is no OAuth to use. That is fine — just connect IMAP as well so placement is observable, and keep the credential in a secret store rather than in a tool's settings screen.

Forwarding is the thing that quietly breaks authentication

This matters for warm-up because warm-up pools and shared mailboxes often involve forwarding, and forwarding breaks SPF by design. When alice@example.com forwards to alice@gmail.com, the forwarding server connects to Gmail from its own IP. The envelope sender is still example.com, whose SPF record does not list that IP, so SPF fails at Gmail.

Sender Rewriting Scheme is the partial fix: the forwarder rewrites the envelope sender into its own domain so SPF evaluates against the forwarder.

Original envelope sender:  bounce@example.com
After SRS rewrite:         SRS0=abc1=XY=example.com=bounce@forwarder.net

SPF now passes — for the forwarder. But DMARC requires alignment with the visible From: domain, and forwarder.net does not align with example.com. So SRS saves SPF and does nothing for DMARC. The thing that survives forwarding is DKIM, because the signature travels with the message and covers headers and body rather than the connection. As long as the forwarder does not rewrite the subject, append a footer or re-encode the body, DKIM still validates and DMARC still passes on the DKIM leg. ARC exists to let a forwarder vouch for the original result, and the large providers do consult it, but you cannot rely on it being honoured everywhere.

The design conclusion is simple: sign everything with DKIM aligned to your From: domain, and avoid building a warm-up or routing scheme that depends on forwarding. Deliver to the real mailbox instead.

What not to do

Do not share one password across tools. When it leaks you cannot tell which tool leaked it, and rotating it breaks everything at once. Do not grant full-mailbox OAuth scopes to a tool that only needs to send and read placement — ask what it requests. Do not enable POP3 to make an old integration work; POP downloads and can delete, and it gives you no folder visibility. Do not assume a password reset revoked access: existing OAuth grants and app passwords survive it, and you must revoke them explicitly. And do not route warm-up mail through a forwarder to save creating mailboxes — you will spend the next month debugging SPF failures that are not bugs.

One more honest note on method and outcome

The connection method affects what you can measure and how reliably the plumbing holds. It does not change whether warm-up is defensible. Ramping volume on real mail with real recipients is sound practice. Manufacturing opens, clicks and replies between controlled mailboxes is the behaviour Validity's Heatwave blocklist, launched on 3 September 2026, was built to catch — it lists domains rather than IPs, launched with over a million listed, and its thresholds are not published, so no tool can honestly offer you exemption from it.

MailPilot supports both paths: OAuth for Gmail and Outlook, and SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom relays. Either way it reads real folder placement per provider through its seed network, checks SPF, DKIM and DMARC on the sending domain, and records per-mailbox reputation daily.