SMTP Relay Service for Cold Email: A Selection Test

An SMTP relay service accepts a message from your sending system and attempts to transfer it toward the recipient's mail server. For cold email, choose the relay only after confirming that the provider permits your exact use, can authenticate the identities you control, exposes its IP-pool behavior, and enforces understandable throughput caps. It must also suppress failed recipients and return message-level events. It is a transport decision, not a sending-platform or mailbox-provisioning decision.

Start with permission to use the relay

A technically capable relay can still be the wrong provider if its terms prohibit your sending model. Read the current acceptable-use policy and product terms, plus the enforcement documentation. Give the provider a plain description of audience sourcing, message type, complaint handling, opt-out handling, and expected sending pattern. Preserve the written answer.

Do not interpret account approval as permanent permission for every campaign. Terms can distinguish transactional and subscribed marketing mail from unsolicited bulk mail. The relay decision also does not answer which laws apply to your recipients or whether a particular contact is eligible for outreach. Those are separate business and legal decisions.

Our view is that ambiguous permission is a failed procurement result. A lower price cannot offset the risk of building operations on a use the provider may suspend.

Verify authentication and domain alignment

The relay should let you authenticate as an approved sender without borrowing an identity you do not control. Ask how it verifies sending domains, which envelope domain it uses, where DKIM signing occurs, whether you can control the signing domain, and how credentials are scoped and rotated.

Google's email sender guidelines require SPF or DKIM for all senders to Gmail, with SPF, DKIM, and DMARC requirements for bulk senders. The same guidance says the visible From domain for direct email must align with either the SPF domain or DKIM domain to pass DMARC alignment. Use those statements as Gmail requirements, not as a promise of placement.

Google Workspace's official SMTP relay setup guide shows how its relay can restrict allowed senders, require SMTP authentication, authenticate by IP, and require TLS. That is one provider's configuration model. Your test should still prove the effective message headers and transport settings for every identity in scope.

Send a controlled message, retain the raw headers, and map the visible From domain, return-path domain, DKIM d= domain, sending IP, and relay message ID. Hold the provider if the expected identity cannot be explained from its own evidence.

Identify the IP pool you are actually buying

Shared pools spread reputation and capacity across customers. Standard dedicated IPs isolate the sending IP but leave the sender responsible for stable use and reputation. Managed dedicated products may allocate or warm capacity on the provider's terms. The label alone is not enough.

Ask which pool carries traffic during onboarding, normal sending, volume spikes, and provider maintenance. Ask whether the pool can change without notice and whether the logs expose the actual sending IP. Amazon SES documents that its managed dedicated IP feature can spill some traffic into the SES shared pool during warm-up or a sudden rise in sending rate. That behavior is specific to the product, but it shows why "dedicated" needs an operational definition.

A dedicated IP is not automatic proof of better delivery because it concentrates responsibility on your traffic. If your volume is uneven or too small to establish a stable pattern, a shared or provider-managed option may be the more defensible test candidate.

Test throughput caps as operating controls

Request the daily allowance, sustained acceptance rate, burst behavior, concurrent-connection limit, recipient counting rule, and retry response. Distinguish a documented account quota from the rate the service accepts in practice.

Amazon SES's sending-quota documentation separates the messages allowed in a rolling daily period from the rate accepted each second. It also states that a request exceeding the daily maximum is rejected and that actual acceptance can be below the account's maximum send rate.

Build your test below the approved cap, then observe a controlled limit case. The sending system should slow or queue work rather than hammering the relay. Record the response code, retry delay, duplicate-prevention behavior, and final message state. A quota visible only after production starts is not an adequate control.

Inspect suppression ownership and behavior

The relay needs a defined response to permanent failures, complaints, and addresses your business has suppressed. Ask whether suppression is global, account-level, configuration-specific, or tenant-specific. Confirm who can add, remove, export, and audit an entry. Determine whether a suppressed submission is rejected immediately, accepted but not sent, or represented another way.

Amazon SES's account-level suppression documentation supports bounce and complaint reasons and describes provider-specific handling for submitted addresses already on the suppression list. Do not assume another relay behaves the same way.

LeadHaste practice is to keep the client-owned suppression record upstream and treat the relay list as another enforcement point. We reconcile both rather than letting a provider-only list become the sole record. This is our operating choice, not a requirement imposed by SMTP.

Demand message-level logs you can reconcile

A dashboard total is not enough. Require a stable message ID, submission timestamp, authenticated sender, recipient, sending IP or pool, relay response, receiving-server response, retry history, bounce class, suppression decision, and export path. Set a retention period that fits your investigation and reporting needs.

Test at least four known outcomes: normal remote acceptance, local provider rejection, a permanent recipient failure, and a temporary delay. Confirm that each event connects to the original submission without relying on subject text. Amazon SES's event-data documentation distinguishes send, delivery, bounce, reject, and delivery-delay records. Its delivery event refers to passing a message to the recipient's mail server and includes that server's SMTP response. Those definitions apply to SES, but they illustrate the evidence a relay can expose.

Keep the relay boundary narrow

This selection does not choose your sequencing interface, provision inboxes, register domains, source recipients, write copy, or build an end-to-end outbound operation. A relay can transmit a message while another product decides timing and another system stores the prospect record.

Write the handoffs before contracting: sending platform to relay, relay to receiving server, relay events to reporting, and suppression changes back to the client-owned record. Our email authentication service guide covers a separate acceptance package for SPF, DKIM, and DMARC. LeadHaste's broader outbound services connect the relay to the rest of the client-owned system.

Ready to test a relay against real handoffs?

We can review your ICP, campaign fit, relay boundary, identity evidence, suppression ownership, and logging requirements before you commit. Book your free discovery call →