Comprobar SPF, DKIM y DMARC en cada ruta de envío

Cuando una aplicación envía correo mediante un servicio externo, no basta con mirar la dirección de la empresa en el programa de correo. Registre la ruta real y compruebe un mensaje de prueba autorizado en el punto de recepción previsto. Los registros DNS y la comprobación del mensaje responden a preguntas distintas.

Empezar por una ruta de envío concreta

En el diseño ficticio, un portal de clientes envía avisos de estado. El remitente visible es hinweis@firma.example; el servicio externo utiliza versand.example como dominio de su remitente SMTP y de su firma. Los nombres sirven solo para este diseño. No se envió ningún mensaje ni se consultó ningún registro DNS.

Aclare primero qué aplicación activa el correo, qué servicio lo transmite y quién administra la configuración de dominio de ese servicio. Registre otras rutas por separado, por ejemplo, las notificaciones de un sistema de soporte. La configuración de un servicio no demuestra la de otro.

Comprobar juntos DNS y mensaje real

SPF describe los servidores autorizados para identidades SMTP. Relacione el registro publicado con el dominio SMTP utilizado realmente. La mera presencia de un registro TXT no es un resultado correcto para esa ruta concreta.

DKIM asocia las partes firmadas del mensaje con el dominio firmante. Compruebe también si el servicio firma realmente y si la firma es válida en el punto de recepción previsto. Publicar una clave pública en el DNS no lo confirma por sí solo. Tenga en cuenta los servicios que procesan el mensaje después de la firma.

DMARC exige una comprobación SPF o DKIM correcta con una alineación de dominio adecuada al remitente visible. Esa correspondencia se llama alignment o alineación. Determine también el registro DMARC aplicable y las condiciones de alineación que establece.

Valorar correctamente un resultado positivo aislado

La tabla siguiente contiene supuestos construidos deliberadamente para el mismo diseño, no resultados medidos.

Para la aprobación, el servicio concreto debe admitir una configuración de dominio adecuada y el envío correspondiente. El cambio necesario depende del servicio. Copiar cualquier registro DNS existente o fijar precipitadamente una política de rechazo no resuelve el problema de alineación.

Conservar la prueba de envío controlada como evidencia

Documente la ruta, los dominios utilizados, el mensaje comprobado y los resultados de la prueba. Si intervienen otros servicios, esa ruta también necesita un caso de prueba adecuado. Repita la comprobación tras cambios en el servicio, el dominio o el procesamiento de mensajes.

Google trata la autenticación como parte de sus requisitos de envío. Ni siquiera un caso de prueba técnico correcto demuestra la ubicación en la bandeja de entrada ni la lectura. Registre por separado la observación de recepción e identifique quién atiende los controles fallidos y las notificaciones de entrega.

Fuentes

• IETF: Sender Policy Framework

• IETF: DKIM Signatures

• IETF: DMARC

• Google: Email sender guidelines