SPF, DKIM y DMARC: registros, alineación y entrega

Empiece por las identidades reales del mensaje

La dirección From visible no coincide necesariamente con la identidad SPF. SPF suele evaluar el dominio del remitente del sobre SMTP; DKIM usa d= como dominio firmante y s= como selector. DMARC comprueba la alineación con el dominio From visible: una validación SPF o DKIM correcta y alineada puede satisfacer la autenticación. Utilice los encabezados originales de un mensaje en un buzón que controle.

Consulte los nombres DNS correctos

Sustituya example.com y selector1 por las identidades indicadas por su proveedor de correo. Los tres comandos suponen que esos dominios coinciden; consulte cada dominio real por separado cuando sean distintos. dig requiere un paquete de utilidades DNS. Sin selector, nuestra herramienta no intenta descubrir registros DKIM.

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Interprete los resultados dentro de los límites del comprobador

check.uk.app solo examina el nombre de host enviado. No expande las cadenas include de SPF, no aplica la herencia DMARC del dominio superior, no verifica firmas de mensajes ni comprueba la alineación. Por tanto, la ausencia de _dmarc en un subdominio no demuestra que no se aplique ninguna política DMARC.

Varios registros SPF que empiezan por v=spf1 en un mismo nombre son un error de configuración; otros registros TXT no relacionados sí están permitidos. Varias cadenas entre comillas dentro de un único TXT no son varios registros SPF. En DKIM, p= vacío revoca la clave; publicar una clave no demuestra que los mensajes salientes se firmen correctamente.

Cambie los registros con datos del proveedor

Identifique todos los remitentes legítimos antes de editar SPF. Mantenga un registro SPF por dominio evaluado y tenga en cuenta el límite de consultas DNS del estándar. Publique el registro DKIM exactamente como se haya emitido para el selector; no sustituya a ciegas claves en uso.

Empiece los cambios de DMARC observando y analizando las fuentes legítimas de envío. p=none no solicita cuarentena ni rechazo por DMARC, pero no garantiza llegar a la bandeja de entrada. Configure un buzón que controle para los informes y confirme cualquier autorización necesaria para enviarlos a un dominio externo. Endurezca la política solo después de comprobar la alineación.

Investigue la entrega más allá del DNS

Si falta un correo de registro, localice el evento de la aplicación, la entrada de la cola y la respuesta SMTP con la misma marca de tiempo. La aceptación SMTP no demuestra la entrega en la bandeja de entrada. Examine los rebotes, la carpeta de spam del destinatario y los Authentication-Results fiables del proveedor receptor. No confíe en encabezados de autenticación arbitrarios añadidos por el remitente.

Guarde los valores DNS y TTL originales antes de editar. Tras publicar, compruebe las respuestas autoritativas y recursivas y envíe un mensaje controlado a su propio buzón. Compare la autenticación antes y después; la caducidad de la caché puede retrasar los cambios. Restaure los registros si fallan remitentes legítimos. check.uk.app no envía correos durante esta prueba.