Use a Postmark Server API token to connect an authenticated sender. MailSlurp reuses that connection for warmup and recurring placement checks while Postmark remains the sending service.

<span id="before-you-connect"></span>

## Prepare the sender in Postmark

1. Complete [Postmark's account review](https://postmarkapp.com/support/article/1084-how-does-the-account-approval-process-work) and confirm the account is permitted to send the intended messages to external recipients.
2. Add and verify a sending domain or sender signature. For a domain, publish the issued DKIM record and configure the custom Return-Path when using it.
3. Choose a live Postmark server for these messages. A sandbox server does not deliver external mail.
4. Copy the **Server API token** from that server's **API Tokens** tab. Use a dedicated server when you want to keep this activity separate.

Use an account approved for your intended sending, and include production traffic when checking provider limits. See [Postmark token types and test-token behavior](https://postmarkapp.com/developer/api/overview) for provider setup details.

<span id="connect-in-mailslurp"></span>

## Connect and verify in MailSlurp

Open **Email warmup > Create warmup** or **Inbox placement > Automations > Create automation**. Select **Postmark** in the sender step, or reuse the existing verified connection for that sender.

Enter a recognizable connection name, sender name and authorized From address, followed by these values:

<span id="connection-values"></span>

| Field | Value |
| --- | --- |
| Connection type | Postmark API key |
| Credential | Server API token, rather than the account-wide token |
| From address | A verified sender signature or address on a verified domain |

MailSlurp's native Postmark connection sends through the server's `outbound` transactional stream.

Choose **Verify and continue** and complete the delivery test before proceeding. Check credential verification and the received test separately: an authenticated connection does not by itself prove message delivery. Reuse this connection for both features instead of creating another copy of the same sender.

## Schedule automated inbox placement

1. Open [Inbox placement automations](https://app.mailslurp.com/inbox-placement/automations/) and select **Create automation**.
2. Select the verified Postmark connection.
3. Set the schedule name, **Frequency** and **Inbox audience**. Account allowance and provider limits must cover every seed recipient in each run.
4. Enter the subject and text body, retaining `{{trackingToken}}` in at least one of them. MailSlurp substitutes a fresh marker for each test.
5. Select **Create automation**, then inspect the saved schedule and next run.
6. Use **Run now** for an immediate check if needed. Inspect a later scheduled execution separately to confirm the recurrence is working.

Open the linked report and wait for all targets to settle. Compare inbox, provider tabs, spam and not-received results with the same messages in Postmark's activity. A provider delivery event does not prove inbox placement. Pausing the schedule stops future scheduled tests while preserving its history.

The scheduled subject and text body are the message being tested. To check a finished campaign with different HTML, links or routing, use the [manual placement workflow](/docs/inbox-placement/) through the original sending path.

## Start and monitor warmup

Open **Email warmup > Create warmup** and choose the same connection. Set the sender goal, ramp preset or custom daily volumes, time zone and sending window. Select managed content or an allowed custom subject and plain-text body. Review the resolved coverage and estimated usage before starting.

Controlled coverage measures paced delivery to managed inboxes. Core coverage adds provider placement checkpoints when your plan and the available coverage permit them. Review accepted sends, observed controlled receipts and completed checkpoint folders separately; a progress percentage alone does not establish successful delivery.

Choose maintenance when you want ongoing activity after the ramp. For a finite program, disable maintenance and follow the remaining ramp and any final checkpoint through its terminal state. Pause while investigating a persistent send failure, then resume the existing program after correcting it. A short successful run does not establish a lasting reputation improvement.

<span id="troubleshooting"></span>

## Review capacity, usage and errors

Warmup and placement automation share a Delivery Sender allocation. Creating or verifying a connection does not consume an enabled sender seat; starting a workflow can enable it. Pausing retains the allocation. After stopping warmup and pausing all automations that use it, disable the sender in **Settings > Sending connections** if you want to release that capacity.

Read the account's included allowance and credit weights before sending. Warmup uses weighted message credits; standalone and automated placement use placement-test allowance. Warmup placement checkpoints use warmup credits rather than consuming another standalone placement test. Provider recipient limits still apply to every message.

Check account approval, server mode and the stream before retrying an accepted-but-undelivered request. The special POSTMARK_API_TEST token validates requests without delivering messages, so use a real server token for receipt tests. A server token has server-level access, not a sending-only scope. Include every seed recipient and warmup message when reviewing the account quota.

See [warmup configuration and results](/docs/email-warmup/) for pacing and program controls, and [placement automation and reports](/docs/inbox-placement-automation/) for API workflows and exports.