Ir al contenido
DMARC
← Blog

Postmark: DKIM, Return-Path personalizado y alineación DMARC

Por Thomas · CISO virtual · 08 de septiembre de 2026

Postmark se ha labrado una reputación en un nicho preciso: el correo transaccional — confirmaciones de pedido, restablecimientos de contraseña, notificaciones aplicativas — con una exigencia de entregabilidad que es su sello. Esa orientación se traduce en una configuración de autenticación depurada, distinta de la de los grandes ESP generalistas: donde otros apilan tres o cuatro CNAME, Postmark se apoya en dos bloques bien diferenciados, la clave DKIM y el Return-Path personalizado.

Por defecto, un dominio añadido a Postmark emite bajo la identidad de la plataforma: sin la clave DKIM publicada y sin Return-Path personalizado, la firma no lleva el dominio mostrado y el sobre permanece en el dominio técnico de Postmark. Desde el punto de vista de DMARC, nada se alinea, y una política p=reject rechaza ese tráfico, por legítimo que sea. Ambos registros deben, pues, colocarse antes de cualquier subida de política.

Esta guía detalla la clave DKIM y su alineación directa, el Return-Path personalizado que busca la alineación SPF, la forma en que DMARC valida el conjunto, la distinción entre flujo transaccional y flujo de difusión — que atañe a la reputación, no a la autenticación — y luego los errores de configuración habituales y la contraprueba mediante los informes RUA.

DKIM: la clave a nombre del dominio

El primer bloque es la firma DKIM. Desde la consola de Postmark, al declarar un dominio, la plataforma genera un par de claves y muestra un registro TXT que publicar en la zona, bajo un selector que proporciona:

<selector>._domainkey.ejemplo.es.  TXT  "k=rsa; p=MIIBIjANBgkq…"

Una vez propagado el TXT, la verificación en la consola confirma que la clave se detecta: a partir de ahí, cada mensaje saliente lleva una firma d=ejemplo.es — el propio dominio organizativo. La alineación DKIM queda por tanto asegurada de entrada, incluso en modo estricto, sin subdominio técnico interpuesto.

Postmark también gestiona la rotación: renovar una clave consiste en generar un nuevo par en la consola, publicar el nuevo TXT y luego conmutar una vez confirmada la propagación. El principio de solapamiento — nuevo selector activo antes de retirar el antiguo — es el mismo que para toda renovación de las claves de firma: evita la ventana durante la cual los mensajes saldrían sin firma válida. La clave ofrecida es de 2048 bits, longitud robusta y esperada por los grandes proveedores; 1024, aún aceptada por herramientas antiguas, debe evitarse en toda nueva configuración.

Firma de remitente o dominio entero

Postmark distingue dos niveles de configuración, y confundirlos es una fuente de error frecuente. La firma de remitente verifica una dirección aislada — no-reply@ejemplo.es — mediante un simple correo de confirmación; autoriza el envío desde esa dirección, pero no coloca ni clave DKIM de dominio ni Return-Path. El dominio verificado, en cambio, publica la clave DKIM y el Return-Path en la zona, y cubre entonces todas las direcciones del dominio con un solo juego de registros.

Para DMARC, solo la configuración a nivel de dominio aporta la alineación a escala: una firma de remitente aislada deja el resto del correo del dominio sin firma alineada. Una cuenta que empezó con una firma de remitente — el camino más rápido para un primer envío de prueba — debe por tanto pasar al dominio verificado en cuanto varias direcciones emiten, so pena de ver fallar DMARC en todo lo que la firma aislada no cubre. Es una transición olvidada de muchas configuraciones quedadas en fase de prototipo.

El Return-Path personalizado: alinear SPF

El segundo bloque resuelve SPF. Por defecto, la dirección de sobre — el Return-Path, que es lo que SPF verifica realmente — está en el dominio técnico de Postmark (pm.mtasv.net). SPF sí autentica ese dominio, pero se alinea con Postmark, no con ejemplo.es: SPF pasa sin alinearse, lo que no cuenta para DMARC.

La respuesta es el Return-Path personalizado, colocado como un CNAME en la zona del dominio:

pm-bounces.ejemplo.es.  CNAME  pm.mtasv.net.

Este CNAME desplaza el sobre a pm-bounces.ejemplo.es, un subdominio del dominio organizativo. En modo relajado — el valor por defecto de DMARC — ese subdominio se alinea con ejemplo.es, y SPF se alinea a su vez. La resolución SPF sigue el CNAME hacia Postmark, que publica allí la autorización adecuada: no hay, pues, ningún include que añadir al SPF raíz del dominio, un punto que distingue a Postmark de las plataformas que exigen una modificación del registro SPF principal.

La alineación DMARC: la doble garantía

