Is Postmark Down? How to Check Postmark Status Right Now

Postmark is the delivery layer for your most critical emails — password resets, payment receipts, onboarding sequences, account notifications. When Postmark is working, those emails land in inboxes within seconds. When Postmark goes down, your users are locked out, unsubscribed receipts disappear, and your support queue fills with "I never got the email" tickets. The impact is immediate and visible in ways that most SaaS outages are not.

Here's how to quickly determine whether Postmark is down, understand which failure mode you're dealing with, and protect your users from email gaps.

Is Postmark Down Right Now?

Check these sources in order:

1. Statusfield — Postmark status — real-time monitoring across Postmark's delivery API, SMTP relay, webhooks, and bounce processing.
2. Twitter/X — search Postmark down or Postmark email delayed sorted by Latest. Developers notice transactional email failures within minutes and post about them.
3. Downdetector — useful for confirming a user-reported spike, though it lacks component-level detail for email delivery.

What Actually Breaks During a Postmark Outage

Postmark is composed of several independent subsystems. A degradation in one does not automatically mean the others are affected.

Component	What it does	Impact when down
Delivery API	Accepts outbound email via REST; primary integration point	All programmatically sent emails fail; your application receives 422 or 5xx errors
SMTP relay	Accepts outbound email via SMTP for legacy or library-based senders	SMTP-connected apps stop delivering; connections time out or are refused
Inbound email processing	Routes inbound messages to your webhook	Inbound email handlers go silent; no messages are delivered to your endpoint
Webhooks	Delivers bounce, open, click, and delivery events	Event-driven logic (bounce handling, open tracking) stops firing
Bounce processing	Classifies bounces and suppresses invalid addresses	Hard bounces aren't removed from your list; your sender reputation accumulates risk
Message streams	Routes transactional vs. broadcast traffic to separate IPs	Stream-level routing fails; deliverability on shared IPs may degrade
Dashboard / API console	Web UI for message logs, stats, and account management	No visibility into in-flight messages or delivery history

Common Postmark Error Symptoms

What you see	What it usually means
422 Unprocessable Entity from the API	Request-level validation failure (usually your data, not Postmark)
500 Internal Server Error from the API	Postmark's API layer is degraded
API request times out after 10–30s	Postmark API is under heavy load or partially unreachable
SMTP connection refused or timed out	SMTP relay is down or congested
Emails accepted by API but never delivered	Delivery queue is degraded; messages are accepted but not sent
Webhooks not firing for confirmed deliveries	Webhook dispatch is degraded; events are queued or dropped
Bounce rate anomaly (sudden spike or flat zero)	Bounce processing is degraded
Dashboard shows no recent activity	Stats pipeline is lagging; messages may still be delivering normally

Key distinction: A successful 200 OK from the API means Postmark accepted the message, not that it was delivered. If your API responses are normal but users aren't receiving emails, the issue is in Postmark's outbound delivery queue or DNS/IP reputation — not the API layer.

How Postmark's Architecture Affects Outage Scope

The API acceptance layer is separate from the delivery queue. Postmark accepts messages synchronously via the API and then queues them for outbound delivery asynchronously. This means you can receive clean 200 responses during a delivery queue degradation — your messages are accepted, but delivery is delayed or failing silently. Monitor delivery rates, not just API response codes.

Message streams use dedicated IP pools. Postmark separates transactional and broadcast traffic onto different IP addresses. A reputation event affecting broadcast IPs doesn't contaminate transactional IPs, and a delivery degradation on one stream is isolated from the other. If only one category of email is failing, check whether the issue is stream-specific.

SMTP and API share delivery infrastructure but have independent ingestion layers. An SMTP relay outage can occur independently of the API, and vice versa. If you use both pathways (e.g., a library that uses SMTP alongside a custom API integration), confirm which pathway is affected before debugging.

Webhooks run on separate workers. Postmark's webhook dispatch is asynchronous and runs independently of email delivery. During partial outages, delivery may continue while webhook events are delayed or dropped. If your bounce handling, suppression logic, or engagement tracking depends on webhooks, treat webhook degradation as a separate failure mode from delivery failure.

Is It Postmark or Your Configuration?

Before escalating to an infrastructure outage, rule out common configuration issues:

Your API key is expired or revoked. Postmark Server API keys can be regenerated after a security review or accidental exposure. A 401 Unauthorized or 403 Forbidden response means the issue is your credentials, not Postmark's infrastructure.

Your From address isn't verified. Postmark requires a verified sender signature (domain or From address). If you recently changed your From address or domain without re-verifying, sends will fail at the API layer with a 422 containing the specific error.

