An SMTP relay is a server that accepts outbound email from your application and forwards it to the recipient's mailbox provider. The relay is responsible for the SMTP conversation, the authentication records, and the IP reputation.
A transactional email API can add structured requests, idempotency keys, typed responses, delivery-event webhooks, and audit trails around the delivery pipeline. The choice between SMTP submission and an API is often about client compatibility and how much retry and tracking logic the caller needs. Compare the SMTP relay guide with the transactional email guide for the two application interfaces.
Free public SMTP relays (Gmail, Outlook, Yahoo's outbound SMTP) are not designed for transactional volume. Their rate limits are per-account, not per-IP, and they can change without notice. Because many senders share their IP pools, you cannot independently control the pool's reputation, and poor sending activity by others can affect your transactional deliverability.
PulsePigeon's SMTP submission listener is a compatibility lane for legacy clients. It is code-complete but not live until an operator provisions TLS, public ingress, DNS, and an external STARTTLS probe. It is disabled and loopback-bound by default.
SMTP submission deliberately has no idempotency-key extension and does not replace the signed status-webhook surface. Use the REST API when you need retry-safe acceptance; use SMTP only after the operator-gated rollout is active for your tenant.