---
title: How to Evaluate an SMTP Relay Service | SendHQ
description: Evaluate SMTP relay services by submission security, authentication, queues, retry behavior, limits, delivery events, suppression, isolation, and migration fit.
canonical: https://sendhq.cc/guides/smtp-relay-service
last-updated: 2026-08-24
---
# What should a product team evaluate when choosing an SMTP relay service?

Evaluate an SMTP relay service as a controlled message-submission and operations system, not merely a hostname and port. Verify mandatory TLS, supported submission ports, SMTP AUTH controls, credential isolation, sender-domain verification, queue durability, documented 4xx and 5xx behavior, quotas, message-size limits, delivery-status events, bounce and complaint handling, suppression scope, tenant isolation, observability, and exportability. Test the exact clients and networks that will connect. A relay's 250 response transfers responsibility for further handling; it does not prove receiving-server delivery or inbox placement.

## Separate submission from server-to-server relay

Product teams often use “SMTP relay” to mean an authenticated service that accepts outgoing messages from an application and transfers them toward recipient mail servers. Standards distinguish that submission role from relay between mail servers. RFC 6409 reserves port 587 for message submission and allows submission servers to apply authentication, policy, and message-correction rules that differ from port 25 relay. Ask each provider which interface you are buying: authenticated submission for applications, inbound server-to-server relay, or both. Record the hostname, ports, encryption modes, authentication mechanisms, sender rules, and supported SMTP extensions. A service that works for a desktop client may not fit a high-volume queue, while a server relay may reject application authentication. Test the exact role instead of assuming that all SMTP endpoints behave alike.

## Require protected submission and safe authentication

Do not send credentials or message content over an unprotected connection. RFC 8314 treats cleartext submission as obsolete, recommends TLS 1.2 or later for submission traffic, and prefers implicit TLS where supported. RFC 4954 defines SMTP AUTH and requires servers to offer a configuration that does not permit plaintext password mechanisms without TLS or equivalent protection. During evaluation, confirm certificate validation, supported TLS versions, implicit-TLS and STARTTLS ports, downgrade behavior, and whether authentication is refused before encryption. Keep relay credentials in server-side secret storage, create separate principals for environments and applications, and rotate them without downtime. Determine whether permissions can restrict sender domains or message classes. A single shared credential across production tenants makes revocation, attribution, and incident containment needlessly broad.

## Check client and network compatibility

Inventory every sender before choosing a relay: application libraries, queue workers, monitoring appliances, business software, multifunction devices, and legacy systems. Some support port 587 with STARTTLS, some require implicit TLS, and some cannot validate modern certificates or authenticate safely. That limitation is a reason to isolate or replace the client, not to weaken the relay account globally. Test DNS resolution, IPv4 and IPv6, outbound firewall rules, connection timeouts, proxy behavior, TLS negotiation, AUTH, EHLO extensions, message-size limits, and internationalized addresses if required. Cloud environments can restrict port 25, so a provider's alternate submission ports matter operationally. Run the compatibility test from each production network rather than a developer laptop. Document a supported configuration and block fallback to cleartext or an unapproved hostname.

## Understand acceptance, queues, and retries

SMTP replies are part of the application contract. A 2xx completion indicates success for that command; after final message acceptance, the relay assumes responsibility for delivery or a later failure notification under SMTP rules. A 4xx response is transient and can justify retry, while a 5xx response is permanent for the attempted command and normally requires correction rather than repetition. Ask how long the service queues messages, which failures it retries, its backoff schedule, when it generates a delivery-status notification, and whether queued mail survives a regional failure. Your application still needs a stable job identifier, bounded connection retries, and protection against ambiguous outcomes. If the connection breaks after DATA, blindly creating a new job can duplicate mail. Persist the relay's message identifier when available and reconcile before resubmitting.

## Measure capacity with the right units

