PulsePigeonemail infrastructure

SMTP relay

Authenticated SMTP submission, built for controlled rollout.

PulsePigeon has implemented an authenticated STARTTLS submission listener for legacy applications that cannot call the REST API. It is a beta capability that is not deployed or publicly reachable. Use POST /v1/messages for production integration today.

Create a free accountUse the REST API

Current status

Code-complete does not mean publicly available.

The listener, credential lifecycle, tenant rollout states, MIME normalization, and send policy bridge are implemented. Production activation still requires a real TLS certificate, public DNS, explicit network ingress, listener deployment, tenant approval, and an external STARTTLS smoke test.

The disabled defaults are deliberate: the listener kill switch is off, the publish address is loopback-only, and missing or mismatched TLS material prevents startup. No hostname or availability date should be inferred until those gates are completed.

Protocol contract

What the controlled listener supports.

  • RFC 6409 submission on port 587, with mandatory STARTTLS.
  • AUTH PLAIN or AUTH LOGIN using a separately issued SMTP credential.
  • A default 25,000,000-byte message limit and 50-recipient limit, both operator-configurable.
  • Attachments parsed from MIME parts and passed through the same provider size checks as REST sends.
  • Immediate credential revocation and operator-controlled tenant rollout states.

SMTP credentials are separate from pp_live_ and pp_test_ API keys. Each credential is scoped to one project and tenant, and its secret is returned once. The listener never operates as an open relay.

Shared safety gates

One acceptance policy, two possible protocols.

After an SMTP message is normalized, it enters the same acceptance function used by the REST API. Billing, vetting, domain verification, suppression, compliance, consent, rate limits, sending limits, and content checks still apply.

The message's visible From: header is checked against verified domains. The envelope MAIL FROM value does not choose a tenant, route, or reputation lane. SMTP submissions use the operator-configured default message category, which defaults to transactional.

Differences from REST

Compatibility has a narrower contract.

  • SMTP has no equivalent to the REST Idempotency-Key header.
  • One DATA command accepts one MIME submission. Visible To and Cc recipients share one message record, while every Bcc-only recipient gets a separate message id to preserve address privacy.
  • SMTP reply codes map policy and validation failures into standard 4xx or 5xx SMTP families.
  • Delivery tracking still uses tenant-scoped message logs, events, and separately configured signed status webhooks.

If retry-safe acceptance matters, use the REST API. A client that retries SMTP after losing the final server reply can create a second send because SMTP submission has no idempotency key. A Bcc fanout can also accept earlier recipient records before a later record fails, so retrying the failed DATA command can duplicate delivery to recipients already accepted.

For HTTP integration, follow the REST documentation below. If your application requires SMTP, confirm current availability and access with the operator before configuring it. API acceptance does not prove delivery to an inbox or that a person read the message.

Activation path

How the beta can become reachable.

  1. Provision and mount a hostname-matched TLS certificate and private key.
  2. Publish the hostname and configure an explicit public bind address and direct TCP ingress.
  3. Deploy the listener and pass an external STARTTLS and certificate probe.
  4. Move the rollout from off to pilot, approve a tenant, and issue a project-scoped credential.
  5. Run a bounded tenant canary before any wider rollout.

Until this sequence is complete, the REST API remains the only supported production send path.

Read next