Elija la ruta y las identidades Postmark
Esta guía cubre los mensajes salientes realmente enviados a Postmark , no un sitio web que simplemente utiliza Postmark para el procesamiento entrante. Registre la aplicación, el servidor Postmark y el flujo de mensajes, el dominio de destino y el administrador DNS . Un recibo enviado por una aplicación diferente debe probarse por separado incluso cuando su marca parezca idéntica. Antes de cambiar DNS , guarde los registros existentes y un mensaje de referencia del flujo de trabajo exacto.
El flujo de trabajo de verificación de dominio de Postmark proporciona una DKIM registro TXT y personalizado Return-Path CNAME. Un dominio verificado permite realizar envíos desde direcciones de ese dominio, por lo que la verificación del dominio debe ser propiedad del equipo autorizado para representarlo. Utilice los valores que se muestran para su dominio, no los valores de un inquilino diferente. Verificación del dominio Postmark.
Habilitar la firma antes de cambiar la política
Abra Firmas del remitente, elija el dominio e ingrese Configuración DNS . Copie el nombre de host DKIM y el valor en un registro TXT en el proveedor DNS autorizado. Compruebe si el editor DNS agrega el nombre de la zona; un sufijo duplicado colocará la clave en la ubicación incorrecta. Regrese a Postmark y verifique el registro. Postmark documenta controles automáticos dentro de las 48 horas y un control de verificación manual. La firma comienza después de la verificación. configuración DKIM.
No trate el estatus verde como la prueba de aceptación final. Establece que el proveedor encontró un récord, no es que su aplicación de producción haya utilizado la dirección De remitente prevista ni que una puerta de enlace posterior haya conservado la firma. Programe un envío controlado después de la verificación y conserve el mensaje original del destinatario, incluidas todas las firmas DKIM .
Agregue la Return-Path admitida por separado
Utilice el nombre de host Return-Path que se muestra en la misma configuración de dominio y su destino CNAME , documentado como pm.mtasv.net . Reserve un nombre de host no utilizado para este propósito. No coloques un SPF Registro TXT junto con un CNAME con el mismo nombre de propietario y no reemplace sus registros principales con el CNAME de rebote. La documentación Postmark muestra diferentes ortografías predeterminadas del nombre de host, por lo que el valor de la cuenta real tiene prioridad sobre un ejemplo copiado. Verificación de dominio.
Postmark no requiere su inclusión en el ápice del cliente. Registro SPF. La verificación SPF sigue el dominio del sobre real. Agregar una inclusión de vértice no puede convertir un Return-Path propiedad del proveedor en uno propiedad del cliente. La Return-Path personalizada documentada es un subdominio; Postmark aconseja SPF relajado alineación para esta ruta. Un requisito estricto SPF no se soluciona agregando más inclusiones. Conserve la política aprobada del dominio y utilice una ruta DKIM alineada y verificada cuando corresponda. Guía SPF Postmark.
Probar el resultado de la aplicación.
El siguiente es un diseño de aceptación sintético, no una entrega capturada. Reemplace cada ejemplo con el valor observado y conserve la marca de tiempo y el ID del mensaje de la prueba.
- Evidencia: Visible desde; Valor ilustrativo: receipts@example.com ; Pregunta de aceptación: ¿Es esta la identidad de la solicitud aprobada?
- Evidencia: dominio sobre; Valor ilustrativo: pm-bounces.example.com ; Pregunta de aceptación: ¿Se activó la Return-Path personalizada en este mensaje?
- Evidencia: dominio de firma DKIM ; Valor ilustrativo: example.com ; Pregunta de aceptación: ¿El receptor de confianza validó esta firma?
- Evidencia: DMARC; Valor ilustrativo: pase; Pregunta de aceptación: ¿Qué método de pase alineado produjo este resultado?
- ra Desde el dominio example.com y un subdominio de rebote debajo de él, la alineación relajada SPF puede funcionar, mientras que la alineación estricta SPF no. Un paso de dominio exacto firma DKIM todavía puede satisfacer DMARC . Evalúe la firma observada, no una promesa de que cada mensaje esté firmado. Alineación DMARC.
Pruebe un recibo real y un evento de restablecimiento de contraseña a través de sus respectivas rutas de aplicación. Compare sus transmisiones y la configuración del remitente. Si uno pasa y el otro falla, investigue la ruta divergente antes de alterar DNS compartido. No reenvíe recibos financieros genuinos a los clientes como prueba.
Diagnosticar y recuperar
Si DKIM no está, confirme que el dominio De la aplicación coincida con el dominio verificado y que la firma esté activa. Si la firma existe pero falla, conserve la razón del destinatario e inspeccione la firma exacta. selector búsqueda y cualquier retransmisión de modificación de contenido. Si SPF se aprueba pero no está alineado, inspeccione la activación de Return-Path en lugar de agregar permisos de vértice. Si la verificación DNS falla, compare las respuestas autorizadas, complete el nombre de host y el tipo de registro con los valores de la cuenta.
Pause solo el flujo de la aplicación afectada si falla la aceptación. Restaure el registro guardado o la configuración del remitente a través del cambio de propietario y luego vuelva a probar un evento controlado. No elimine un selector antiguo mientras el correo en cola aún pueda necesitarlo. Retire la delegación de rebotes y los registros de firma no utilizados solo después de confirmar que ninguna otra aplicación Postmark los comparte. Este manuscrito se basa en documentación; no se probó ningún inquilino, cambio DNS o entrega en vivo.
Comparar resultados estrictos y relajados explícitamente
Para el caso escrito PM-01, suponga que De receipts@example.com , CORREO DE bounce@pm-bounces.example.com y un pase SPF confiable para pm-bounces.example.com . Bajo una alineación relajada ordinaria del mismo dominio organizacional, esa ruta SPF se alinea; con aspf=s no coincide exactamente example.com . Supongamos por separado una firma pasajera d=example.com, s=demo1: esa ruta se alinea exactamente y puede satisfacer DMARC incluso en el caso de SPF estricto. Si DKIM se vuelve desconocido en lugar de pasar, no conserve un pase basándose en la premisa anterior. Estos son aportes estipulados, no una entrega Postmark capturada o un consejo para debilitar una política.
Preservar el límite de aplicación
RFC 9989 Sección 7.4 requiere DKIM válido, no solo SPF , para dominios que publican p=reject, y advierte sobre la interoperabilidad del correo indirecto y de las listas de correo. Una sola prueba exitosa de mensajes directos no es prueba de que todas las rutas legítimas estén listas para una política más fuerte. Mantener la protección aprobada existente mientras se diagnostica la brecha real; cualquier cambio de política necesita su propia decisión.