Relay limits can apply to recipients per rolling day, messages per second, concurrent connections, recipients per transaction, bytes per message, attachment size after encoding, and stored queue depth. A plan advertising a large monthly total can still throttle a launch burst or a failover. Request current limits for each account and Region, then model normal, peak, retry, and full failover traffic by recipient rather than only SMTP sessions. Determine whether the relay returns a transient reply when throttled and whether your client honors it without opening excessive connections. Test backpressure below the approved ceiling, and alert on remaining quota, connection saturation, queue age, and throttle responses. Do not increase concurrency until the provider and receiving ecosystem can support the traffic. Capacity is also an abuse boundary, so evaluate per-credential and per-tenant controls rather than only one account-wide maximum.

## Verify sender authentication and domain onboarding

A relay should provide an exact, reviewable domain-onboarding flow. Confirm how it verifies ownership, produces DKIM selectors, configures the envelope MAIL FROM domain, and reports authentication status. SPF authorizes SMTP identities and must be merged into an existing valid record rather than published as a second selectable SPF record. DKIM associates a signing domain with a cryptographic signature. DMARC evaluates whether a successful SPF or DKIM identifier aligns with the visible From domain and lets the domain owner publish policy and receive reports. Ask who controls signing keys, selector rotation, return-path alignment, and DNS changes during migration. Send controlled messages and inspect received headers before production. A dashboard showing “verified” does not prove that every legitimate stream is aligned, and authentication does not establish inbox placement.

## Demand usable outcome events and correlation

SMTP submission alone gives command replies, while product operations need later outcomes. Evaluate whether the service exposes receiving-server delivery, bounce, complaint, rejection, delay, and suppression events through authenticated webhooks, queues, or APIs. Determine event identifiers, retry behavior, ordering guarantees, retention, signature verification, and whether recipient detail can be redacted. RFC 3461 defines an SMTP extension for requesting delivery-status notifications under selected conditions, but provider event systems can offer more structured operational data. Map your application job ID to the relay message ID at acceptance, then ingest events idempotently. Keep acceptance, delivery to a recipient mail server, complaint, bounce, and inbox placement as different concepts. Open and click observations require separate privacy review and should not overwrite transport truth.

## Evaluate suppression and reputation boundaries

A production relay must make bounce and complaint response operationally possible. Ask whether it maintains provider-wide, account, subaccount, domain, or tenant suppression lists; which event types add entries; whether an address can be queried before submission; and how removals are authorized. Permanent bounces and complaints should stop routine future attempts, while temporary delays need a separate policy. In a shared account, determine whether one tenant's complaint can suppress another tenant's legitimate recipient or affect the whole account's reputation. Review dedicated versus shared IP options only in relation to actual volume, isolation needs, warmup ownership, and incident response. No network choice compensates for unexpected mail, poor recipient data, or ignored complaints. Require dashboards and alerts for bounce and complaint changes, but retain your own normalized events so migration does not erase operational history.

## Test tenancy, observability, and failure recovery

Create two test tenants and prove that each credential can send only from its approved domains, view only its messages, and consume only its own limits. Attempt an unauthorized From address, revoked credential, oversized message, invalid recipient, rate-limit breach, TLS failure, network timeout, duplicate submission, bounced recipient, complaint, delayed delivery, and repeated webhook. Verify that logs contain a stable message ID, tenant, sanitized response class, attempt count, and timing without copying credentials or message bodies. Ask the provider for status history, incident communication, regional failover behavior, data residency, retention, export formats, and support escalation. A service-level claim is useful only when the application can detect violation and recover. Run a failover exercise with queued messages and prove that the alternate configuration has verified domains, credentials, quotas, events, and suppression state.

## Compare SMTP relay with an email API

SMTP submission is valuable when existing software already speaks SMTP or when a provider-neutral mail transport interface matters. An HTTPS email API can provide structured validation, resource identifiers, batch semantics, and direct event resources that are easier for a new application to control. Teams that require legacy SMTP compatibility should select a documented relay or build a tightly controlled adapter. Teams building new product workflows can compare an API layer on authorization, queues, events, tenant boundaries, migration cost, and operational ownership rather than assuming SMTP is automatically more portable.