DMARC solo valida un mensaje si SPF o DKIM pasa y se alinea con el dominio del From. Con ambos bloques en su sitio, Postmark ofrece el caso favorable: DKIM se alinea por la firma d=ejemplo.es, SPF se alinea por el Return-Path personalizado. Dos mecanismos pasan alineados.

Esa redundancia tiene un valor concreto. Si una redirección cambia la IP emisora por el camino, SPF se rompe pero DKIM sobrevive; si una pasarela reescribe el cuerpo e invalida la firma, SPF resiste. Bajo DMARCbis, el dominio organizativo que sirve de referencia a la alineación se determina mediante el DNS Tree Walk en lugar de la antigua Public Suffix List, pero el razonamiento no cambia. Los ejemplos de registros DMARC comentados muestran cómo fijar la consigna _dmarc una vez DKIM y Return-Path en su sitio — primero en p=none, luego endureciendo.

A destacar: el Return-Path personalizado no es estrictamente obligatorio para que DMARC pase, puesto que DKIM basta por sí solo. Pero prescindir de él equivale a renunciar a la redundancia — y el día en que una firma cae, nada rescata el mensaje. En correo transaccional, donde cada mensaje cuenta (una confirmación, un enlace de restablecimiento), esa redundancia no es un lujo: la pérdida silenciosa de un mensaje así se traduce a menudo en un usuario bloqueado, un carrito abandonado o un ticket de soporte.

Flujo transaccional y flujo de difusión

Postmark separa los envíos en dos tipos de flujo: transaccional y difusión (broadcast). Esta distinción no toca la autenticación — DKIM y SPF se alinean de la misma forma en ambos casos — sino la reputación. El flujo transaccional, con alto riesgo de entregabilidad, se aísla del flujo de difusión, cuyo perfil (volúmenes, tasas de queja) difiere; mezclar ambos degradaría la reputación del correo crítico.

Para DMARC, la consecuencia es indirecta pero útil de conocer: en los informes agregados, ambos flujos aparecen bajo la misma fuente Postmark, alineados de forma idéntica. Una diferencia de alineación entre ellos señalaría una configuración incompleta en uno de los dos — un caso raro, pero que la lectura de los informes detecta. La separación de flujos es una cuestión de higiene de entregabilidad; la autenticación se resuelve una vez para el dominio.

En volúmenes elevados, Postmark ofrece IP dedicadas, reservadas a una cuenta. Como en todas partes, una IP dedicada nueva se calienta — se sube en volumen a lo largo de varios días — y ese calentamiento se lee en las tasas de entrega, nunca en la alineación, que sigue idéntica sea cual sea la IP emisora. Distinguir un bache de entregabilidad debido a una IP nueva de un verdadero defecto de autenticación es uno de los beneficios directos de los informes agregados: el primero no afecta a las columnas SPF y DKIM, el segundo sí.

Los errores de configuración habituales

Varias trampas reaparecen en el corpus de informes que el analizador DMARC gratuito procesa a diario.

Omitir el Return-Path personalizado. DKIM basta para hacer pasar DMARC, de modo que un CNAME ausente pasa desapercibido mucho tiempo — hasta el día en que una firma cae y SPF, no alineado, no rescata nada. Síntoma en los informes: DKIM alineado, SPF autenticado pero no alineado.

Publicar la clave DKIM sin verificarla. El TXT está en su sitio, pero la consola no ha confirmado la detección: mientras el dominio no esté marcado como verificado, la firma no está garantizada.

Reutilizar una configuración entre dominios. Cada dominio emisor tiene su propia clave DKIM y su propio Return-Path; copiar los registros de un dominio a otro produce firmas que no se alinean.

Endurecer la política demasiado pronto. Pasar a p=reject antes de confirmar con los informes que todo el tráfico legítimo se alinea equivale a arriesgarse al rechazo de los propios mensajes transaccionales — precisamente los que no se puede permitir perder.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es la consola de Postmark, sino lo que reportan los destinatarios. Una vez publicado un registro _dmarc con una dirección rua=, los informes agregados llegan en unos días y detallan, fuente por fuente, qué se alinea y qué falla. La lectura de los informes DMARC agregados confirma que el tráfico de Postmark se atribuye correctamente al dominio: DKIM alineado, y SPF alineado en cuanto el Return-Path personalizado se ha colocado.

Basta una cadencia sencilla: una primera lectura unos días después de publicar el registro _dmarc, una vez que varios destinatarios han reportado, luego un vistazo semanal mientras la política siga en p=none. El tráfico de Postmark se reconoce pronto por sus rangos de direcciones estables; toda fuente no alineada resalta de inmediato — un Return-Path olvidado, un dominio añadido sin su clave. Una vez confirmada la alineación durante varios días y sobre el conjunto de los flujos, el paso a p=reject se hace sin riesgo. El analizador en línea recompone este estado a partir de los registros publicados y de los informes recibidos, y sitúa el dominio en el camino que lleva a p=reject.

Guías relacionadas

Sobre el autor

Thomas — Thomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.