1 October 2026

Resend vs Postmark MCP for transactional email

Jess Wang·13 min

Transactional email delivers password resets, receipts, account alerts, and onboarding messages. At scale, teams rely on batches to send many personalized emails at once and templates to keep high-volume messages consistent. A pipeline failure can leave emails unsent or send an invoice or account detail to the wrong recipient.

AI agents and MCP servers can automate parts of that workflow. Transactional messages can contain password-reset links, invoice details, account information, and personal recipient data. This evaluation compares the Resend MCP and Postmark MCP across common tasks, direct acceptance timing, and record availability for follow-up lookup.

Methodology

1. Full task evaluation: Codex completes nine email-task types through each MCP and returns a structured response. This measures workflow correctness and surfaces behavior in the traces.

2. Direct benchmark: The task evaluation includes agent reasoning and tool-use time, so it cannot isolate MCP latency. The direct benchmark uses a non-agent client. It tests one 10-email batch at a time, then low- and high-concurrency bursts of two and five batches. Each measurement ends when the tool returns accepted IDs.

3. Feature comparison: Some features could not be included in a fair head-to-head task because only one MCP exposed them. The feature comparison makes the scope of the two tools clear.

Source experiments and traces are available in the Braintrust project.

The email workflow

The following terms clarify the email pipeline used throughout the evaluation.

Follow one email through the workflow

Codex receives an email task from the dataset and calls either the Resend MCP or Postmark MCP. The provider accepts the request and returns an email ID to Codex. Codex then calls the MCP again with that ID to retrieve the provider record. Finally, Codex returns structured JSON to the eval harness with the recipient, ID, and observed status.

Full task evaluation

Dataset

The dataset contains nine task buckets with five variants per bucket.

• Password reset: Basic direct send and lookup.
• Receipt: Tests whether a direct send preserves text, HTML, URL, visible link label, and tag.
• Service notice: Tests that a direct send includes both required text and HTML, a precise maintenance window, a tag, and no unintended recipients.
• Two-recipient welcome batch: Tests whether Ada and Lin's subjects, bodies, and URLs stay paired with the correct person in one batch call.
• Two-recipient receipt batch: Tests that Sam and Rin receive their distinct invoice numbers, amounts, subjects, and body content in one batch call.
• Content / serialization direct send: Tests whether Unicode, emoji, curly quotes, special characters, multiline text, and query-string links survive MCP serialization.
• Shuffled five-recipient batch: Tests whether the MCP keeps each distinct subject, body, and HTML link paired with its intended recipient, even when the requested order is shuffled.
• Shuffled ten-recipient batch: Tests the same mapping problem at 10 recipients.
• Lookup-retry direct send: Tests that a temporary not found response causes Codex to retry only the lookup and not create a duplicate send.

Scorers

The evaluation uses seven deterministic scorers to test different parts of this pipeline.

This diagram shows how each deterministic scorer verifies a specific behavior in the email workflow.

Results

Both MCPs passed every check

The task evaluation ran twice with the same dataset and configuration. The results below combine both runs.

These deterministic checks show that both MCPs completed the tasks correctly. They do not identify a clear winner between Resend and Postmark.

Resend returned usable records sooner

First-lookup success differed between the two providers. It measures whether the first MCP lookup after the provider accepted an email returned a usable provider record rather than a temporary not found response.

The difference in first-lookup success was 30.4 percentage points. Postmark often accepted the email before the agent could retrieve its record to verify content and status. This matters for two reasons. The agent must retry the lookup, which adds latency and cost. An agent that interprets the missing record as a failed send could incorrectly report failure or send a duplicate email.

Postmark required more lookup retries

For Postmark, the first lookup for 74/240 email units returned an unavailable result and needed a retry, which led to 98 extra Postmark lookup calls.

If we group email units by the number in each send-tool call, larger batches had fewer Postmark first-lookup misses, probably because they give records more time to become available before Codex looks them up. In one 10-recipient Postmark trace, the batch was accepted at 52.12s and the first lookup began 15.04s later, giving the provider record time to appear.

Checking the delay without the MCP

The next question was whether the delay came from the MCP wrapper or the provider. A direct REST control called each provider's API with no Codex agent or MCP server. It used one task from each of the nine task buckets.

The delay before the first readable provider record remained even after the MCP and agent were removed. This indicates that the observed delay comes from the Postmark provider rather than the Postmark MCP.

Estimated model cost

To calculate the estimated cost, we used the traces' token counts. The estimate uses the current GPT-5.6 Sol prices of $4 per million input tokens, $0.40 per million cached input tokens, and $20 per million output tokens (GPT-5.6 Sol pricing). It excludes Postmark and Resend plan charges.

Based on the rounded totals above, Postmark's estimated LLM cost was about $0.65 higher across the entire comparison, or about $0.007 more per task. This is probably because Postmark made 68 more model calls, consistent with extra lookup retries caused by the delay between email acceptance and provider-record availability.

Direct benchmark

The second part of this head-to-head comparison calls each MCP with no agent involved, which isolates MCP behavior.

The benchmark used three test conditions.

• Single batch: One 10-email batch call.
• Low concurrency: Two 10-email batch calls at the same time, for 20 email units total.
• High concurrency: Five 10-email batch calls at the same time, for 50 email units total.

The single-batch test is the baseline latency condition. It measures one batch-acceptance round trip without competing calls. The low- and high-concurrency tests measure burst behavior, testing whether the MCP and provider stay responsive when two or five clients submit batches at the same time.

Postmark accepted batches sooner

Postmark returned accepted IDs sooner after a direct batch request. Resend made those accepted email records available sooner when Codex immediately tried to look them up, which reduced retry work.

Feature comparison

Some features could not be evaluated head to head because only one MCP exposed them. The differences were substantial enough to document separately.

All direct latency benchmarks use 10-recipient batches because the Postmark MCP returned only 10 canonical IDs to the agent.

Conclusion

Both MCPs completed the shared GPT-5.6 task suite correctly. Postmark returned the initial acceptance response sooner, but its provider record was often not immediately readable, which led to more agent retries. Resend took slightly longer to return acceptance, but its record was almost always ready for the agent to inspect immediately. Postmark fits teams that send batches and use provider-hosted templates. Resend is a better fit for individual email workflows that need immediate record lookup, attachment support, or scheduling and cancellation.

You can build an eval like this one to check whether your agent sends the right content to the right recipients and verifies each email. Sign up for free to test your own workflow, or book a demo to walk through your setup.