## Run a scored relay evaluation

Build a requirements matrix before requesting proposals. Weight submission security, client compatibility, domain onboarding, authentication alignment, queue durability, retry semantics, quotas, event completeness, webhook verification, suppression scope, tenant isolation, observability, data handling, regional design, support, exportability, and total operating cost. Mark hard failures separately from preferences: cleartext fallback, no bounce or complaint path, unverifiable events, shared credentials, missing domain ownership checks, or limits below peak demand should not be averaged away by a low price. Execute the same controlled test suite against every finalist and retain transcripts with secrets removed. Score current documented behavior, not roadmap promises. Before migration, rehearse dual sending at low volume, DNS changes, event reconciliation, suppression transfer, credential rotation, rollback, and final revocation of the old relay.

## Frequently asked questions

**What is the difference between SMTP submission and relay?**

Submission accepts outgoing mail from an authenticated client, normally using port 587 and submission-specific policy. Relay describes transfer between mail servers, commonly over port 25, with different trust and routing rules.

**Should an SMTP relay require TLS?**

Yes for application submission. Require certificate-validated TLS and refuse credential use or message submission when the configured confidentiality level is unavailable. Test both the supported port and downgrade behavior.

**Does SMTP 250 mean the recipient received the message?**

No. It means the server accepted responsibility for the completed SMTP command or message. Later delivery-status notifications or provider events describe receiving-server delivery, bounce, complaint, delay, or rejection.

**How should an application retry SMTP failures?**

Retry transient 4xx and network failures with bounded backoff and stable job identity. Correct 5xx failures before another attempt, and reconcile ambiguous post-DATA failures to avoid duplicate messages.

**Do SMTP relays handle DKIM, SPF, and DMARC?**

Capabilities vary. Confirm who signs DKIM, which MAIL FROM domain is used, what SPF mechanism is required, and whether SPF or DKIM aligns with the visible From domain for DMARC.

**When is an email API preferable to SMTP relay?**

An API can be preferable for new applications that need structured validation, resource identifiers, explicit tenant authorization, batch results, and event resources. SMTP remains useful for existing SMTP-capable software.

## Sources

- [RFC 6409: Message Submission for Mail](https://datatracker.ietf.org/doc/html/rfc6409) — Internet Engineering Task Force
- [RFC 8314: TLS for Email Submission and Access](https://datatracker.ietf.org/doc/html/rfc8314) — Internet Engineering Task Force
- [RFC 4954: SMTP Service Extension for Authentication](https://datatracker.ietf.org/doc/html/rfc4954) — Internet Engineering Task Force
- [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321) — Internet Engineering Task Force
- [RFC 3461: SMTP Delivery Status Notifications](https://datatracker.ietf.org/doc/html/rfc3461) — Internet Engineering Task Force
- [RFC 6376: DomainKeys Identified Mail Signatures](https://datatracker.ietf.org/doc/html/rfc6376) — Internet Engineering Task Force
- [RFC 7208: Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208) — Internet Engineering Task Force
- [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc7489) — Internet Engineering Task Force
- [Connecting to an Amazon SES SMTP endpoint](https://docs.aws.amazon.com/ses/latest/dg/smtp-connect.html) — Amazon Web Services
- [Amazon SES SMTP issues and response codes](https://docs.aws.amazon.com/ses/latest/dg/troubleshoot-smtp.html) — Amazon Web Services
- [SendHQ OpenAPI contract](https://sendhq.cc/openapi.json) — SendHQ

## Continue learning

- [SMTP Mail Protocol: How Application Email Moves](https://sendhq.cc/guides/mail-protocol-smtp.md): Learn how SMTP submission, relay, envelopes, response codes, TLS, retries, and message content shape an application email workflow.
- [Email API Implementation Guide for Product Teams](https://sendhq.cc/guides/email-api.md): Design a safe email API integration with verified domains, queued sends, stable identifiers, controlled retries, delivery events, suppression, and tenant isolation.