Configurar Postmark: autenticación de dominio para email transaccional fiable
Cómo configurar Postmark con autenticación de dominio: DKIM, SPF, Return-Path personalizado y separación clara entre transaccional y broadcast.
Postmark es uno de los proveedores más estrictos en separación entre tráfico transaccional y broadcast: no acepta envíos masivos genéricos en sus servidores transaccionales. A cambio, ofrece tasas de inbox altas y latencias bajas. Para aprovecharlo, hay que configurar bien el dominio de envío con DKIM, SPF y Return-Path personalizado, y entender cómo Postmark separa los flujos. Esta guía cubre el alta del dominio, los registros DNS y los puntos donde el setup se rompe en producción.
El modelo de Postmark: transactional vs broadcast
Postmark divide el tráfico en dos servidores lógicos por cuenta:
- Transactional Stream: confirmaciones de cuenta, recibos, notificaciones, password reset, OTP. Postmark espera que cada destinatario haya solicitado o esté esperando ese mensaje.
- Broadcast Stream: campañas y mensajes enviados a una lista. Postmark exige consentimiento explícito y supresión de bajas.
Mezclar ambos en el stream incorrecto provoca avisos y, si se mantiene, suspensión. La separación se hace al crear el “server” en el panel y al elegir el stream para cada envío. La consecuencia práctica es que Postmark protege la reputación de su infraestructura siendo intolerante con remitentes que envían broadcast donde no toca.
Lo que hay que configurar en DNS
Postmark usa una arquitectura clásica con DKIM y Return-Path personalizado:
- DKIM: un TXT en
<selector>._domainkey.tudominio.comcon la pública. El selector lo elige Postmark al generar la firma. - Return-Path personalizado: un CNAME en
pm-bounces.tudominio.com(o el subdominio que elijas) que apunta apm.mtasv.neto equivalente. Eso reescribe el sobreMAIL FROMpara que el dominio del Return-Path sea tuyo y permita alineamiento SPF. - SPF: si vas a enviar también desde otros sistemas con tu dominio, asegúrate de que tu SPF principal incluye los origens correctos. Postmark, al usar Return-Path personalizado bajo tu subdominio, no requiere modificar tu SPF raíz si ese subdominio tiene su propio SPF gestionado vía CNAME.
Pasos en el panel
1. Añade el Sender Signature o el dominio
Postmark trabaja con dos figuras:
- Sender Signatures: direcciones individuales (
[email protected]). Útil para empezar rápido pero no escalable. - Sending Domains: configura todo el dominio. Esta es la forma seria.
Elige “Add Domain” e introduce tudominio.com (o el subdominio dedicado, p. ej. mail.tudominio.com o transactional.tudominio.com).
2. Publica el TXT de DKIM
Postmark te muestra un TXT como:
2026._domainkey.tudominio.com. IN TXT "k=rsa; p=MIIBIjANBgkq..."(El selector cambia, ronda fechas o hashes).
Publícalo en tu DNS exactamente como te lo indique el panel. Si tu panel cuenta caracteres y el TXT supera 255, sigue las pautas de migración DKIM 2048 sobre TXT troceado.
3. Configura Return-Path personalizado
Postmark pide un CNAME para el Return-Path:
pm-bounces.tudominio.com. IN CNAME pm.mtasv.net.Este CNAME hace que el sobre MAIL FROM de los envíos sea [email protected], que está bajo tu dominio y por tanto alinea SPF con tu From:.
Sin Return-Path personalizado, los mensajes salen con MAIL FROM: [email protected]. Esto también funciona técnicamente, pero rompe el alineamiento SPF estricto y solo funciona con DMARC aspf=r (relaxed).
4. Verifica el dominio en Postmark
Vuelve al panel y pulsa “Verify”. Postmark consulta tu DNS y confirma DKIM y Return-Path. Si falla, comprueba con dig:
dig +short TXT 2026._domainkey.tudominio.com
dig +short CNAME pm-bounces.tudominio.comLos TTL pueden hacer que tarde unos minutos.
5. Envía un mensaje de prueba
Desde el panel o vía API, envía un email a una cuenta tuya en Gmail:
curl "https://api.postmarkapp.com/email" \
-X POST \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "X-Postmark-Server-Token: TU_TOKEN" \
-d '{
"From": "[email protected]",
"To": "[email protected]",
"Subject": "Prueba Postmark",
"TextBody": "Hola desde Postmark"
}'Revisa “Mostrar original” en Gmail:
Authentication-Results:
spf=pass smtp.mailfrom=pm-bounces.tudominio.com
dkim=pass header.d=tudominio.com header.s=2026
dmarc=pass (p=...) header.from=tudominio.comLas tres líneas en pass con tudominio.com son la prueba final.
Alineamiento DMARC con Postmark
Con DKIM firmando con header.d=tudominio.com y Return-Path bajo pm-bounces.tudominio.com, DMARC aligna correctamente en modo relaxed (que es el default). Si necesitas modo estricto (adkim=s, aspf=s), revisa que el From: exacto use el mismo dominio que el header.d y que el subdominio del Return-Path coincida con el de envío.
Streams y separación operativa
Postmark expone “message streams” dentro de cada server. Cada uno tiene:
- Su propio DKIM efectivo (puedes diferenciarlo entre transactional y broadcast).
- Listas de supresión separadas.
- Logs y reportes independientes.
Para entornos multi-flujo, usa un server distinto para transactional vs broadcast. No los mezcles bajo el mismo server “porque es más cómodo”: Postmark detecta y avisa.
Webhooks y manejo de bounces
Postmark envía webhooks para cada evento (bounce, spam complaint, open, click). Configura al menos:
- Bounce webhook: para suprimir destinatarios con
Type: HardBouncey monitorizarType: SoftBouncerecurrentes. - Spam Complaint webhook: cualquier queja debe suprimir al destinatario inmediatamente.
Si no procesas los webhooks, Postmark mantiene la supresión interna pero tú no te enteras del estado real de tu lista. Más detalle en la guía de bounces SMTP.
Subdominio dedicado o dominio raíz
La práctica más limpia es enviar transaccional desde un subdominio dedicado (mail., notifications., app.):
- Aísla la reputación del transaccional del marketing y del correo humano.
- Permite políticas DMARC independientes con
sp=en el dominio raíz. - Si en el futuro cambias de proveedor, la migración solo afecta a ese subdominio.
Postmark soporta perfectamente subdominios. Para dominios completamente nuevos, conviene un breve warming aunque la IP la maneje Postmark, porque la reputación de dominio se construye con el envío.
Errores frecuentes
No configurar Return-Path personalizado
Sin él, el sobre lleva [email protected] y el alineamiento SPF estricto no funciona. La mayoría de receptores aplican aspf=r (relaxed) y aún así pasa, pero pierdes capacidad de subir a DMARC estricto.
Mezclar transactional y broadcast en el mismo stream
Postmark detecta patrones (volumen repentino a listas, ratios de bounce, contenido) y, si concluye que estás haciendo broadcast en transactional, suspende el server. La regla es estricta porque les protege la reputación a todos los demás.
Olvidar el SPF principal del dominio
Si tu dominio raíz no tiene SPF o tiene uno laxo, otros vectores de suplantación quedan abiertos. Postmark con Return-Path personalizado autentica el envío, pero el SPF raíz (v=spf1 ... ~all) sigue siendo necesario para todo lo demás. Revisa la guía de SPF.
Contenido demasiado genérico que parece marketing
Postmark monitoriza patrones. Un correo “transaccional” que en realidad es promocional disparará alertas. Si vas a hacer marketing, configura un server broadcast separado.
No procesar webhooks
Si Postmark suprime un destinatario por queja y tú sigues intentando enviarle, los intentos se silencian pero la lista sigue sucia. Sincroniza supresión con tu base de datos vía webhook.
Comprobaciones útiles
Estado de DKIM y Return-Path
dig +short TXT <selector>._domainkey.tudominio.com
dig +short CNAME pm-bounces.tudominio.comCabeceras del email recibido
Authentication-Results: ...
DKIM-Signature: v=1; a=rsa-sha256; d=tudominio.com; s=<selector>; ...
Return-Path: <[email protected]>Reportes DMARC
Revisa los reportes RUA tras unos días: deben mostrar pasadas DKIM/SPF para los envíos vía Postmark.
Recursos relacionados
Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.
¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de retención y email marketing de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.