Skip to content
Engineering

Move a Stampwing integration from Test to Live

Know exactly which prerequisites remain before enabling a real application send.

THE SHORT ANSWER

Test does not require DNS. Live requires a ready deployment, an active account, a verified sending domain, a Live credential, and available allowance. Accounts are approved automatically at signup; there is no routine manual use-case review.

Before you start #

For
Developers with a working Test integration and access to a live-capable Stampwing installation.
Bring
Control of the sending domain’s DNS, a server-side secret store, an authorized recipient for any later live check, and access to project readiness.
Scope
The public resource site does not enable Live sending. These steps describe the application workflow when a deployment provides it. Do not run live sends as automated tests.

1. Confirm who operates the service #

If you use an operator-managed installation, your job is to configure the project, domain, and application credential. You do not install PostgreSQL or put AWS secrets into your application. The Stampwing operator manages those services.

If you operate Stampwing itself, a local demo is not a production checklist. Read docs/deployment.md, docs/operations/infrastructure-setup-guide.md, and docs/operations/launch-operations.md in the source repository. Live mode fails closed without required authentication, encryption, database, and SES configuration. Role-specific services also require their own screening, event, billing, and operational configuration.

2. Add the exact sending domain #

  1. Open Domains in the intended project and add the domain you will use in the From address, such as mail.yourdomain.com.
  2. Choose a dedicated sending subdomain if you want to keep its setup separate from employee mail. Confirm who manages that DNS zone.
  3. Copy the exact record names, types, and values shown by Stampwing. The records are specific to the deployment and region; do not copy tokens from a tutorial.
  4. If Domain Connect is offered, review the proposed records and approve the provider’s DNS changes. If it is unavailable, enter the records manually at your DNS provider.

3. Verify DNS and authentication #

DNS providers differ in how they handle the zone suffix. A host such as selector._domainkey may already have yourdomain.com appended by the provider. Compare the final fully qualified name against Stampwing’s expected record. Keep email CNAME records DNS-only where your DNS provider offers web proxying.

Stampwing checks ownership and authentication automatically and shows the observed status. If the interface offers Check again, use it after saving records, then allow for DNS caches. Read the reported mismatch rather than repeatedly adding new records. A generic public DNS checker can help diagnose records, but it does not replace Stampwing’s stored verification or SES readiness.

  • Do not create a second SPF record at the same DNS name. Merge approved mechanisms into the existing policy where needed.
  • Use the supplied DKIM records and check the selected sending region.
  • Keep DMARC policy changes separate from proof of a successful send; authentication does not guarantee inbox placement.

Understand SPF, DKIM, and DMARC →

4. Wait for actual readiness #

Normal account access is approved automatically at signup, and provider accounts are provisioned automatically. If provider setup is pending, read the setup status or diagnosis and let the operator investigate a persistent failure. Do not ask customers to submit a use-case review to unlock normal sending.

A verified domain does not bypass suspensions, suppressions, content screening, rate limits, or billing allowances. A paused workspace needs the reason and next step shown in the application. The readiness view is advisory; the API and dispatcher enforce the current rules when work is queued and submitted.

5. Configure a separate Live credential #

  1. Create a Live key for this project with email:send, adding email:read only if the application reads delivery status. Add templates:use if you send published templates.
  2. Put the Live key into your production server’s secret store. Keep the Test key in development and staging. Do not change staging to Live just to make an example run.
  3. Use a From address on the exact verified domain and a published template version in the matching project/environment, if applicable.
  4. Deploy the configuration through your normal release process. The guarded tutorial sender intentionally refuses a Live key; use your reviewed business integration for live traffic.

6. Understand allowance and rate limits #

A payment method or paid plan does not promise immediate delivery or remove abuse controls. Review workspace usage before a large job and keep jobs within the useful lifetime of their content.

ControlMeaning
Free daily allowance100 outbound recipients per UTC calendar day, shared across projects, resetting at midnight UTC.
Paid daily allowanceNo platform daily sending cap. Optional customer-set project caps may still apply.
Monthly and spending limitsMonthly plan allowances and enabled spending caps are enforced. A different key or project does not reset a workspace allowance.
Request and sending ratesAPI request rate and provider sending rate are separate controls on every plan. Use the returned code and retry timing.
Recipient countingAn email addressed to three recipients consumes three outbound recipient units.

7. Check the first authorized live send #

  1. When a human authorizes the real send, submit one controlled business message with a saved operation key and retain its returned UUID.
  2. Confirm the response says mode: live. HTTP 202 means it was queued; do not report it as delivered.
  3. Inspect Messages and signed delivery events. submitted means submission has started or the provider has accepted it; accepted means the receiving server accepted it.
  4. Check the controlled mailbox separately if you need inbox evidence. An accepted event does not prove inbox placement or reading.
  5. If the outcome is uncertain, investigate the existing UUID and provider evidence. Do not automatically generate another send.

Diagnose delayed or missing email →

Sources and further reading

Written for Stampwing with AI assistance and checked against the linked documentation. Examples are educational; simulated results are labelled. How these resources are maintained.