Skip to content

Postmark

Postmark uses a single Server API token for both transports, and its webhooks report what happened after the handoff: confirmed deliveries, bounces, and spam complaints. Those events power the delivered state, webhooks like mail.delivered and mail.bounced, and automatic suppressions.

  • A Postmark server with your sender domain verified (DKIM and Return-Path). See Deliverability for what each record proves.
  • The server’s Server API token (the server’s API Tokens tab).
  1. Add the provider.

    In the console, open Providers → New provider, pick Postmark and paste the Server API token. Secrets are encrypted at rest. The one token gives the account both transports: mail that reaches Mailway’s SMTP relay goes on over Postmark’s SMTP server (smtp.postmarkapp.com, with the token as both login and password), and HTTP API and console mail go over Postmark’s API.

  2. Attach it to a project.

    Open the project, attach the provider, and position it in the failover order. Send something, and the provider health panel starts filling in.

Without delivery events, Postmark only reports that it accepted the mail. With them, Postmark tells Mailway what happened afterwards.

Postmark doesn’t sign its webhooks, so Mailway protects the URL two ways: Postmark logs in with a username and password Mailway generated for this provider, and Mailway checks that each request comes from Postmark’s published webhook addresses.

  1. Open delivery tracking. In the console, open the provider → Delivery tracking (beside Configure). Mailway creates the provider’s webhook URL and shows it with a username and password. Treat the password like any other secret. Regenerating (at the bottom of the dialog) rotates the credentials and revokes the old ones instantly, so update Postmark afterwards.

  2. Add the webhook in Postmark. On your server, open the Transactional message stream → Webhooks → Add webhook:

    • Webhook URL: paste the URL.
    • Open Custom headers and basic auth → Basic auth credentials: paste the username and password.
    • Events: tick Delivery, Bounce, and Spam Complaint. Open, Link Click, and Subscription Change can stay off, because Mailway ignores them.
    • Leave both Include message content boxes off. Mailway already keeps the message, so there’s no reason to send it again with every event.
Postmark event Mailway outcome
Delivery The mail turns delivered (confirmed by the provider’s event).
Bounce: hard bounce, bad address, manually deactivated The mail turns bounced; the address is auto-suppressed for the project.
Bounce: soft bounce, transient, DNS error, blocked Recorded as soft_bounced (temporary; a later delivery outranks it).
Bounce: auto-reply, subscribe / unsubscribe notices Ignored, because it isn’t a delivery outcome.
Spam complaint The mail turns complained; the address is auto-suppressed.
  • Connection check. The provider page’s connection check logs in over SMTP and makes one read-only API call, without sending anything.
  • Delivery events. Save the webhook and use Send test on Delivery in Postmark: the sample event is accepted, and the Delivery tracking dialog’s last step ticks when it arrives. After a real send, the mail’s timeline shows the delivered or bounced step with Postmark’s own details attached.

Mailway hands Postmark the message your app sent, byte-for-byte apart from the automatic exceptions, and archives it with the same exceptions made on receipt. Postmark then builds its own message from them: a new Message-ID and Date, a re-encoded body, and any DKIM signature your app applied is removed. Postmark signs with its own DKIM for your domain. Tested results: What providers change.

Your Postmark plan’s own sending limits apply. Mailway adds none for Postmark beyond your Mailway plan’s quotas.