# Postmark DKIM and custom Return-Path, and why DMARC fails without them

> Postmark needs two DNS records per domain. DKIM signs the mail. The pm-bounces Return-Path CNAME makes SPF align. Skip one and DMARC alignment rests on the other.

Mail from Postmark sends fine. Then Gmail starts filing it as spam, or a customer with a strict DMARC policy never gets it. The usual cause is DNS that is half done.

## The two records

Add your domain under **Sender Signatures -> Add Domain**. Postmark shows two records.

| Record | Type | Host | Value | Job |
|---|---|---|---|---|
| DKIM | TXT | `<selector>pm._domainkey.mail.example.com` | `k=rsa; p=...` | Signs every message with your domain |
| Return-Path | CNAME | `pm-bounces.mail.example.com` | `pm.mtasv.net` | Bounces go to your subdomain, so SPF aligns |

Copy the DKIM host and value exactly from the dashboard. The selector is unique to your account.

Some DNS providers append the zone to the host. If you type `pm-bounces.mail.example.com` into a zone for `example.com`, you may get `pm-bounces.mail.example.com.example.com`. Check with:

```bash
dig +short CNAME pm-bounces.mail.example.com
dig +short TXT <selector>pm._domainkey.mail.example.com
```

## Why the Return-Path matters

DMARC passes when **either** SPF or DKIM passes **and aligns** with the From domain.

- **DKIM** aligns once the TXT record exists: Postmark signs with `d=mail.example.com`.
- **SPF** checks the Return-Path (envelope sender), not the From. Without a custom Return-Path, it is Postmark's own domain. SPF passes, but for Postmark's domain, so it does not align.

With DKIM alone you pass DMARC. But one broken record (a rotated key, a DNS migration that drops a TXT) and every message fails at once. The Return-Path gives you a second, independent pass.

You do **not** need to add `include:spf.mtasv.net` to your root SPF record. SPF is evaluated on the Return-Path domain, and the CNAME already points there. Adding it anyway wastes one of your ten SPF lookups.

## DMARC on the root

Add a DMARC record on the organizational domain:

```
_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
```

Start at `p=none` and read the reports for a couple of weeks. Every sender that uses your domain shows up: your CRM, your helpdesk, an old newsletter tool. Move to `p=quarantine`, then `p=reject`, once all of them align.

Gmail and Yahoo require a DMARC record for bulk senders. Transactional-only senders are safer with one too.

## Use a subdomain

Send from `mail.example.com`, not `example.com`.

- Reputation is tracked per domain. A bad week on the subdomain does not touch the domain your team emails from.
- The DKIM and CNAME records live on the subdomain and never collide with your main mail provider.

## Checklist

- [ ] DKIM TXT verified in Postmark.
- [ ] Return-Path CNAME `pm-bounces` -> `pm.mtasv.net` verified.
- [ ] DMARC record on the root domain, starting at `p=none`.
- [ ] `EMAIL_FROM` uses the verified subdomain.
- [ ] A test message shows `dkim=pass`, `spf=pass` and `dmarc=pass` in Gmail's "Show original".

---

Agentic Boilerplate: A Next.js repo your agent already knows. $99 once. Lifetime access and updates.

- Site map for agents: https://agenticboilerplate.com/llms.txt
- Public API: https://agenticboilerplate.com/openapi.json
- Contact: agenticstudio@gmail.com