SPF, DKIM, DMARC y MX: qué revisar

MX indica dónde se recibe el correo de un dominio. SPF, DKIM y DMARC ayudan a comprobar su autenticación. Si tus mensajes rebotan o llegan a spam, distingue primero qué parte falla: cambiar registros sin identificar la causa puede afectar a otros servicios que también envían correo.

Esta referencia está dirigida a quien administra el dominio o coordina su revisión con un proveedor. Te ayudará a reunir los valores correctos y comprobar un mensaje; no sustituye las instrucciones de configuración de tu servicio de correo.

Qué hace cada registro

Las definiciones técnicas están en las especificaciones de MX, SPF, DKIM y DMARC.

Haz el inventario de emisores antes de editar DNS

Incluye los buzones, el formulario del sitio, el sistema de facturación y la plataforma de campañas. Para cada uno, anota el proveedor, el dominio que utiliza y quién puede cambiar su configuración. Un servicio olvidado puede explicar por qué algunos mensajes funcionan y otros no.

Pide al proveedor sus valores vigentes y conserva una copia de la configuración anterior. Si todavía no tienes claro qué cuentas y procesos dependen del correo, empieza por organizar el correo de tu empresa.

Cómo leer una configuración de ejemplo

Ejemplo ficticio, no una configuración para copiar: los nombres example.com están reservados para documentación y la IP 192.0.2.10 pertenece a un bloque de ejemplo. No representan servidores operativos. La clave DKIM se omite intencionalmente. Referencias: dominios de ejemplo y direcciones para documentación.

En MX, el número indica preferencia: los valores menores tienen prioridad. El SPF del ejemplo sólo autoriza esa IP; sería insuficiente si otro servicio también enviara mensajes. Publica un único registro SPF aplicable a cada nombre, con todos los emisores que correspondan. Agregar proveedores mediante include exige revisar el límite de diez términos que provocan consultas DNS durante la evaluación; no equivale a permitir diez proveedores sin más.

En DKIM, correo es el selector del ejemplo. El dominio firmante y el selector determinan dónde buscar la clave pública. Un proveedor puede pedir un CNAME en lugar de este TXT: sigue su configuración real. Publicar una clave no sustituye activar la firma en el emisor.

Comprueba el mensaje, además del DNS

Para un mensaje de prueba de cada emisor, abre los encabezados completos en el buzón receptor. Busca los resultados de autenticación que añadió ese receptor, junto con las identidades evaluadas. No basta con encontrar la palabra pass en cualquier encabezado.

Supón que el remitente visible es ventas@example.com. Si DKIM pasa con d=example.com, hay una firma alineada exactamente con ese dominio. Si SPF pasa únicamente para un dominio diferente del proveedor, ese resultado no demuestra alineación con example.com. DMARC necesita al menos uno de los dos mecanismos autenticado y alineado; no exige que ambos pasen.

La política p=none sirve para observar sin pedir cuarentena o rechazo por DMARC. El buzón de reportes debe existir y revisarse. Antes de aplicar una política más estricta, identifica emisores legítimos y revisa el efecto de reenvíos o listas de correo. Autenticación correcta y entrega en bandeja de entrada siguen siendo comprobaciones distintas.

Qué guardar si algo sigue fallando

Conserva el código de rebote, la hora, el servicio emisor y los resultados de autenticación. Comparte sólo lo necesario: los encabezados y reportes pueden contener direcciones u otros datos privados. Con esa evidencia podrás distinguir un problema de recepción, autorización del emisor, firma o alineación.