Your message stream doesn't match your usage. Sending promotional emails through a transactional stream (or vice versa) violates Postmark's terms and can result in rejected sends. Check that the stream specified in your API call matches the message type.

Your SPF/DKIM records are misconfigured. If you recently changed DNS providers or updated your domain records, your Postmark-required SPF and DKIM entries may have been removed or broken. Postmark accepts the message but receiving mail servers reject it — the failure shows up as a soft bounce, not an API error.

Your webhook endpoint is returning non-2xx responses. Postmark retries webhook deliveries, but if your endpoint consistently returns errors, Postmark may disable the webhook. If events have stopped arriving, check your endpoint's response logs first.

When these are ruled out and failures persist, the evidence points to a Postmark infrastructure issue. Confirm at Statusfield.

Hardening Your Transactional Email Against Postmark Outages

Transactional email is load-bearing infrastructure. These steps reduce user impact when Postmark degrades.

1. Build a graceful degradation path for critical emails

For password reset and magic link flows, add logic to detect a Postmark API failure and surface an alternative path to the user — an in-app notification, a "try again in 5 minutes" message, or a secondary provider fallback. A blank screen with no indication of failure is the worst outcome.

2. Log every API response, not just errors

Store Postmark's MessageID alongside every sent email in your database. When users report missing emails, you can check whether the send was accepted, delivered, or bounced without waiting for Postmark support. This also lets you distinguish Postmark acceptance from actual delivery during a queue degradation.

3. Implement webhook fallback for bounce handling

If your suppression list depends entirely on Postmark webhooks, a webhook outage means bounces aren't being removed from your list. Add a daily reconciliation job that polls the Postmark API for recent bounces and applies suppressions — this catches anything the webhook missed.

4. Set send-timeout alerts in your application

Configure your HTTP client with a timeout (5–10s for Postmark API calls) and route timed-out requests to an error queue that you alert on. Silent timeouts that are dropped without logging are invisible — you won't know Postmark is struggling until your SLA breach queue fills.

5. Monitor Postmark like a critical infrastructure dependency

Transactional email failures translate directly to locked-out users and lost revenue. Statusfield monitors Postmark's API, SMTP relay, and webhook delivery continuously, alerting you the moment status changes — through Slack, Discord, email, or webhook.

How to Stay Ahead of Postmark Outages

The goal is to know Postmark is degraded before your users do — before the "I didn't get my reset email" tickets arrive.

Statusfield monitors Postmark continuously and delivers alerts the moment a degradation is detected. On the free plan you get 3 monitors and 10 alerts/month, no credit card required.

→ Monitor Postmark on Statusfield — free, no credit card required

FAQ

Why are Postmark emails not being delivered even though the API returns 200?

A 200 OK from the API means Postmark accepted the message, not that it was delivered. Postmark queues messages asynchronously for outbound delivery after accepting them. If the API is healthy but delivery is failing, the issue is in Postmark's outbound delivery queue, not the ingestion layer. Check Statusfield to see if a delivery degradation is reported, and check your Postmark dashboard for delivery stats on the affected messages.

Is Postmark down for everyone or just my account?

Check Statusfield first. If Statusfield shows Postmark as operational, the issue is likely scoped to your account — sender signature verification, API key validity, or a stream configuration problem. If Statusfield shows a degradation, confirm whether the affected component (API, SMTP, webhooks) matches what you're experiencing.

Postmark webhooks stopped firing. Is Postmark down?

Not necessarily — webhook dispatch is a separate subsystem from email delivery. Check Statusfield to see if a webhook degradation is specifically reported. If Statusfield shows Postmark operational, check whether your webhook endpoint is returning 2xx responses to Postmark's delivery attempts. Postmark disables webhooks that consistently return errors. Check your Postmark account's webhook settings for any disabled hooks.

How do I check if a specific email was delivered via Postmark?

Use the Postmark API's message detail endpoint with the MessageID returned when you sent the email: GET /messages/outbound/{messageid}/details. This returns the delivery status, including whether it was accepted, delivered, bounced, or is still in queue. Store MessageID in your database for every send so you can look this up without needing Postmark's dashboard.

How long do Postmark outages typically last?

Most Postmark degradations are partial — affecting one component (e.g., webhook dispatch or a specific message stream) while others remain operational. These typically resolve within 15–60 minutes. Full delivery outages are rare and usually resolve within 1–2 hours. Messages queued during a delivery degradation are typically delivered once the queue clears, though delivery order is not guaranteed. Monitor Statusfield for live updates during an incident.