SPF, DKIM y DMARC: autenticación de correo para empresas

Autenticar correo protege el dominio y ayuda a diagnosticar entregas

SPF, DKIM y DMARC son tres controles distintos que se publican o consultan mediante DNS. Juntos ayudan a los servidores receptores a comprobar qué sistemas envían correo para un dominio, verificar firmas digitales y aplicar la política que su responsable haya definido. No garantizan por sí solos que un mensaje llegue a la bandeja de entrada: también influyen la reputación, el contenido, los rebotes, las quejas y las reglas del proveedor receptor.

La diferencia práctica importa: un dominio puede tener SPF y aun así fallar DMARC si los identificadores no están alineados; DKIM puede validar una firma cuyo dominio tampoco coincide con el remitente visible. La guía de DMARC de IETFdefine esa alineación y exige que pase al menos una identidad autenticada y alineada: SPF o DKIM.

Qué comprueba cada mecanismo

• SPF: publica qué servidores están autorizados para enviar correo usando el dominio del remitente SMTP, normalmente el de retorno o MAIL FROM. El receptor compara ese dominio con el servidor que conectó, según el RFC 7208. No autentica por sí solo el nombre visible en el campo From.
• DKIM: el sistema emisor agrega una firma criptográfica al mensaje. El receptor consulta en DNS la clave pública asociada al dominio y al selector de esa firma. Así puede validar la firma y saber qué dominio firmó, conforme al RFC 6376. El resultado no demuestra que el contenido sea legítimo.
• DMARC: compara el dominio del campo visible From con el dominio autenticado por SPF o DKIM. Si al menos uno valida y queda alineado, DMARC pasa. El registro también permite solicitar informes y comunicar una preferencia de tratamiento cuando la verificación falla.

Para una explicación de los registros DNS involucrados, consulta la guía de DNS para empresas. Este artículo se concentra en autenticación y operación de correo.

1. Haz inventario de todos los sistemas que envían

Antes de editar DNS, enumera cada origen que envía mensajes con tu dominio: buzones corporativos, aplicaciones web, formularios, CRM, boletín, facturación, plataformas de soporte, impresoras y servicios contratados. Anota para cada uno el dominio del remitente, el proveedor, quién lo administra y si firma con DKIM. Incluye sistemas poco frecuentes y entornos de prueba.

Solicita al proveedor SMTP los registros exactos para autenticar tu dominio y confirma si firma los mensajes con DKIM. Que la conexión SMTP funcione con usuario y contraseña solo demuestra que la aplicación pudo entregar el mensaje al servidor configurado; no prueba que SPF, DKIM y DMARC estén publicados o alineados. Guarda el estado actual de DNS y prepara reversión antes de cambios.

2. Configura SPF sin duplicar políticas

El registro SPF suele ser un TXT en el dominio que aparece en el remitente SMTP. Debe contemplar todos los emisores autorizados. Si ya existe un registro SPF, integra el nuevo proveedor con la política que ya tienes; no publiques otro registro SPF independiente para el mismo nombre. El RFC 7208 establece un máximo de diez términos de evaluación que provocan consultas DNS, como include, a, mx, exists y redirect. Rebasarlo puede producir un error permanente de SPF.

No copies una cadena encontrada en internet ni elimines métodos de envío que no reconozcas. Un cambio incompleto puede dejar fuera correo legítimo de otra plataforma. El proveedor de cada sistema debe indicar su mecanismo de autorización y el nombre exacto donde se publica.

3. Publica DKIM desde el proveedor que firma

El proveedor genera o administra la clave DKIM y entrega el nombre de registro, el selector y el valor DNS. El selector identifica una clave dentro del dominio y permite rotarla sin cambiar todas las demás. Según el servicio, el registro puede ser TXT o CNAME; usa el tipo y destino que indique la consola del proveedor. La clave privada debe permanecer bajo control del firmante y nunca debe publicarse en DNS ni guardarse en el repositorio de la aplicación.

Si varias plataformas envían con el mismo dominio, revisa cada flujo. Puede haber selectores distintos. Una firma válida con dominio ajeno o no alineado aún puede no servir para pasar DMARC.

4. Activa DMARC en modo de observación

Una vez que SPF y DKIM funcionan, define un buzón o proceso para recibir y analizar informes agregados. El estándar actual es RFC 9989, que sustituyó RFC 7489. Recomienda empezar con una política de observación p=none, revisar los informes, descubrir remitentes legítimos que faltan y corregir la alineación antes de considerar medidas de aplicación. Los reportes agregados pueden incluir fuentes que no conocías y datos que requieren análisis automatizado.

Un registro de ejemplo puede mostrar la forma general, pero no es una configuración lista para copiar:

_dmarc.ejemplo.com. TXT "v=DMARC1; p=none; rua=mailto:reportes@ejemplo.com"

Sustituye el dominio y usa una dirección que exista, esté autorizada y tenga un proceso para analizar esos informes. El RFC 9989 advierte que imponer p=reject puede afectar correo legítimo, reenvíos y listas de distribución. No eleves la política por calendario: primero necesitas conocer los flujos y sus resultados durante un periodo suficiente para tu volumen y frecuencia de envío.

5. Valida DNS y mensajes reales

Tras publicar registros, consulta DNS desde una máquina que tenga dig. Cambia el dominio y el selector por los nombres reales indicados por tu proveedor:

dig +short TXT ejemplo.com
dig +short TXT selector._domainkey.ejemplo.com
dig +short TXT _dmarc.ejemplo.com

La consulta SPF puede devolver varios TXT del dominio; identifica la política que empieza con v=spf1 y confirma que haya una sola. Un selector DKIM podría resolverse mediante CNAME, por lo que revisa el tipo publicado y sigue la respuesta hasta el destino final cuando corresponda. Si el cambio no aparece de inmediato, considera TTL y cachés DNS antes de editar otra vez.

Envía mensajes de prueba desde cada sistema a buzones que puedas revisar y consulta los encabezados originales. En Authentication-Resultsverifica SPF, DKIM y DMARC, y comprueba qué dominios aparecen como autenticados.Google recomienda SPF, DKIM y DMARCpara proteger el dominio y ofrece requisitos adicionales para remitentes masivos. La prueba útil combina la respuesta DNS con un mensaje generado por cada flujo real.

Fallos habituales y control antes de aplicar cambios

• Publicar dos registros SPF separados para el mismo dominio.
• Autorizar solo el servidor de correo principal y olvidar formularios, CRM o boletines.
• Activar DMARC restrictivo antes de identificar todos los emisores legítimos.
• Confundir un inicio de sesión SMTP correcto con autenticación del dominio.
• Copiar el selector o la clave DKIM de otro dominio o cuenta.
• Tratar un resultado SPF o DKIM válido como garantía de entrega en bandeja de entrada.

Si envías mensajes promocionales o boletines, solicita consentimiento, confirma las altas y facilita la baja. Mantén separadas las tareas: primero inventario, luego registros del proveedor, pruebas por flujo y análisis de informes. Si la infraestructura cambia, repite la revisión antes de retirar el emisor anterior.

Elaine System puede ayudarte a revisar dominios, DNS y correo corporativo con el alcance acordado. Describe qué proveedor envía tus mensajes y qué error observas en la página de contacto para valorar el siguiente paso.