You send the email through Postmark, the API returns 201, and the message shows as "delivered" in your Postmark stats. But the recipient never sees it. It is in spam, or it is not there at all. Postmark is one of the cleanest senders around, so when deliverability drops, the cause is almost always on your side: the sending domain, the authentication records, the server you are sending from, or the list you are sending to. Here are the five reasons Postmark deliverability drops, in order of likelihood, and the exact fix for each one.
This is the number one cause. When you send through Postmark, the mail leaves from a Postmark IP, not your own server. The receiving mail server checks your SPF record to see if that IP is allowed to send as your domain. If your SPF record does not include srv.postmark.com, the receiving server sees an unauthorized sender and flags the mail.
The fix: add include:srv.postmark.com to your SPF record. If you are also sending from your own server, add both: v=spf1 include:srv.postmark.com ip4:YOUR_SERVER_IP -all. Then verify the record is actually live: run the SPF checker on your domain and confirm the include resolves.
DKIM is the second layer. Postmark signs your mail with a DKIM key, and the receiving server verifies that signature against the DNS record for your domain. If the DKIM record is missing, expired, or the selector does not match, the signature fails and the mail is flagged.
The fix: go to Postmark's settings, copy the DKIM host record and value, and add it to your DNS. Then verify it: run the DKIM checker on your domain and confirm the signature verifies. If you recently changed your DKIM key in Postmark, the old selector may still be in your DNS and the new one may not be. Check both.
DMARC is the policy layer. It tells the receiving server what to do when SPF or DKIM fails. If you do not have a DMARC record, the receiving server has no policy to follow and may treat the mail as suspicious. If your DMARC record is misconfigured (wrong selector, wrong policy, missing reporting address), it can cause the same problem.
The fix: add a DMARC record that references your SPF and DKIM selectors. Start with p=none and a reporting address, then tighten it to p=quarantine or p=reject as your domain proves itself. Run the DMARC checker on your domain and confirm the record is live and correctly configured.
Postmark sends from dedicated IPs, which is good. But the reputation of the sending domain matters too. If you are sending from a brand new domain, or a domain that has a history of spam, the receiving server will be more skeptical of your mail even if the authentication is perfect.
The fix: check your sending domain's reputation. Run the domain blocklist checker on your sending domain. If it is listed, request delisting from the blocklist operator. If you are sending from a new domain, warm it up gradually before you scale your volume.
The last two causes are on your side, not Postmark's. A list full of hard bounces and cold recipients poisons your reputation. A sudden 10x spike in send volume trips spam filters. Both of these show up as a sudden drop in deliverability with no obvious cause in your infrastructure.
The fix: prune your list. Remove hard bounces, honor unsubscribes the same day, and keep your complaint rate under 0.1%. Ramp your volume in steps over days instead of all at once. If you are sending cold email, warm up the domain before you scale.
Do not guess. Run the checks in order. Start with the authentication layer (SPF, DKIM, DMARC), because it is the most common and the cheapest to verify. Then check the domain reputation. Then look at the list and the volume. The free audit runs the DNS and reputation checks in one pass, scores the domain, and points at the exact record to fix first. That is the fastest way to stop guessing and start fixing.
Want this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →