What should a product team evaluate when choosing a free SMTP service?

Define free from the live contract

The word free can describe an ongoing allowance, a time-limited trial, introductory credits, verified-recipient testing, or a paid plan with temporary credits. Read the current provider pricing and terms on the day of evaluation. Record currency, region, tax, payment-card requirement, trial expiry, included units, overage behavior, suspension behavior, and which features disappear at downgrade. Do not rely on search snippets, old comparison posts, screenshots, or a sales chat without a durable contract reference. AWS SES, Resend, and Mailgun publish different current pricing models and included capabilities on their official pages; none should be assumed interchangeable. Bind the reviewed page URL and capture date to the decision, and set a recheck before launch because provider offers can change. Free acquisition cost does not remove engineering, DNS, monitoring, privacy, incident, or migration cost.

Model the workload in billable and operational units

Estimate messages, recipients, attachments, bytes, API or SMTP requests, event deliveries, inbound mail, stored content, log retention, domains, team members, and environments. A message with several recipients can consume quota differently from a single-recipient transaction. Retries, test traffic, warm-up, bounces, and webhook replays can add volume. Calculate average, peak minute, peak hour, daily, monthly, and seasonal demand, plus growth and incident headroom. Keep application rate controls below provider caps and protect tenants from one another. Ask what happens at zero remaining units: hard rejection, deferral, automatic billing, degraded features, or silent log loss. A free tier that covers send calls but excludes usable event history, support, or suppression export may be more expensive operationally than a small paid plan. Validate the account's observed counters with controlled traffic before production.

Require secure SMTP submission

A production SMTP service should document protected submission, supported ports, TLS behavior, authentication mechanisms, certificate expectations, credential scope, and rotation. Prefer mandatory TLS and fail closed on missing STARTTLS, certificate failure, hostname mismatch, or unsupported protocol. Store credentials in a managed secret system, never in browser code, mobile apps, source, images, logs, URLs, analytics, tickets, or prompts. Separate production, test, tenant, and administrative authority. Confirm whether the free tier restricts credentials, source IPs, domains, regions, or concurrent connections. RFC 8314 recommends cleartext protocols be deprecated in favor of TLS for submission and access, while RFC 4954 defines SMTP authentication as a protocol extension rather than product authorization. The application must still authorize the business event, sender, tenant, recipient, template, and message class before opening the SMTP connection.

Verify sender identity and DNS ownership

Require an organizationally owned From domain and a documented domain-verification process. Inventory the SMTP MAIL FROM or return path, visible From, DKIM d= domain and selector, sending IPs, and reply handling. Publish one valid SPF policy that includes the actual path, configure DKIM signing with protected keys, and evaluate DMARC alignment with the visible From domain. Provider verification is evidence that one setup check passed; it does not prove recipient consent, correct production routing, reputation, or inbox placement. Understand which DNS records the provider owns and which remain in the organization's authoritative zone. Preserve prior values and rollback steps. Avoid a provider-only From domain for production identity because it weakens portability and can make DMARC alignment or brand continuity dependent on the vendor. Test raw received messages through every stream and environment.

Demand useful recipient-level outcomes

The service must distinguish SMTP or API acceptance, per-recipient refusal, temporary deferral, permanent failure, later bounce, complaint, unsubscribe, and provider suppression. Verify how those outcomes are delivered, authenticated, retried, ordered, retained, and exported on the free tier. Authenticate webhooks before parsing, enforce freshness and replay controls, durably capture events before acknowledgement, and correlate them to application-owned attempts. Store accepted and refused recipient scopes separately. Retry eligible temporary failures with bounded backoff, jitter, attempt caps, and queue-age limits. Stop automatic sends after permanent address failure, complaint, or unsubscribe for the applicable scope. A dashboard without exportable evidence creates operational lock-in. A provider delivered event often describes destination-server acceptance, not final mailbox folder. Opens and clicks are engagement instrumentation and can be distorted by privacy technology.

Inspect limits that appear outside pricing

Pricing pages rarely contain the entire operational contract. Review current documentation for recipient count, message size, attachment size, connection rate, concurrent sessions, API rate, DNS domains, templates, webhook attempts, event retention, suppression capacity, and trial recipient restrictions. Determine whether support, audit logs, dedicated IPs, regional processing, inbound routes, or compliance features require paid plans. Test the actual account because new or trial accounts can have lower limits or manual review. Record every limit with a source URL and observation date. Do not design exactly at the maximum; leave headroom for provider changes, retries, and incident recovery. If an application can silently exceed a limit through user-supplied recipient arrays or attachments, enforce a stricter product bound first. Treat undocumented or unclear limits as risk, not unlimited capacity.

Evaluate privacy, security, and abuse controls

Map message content, recipient data, headers, event payloads, IP addresses, logs, support access, backups, and subprocessors across regions. Minimize custom metadata and avoid secrets or unnecessary personal data in tags and headers. Confirm retention and deletion behavior for free accounts, including after cancellation. Verify tenant isolation, role-based access, MFA, audit history, credential rotation, webhook signing, suppression authorization, and incident notification. Test header injection, arbitrary sender selection, excessive recipients, attachment abuse, cross-tenant event lookup, and replay. Free tiers are common targets for abuse, so providers may impose automated reviews or rapid suspension; the product needs a durable queue and a safe pause path. Never evade abuse controls by rotating accounts, domains, credentials, or IPs. Preserve consent and suppression state outside the provider so a suspension or migration cannot discard recipient protections.

Calculate exit cost before sending

Put provider-specific fields behind one adapter and keep the application event model independent. Inventory SMTP host and authentication, API payloads, templates, sender domains, return paths, DKIM selectors, webhooks, event names, message identifiers, tags, suppressions, inbound routes, and logs. Require exports for suppression and operational history in formats the product can validate. A migration must preserve business event keys, attempt history, consent, recipient safety, and sender ownership. Test a second transport with controlled identities but do not configure it as an automatic bypass for permanent recipient or policy failures. Estimate DNS change windows, credential rotation, template conversion, webhook dual-processing, duplicate prevention, and old-event retention. The cheapest free tier can be the wrong choice when its exit requires losing evidence, changing sender identity, or rebuilding safety controls under incident pressure.

Run a scored proof before production

Create a representative test matrix: TLS negotiation and certificate failure, authentication and rotation, verified and unauthorized senders, plain and multipart content, Unicode, attachments, partial recipients, transient and permanent replies, timeout after DATA, bounces, complaints, unsubscribes, webhook replay, out-of-order events, quota exhaustion, plan expiry, export, and account closure. Use dedicated controlled recipients and never real customer lists. Score security, correctness, evidence, capacity, privacy, support, portability, and total cost separately. Block launch on missing TLS verification, shared secrets without rotation, cross-tenant exposure, absent permanent-failure handling, unavailable suppression export, silent overage, or unclear retention. Re-run the proof when a pricing plan, sending path, domain, or provider contract changes. A free plan can be appropriate for a bounded low-risk workload only when the controls and exit plan meet the same standard expected from a paid dependency.

Evaluate SendHQ's current plans

SendHQ has no free plan. New workspaces get a controlled integration trial of 100 deliveries to the account email or an AWS SES simulator address. For current paid-plan prices, allowances, and capabilities, see SendHQ's pricing page.

Frequently asked questions

Sources

• Amazon Simple Email Service pricing — Amazon Web Services
• Resend pricing — Resend
• Mailgun pricing — Mailgun
• RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access — RFC Editor
• RFC 4954: SMTP Service Extension for Authentication — RFC Editor
• RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor