SPF, DKIM y DMARC: protege tu correo empresarial

Por qué tu buzón no basta

Varios sistemas suelen enviar con tu dirección empresarial: el proveedor de correo, el formulario web, la contabilidad, el boletín o el sistema de incidencias. Que un mensaje aparezca en enviados no demuestra que el destinatario pueda asociarlo de forma fiable con tu dominio.

Sin medidas adecuadas, es fácil suplantar la dirección visible del remitente. La autenticación ayuda a distinguir los envíos autorizados de ciertas formas de abuso del dominio. No verifica si una oferta es fiable ni si una factura es correcta.

Tres mecanismos comparten esta tarea. DNS publica los ajustes de tu dominio; el destinatario realiza las comprobaciones.

SPF: ¿qué servidores pueden enviar para este dominio?

SPF significa Sender Policy Framework. El dominio publica un registro TXT que define los sistemas autorizados. El destinatario compara la IP de envío con esa política.

El detalle importante: normalmente SPF comprueba el dominio del remitente del sobre SMTP, la dirección técnica para avisos de entrega. Puede diferir de la dirección visible De. Por eso, un SPF válido no demuestra por sí solo que la dirección empresarial visible esté autenticada.

No añadas una política SPF adicional en el mismo nombre DNS para cada proveedor. Varias políticas SPF en ese nombre son inválidas. SPF limita a diez los mecanismos y redirecciones evaluados que generan consultas DNS; los include anidados cuentan. Referencia técnica: RFC 7208.

En la práctica: integra los requisitos de tus servicios reales en una política coordinada. Añadir un servicio exige revisar la configuración, no crear automáticamente otro TXT con v=spf1.

DKIM: ¿qué dominio ha firmado el mensaje?

DKIM significa DomainKeys Identified Mail. El servicio firma partes del mensaje con una clave privada. El receptor utiliza la clave pública de DNS para comprobar la firma y determinar qué dominio asume la responsabilidad.

La firma incluye un dominio y un selector. El selector permite encontrar la clave pública correcta. Cada servicio puede usar un selector distinto; no necesitan compartir la clave.

La clave privada permanece en el sistema que firma. No debe publicarse en DNS ni enviarse en un mensaje a soporte. Referencia técnica: RFC 6376.

En la práctica: activa DKIM en cada servicio y publica exactamente los registros solicitados. Algunos requieren TXT; otros, como Microsoft 365, referencias CNAME. Microsoft documenta aquí su configuración.

Un registro DNS no basta: comprueba un mensaje real para confirmar que el servicio firma con el dominio previsto.

DMARC: ¿coincide con el remitente visible?

DMARC significa Domain-based Message Authentication, Reporting, and Conformance. Relaciona SPF y DKIM con el dominio visible del remitente y establece una política para las comprobaciones fallidas.

Para superar DMARC debe cumplirse al menos una condición:

• SPF pasa y el dominio comprobado está alineado con el dominio visible del remitente.
• DKIM pasa y el dominio firmante está alineado con el dominio visible del remitente.

Esta relación se llama alineación. Según el ajuste, los dominios deben coincidir exactamente o pertenecer al mismo dominio organizativo. Un spf=pass para el dominio ajeno de un proveedor no basta automáticamente. Lo mismo ocurre con una firma DKIM que solo identifica al proveedor.

Las políticas incluyen none, quarantine y reject: no solicitar un tratamiento especial solo por esta política, solicitar tratamiento como sospechoso o solicitar el rechazo. El receptor sigue tomando su propia decisión de entrega. Referencia: RFC 9989.

En la práctica: configura ambos mecanismos siempre que sea posible. DMARC no exige que ambos pasen a la vez, pero disponer de dos vías correctas ayuda ante distintos envíos y reenvíos.

Paso 1: inventaría todas las rutas de envío

Antes de cambiar DNS, prepara un inventario suficientemente completo para tu negocio.

Ruta	Qué debes aclarar
Buzones habituales	¿Qué proveedor envía y quién administra los ajustes del dominio?
Sitio web y formulario	¿WordPress envía desde el servidor web o mediante un servicio configurado?
Facturas y presupuestos	¿Qué dominio remitente utiliza realmente el programa?
Boletín	¿El dominio está verificado y configurado para DKIM?
Escáner, NAS y sistema de incidencias	¿Qué cuenta SMTP o relay utilizan?

Anota la dirección visible, el responsable técnico y las instrucciones vigentes de cada servicio. Incluye tareas poco frecuentes, como la facturación de fin de mes.

Un error frecuente en formularios es usar la dirección del visitante como remitente visible. Utiliza una dirección propia correctamente configurada. La dirección del visitante suele corresponder a Reply-To para recibir las respuestas. Tu sitio no puede autenticar sin más el dominio del visitante.

Paso 2: comprueba SPF y DKIM por servicio

Guarda la configuración DNS actual como referencia. Consulta la documentación vigente de cada proveedor, modifica un punto identificable cada vez y registra los cambios.

Para SPF, averigua qué dominio usa el remitente del sobre y qué permisos necesita. Algunos servicios lo gestionan bajo un dominio propio. Para DMARC debe existir una vía de autenticación alineada, por ejemplo DKIM con tu dominio.

Para DKIM, activa la firma, publica los registros requeridos y espera la confirmación. Después envía un mensaje real desde ese sistema.

Las consultas muestran lo publicado. Sustituye estos nombres de ejemplo reservados:

dig TXT werkstatt.example +short
dig TXT selector1._domainkey.werkstatt.example +short

selector1 no es universal. Usa el selector de tu proveedor y comprueba también el CNAME cuando corresponda. No copies una política SPF completa ni una clave DKIM de un tutorial ajeno: esos valores dependen de tu configuración.

Paso 3: comienza DMARC con informes

Un punto de partida puede ser p=none con una dirección para informes agregados. Permite observar sin solicitar todavía cuarentena o rechazo mediante esa política. Los demás filtros del destinatario siguen activos.

Un ejemplo ilustrativo, no para pegarlo sin cambios:

Nombre DNS: _dmarc.werkstatt.example
Tipo: TXT
Valor: v=DMARC1; p=none; rua=mailto:dmarc@werkstatt.example

Sustituye el dominio y la dirección de destino. El destino debe estar configurado y permitir el análisis. Si pertenece a un servicio externo bajo otro dominio, puede requerir autorización DNS adicional.

Los informes agregados resumen fuentes de envío y resultados de autenticación. Suelen ser XML, no listas cómodas de correos individuales. No todos los receptores informan de todo; la ausencia de anomalías no demuestra una entrega completa. RFC 9990 describe estos informes.

Planifica quién revisará los informes, investigará fuentes desconocidas y contactará con los responsables. Un buzón de informes desatendido solo acumula trabajo.

Paso 4: corrige errores y endurece la política

Observa un periodo que cubra tus procesos reales. Un número fijo de días no sustituye la comprobación de facturas mensuales, boletines y sistemas poco utilizados.

Investiga las fuentes anómalas. Una IP desconocida puede pertenecer a un servicio legítimo olvidado o indicar envíos no autorizados. No amplíes SPF solo porque aparezca una dirección en un informe. Identifica primero quién envía y si esa ruta es necesaria.

Cuando las rutas legítimas conocidas den resultados correctos, introduce una política más estricta de forma controlada. Documenta el estado anterior, sigue observando informes y problemas de entrega y asigna un responsable. Pasar a reject es una decisión operativa, no una casilla final.

Cómo revisar un mensaje de prueba

Envía desde cada sistema a un buzón externo que controles. Abre las cabeceras completas y busca los resultados añadidos por el proveedor receptor. Las líneas antiguas de procedencia desconocida no son pruebas fiables.

1. SPF: ¿qué dominio se comprobó y pasó?
2. DKIM: ¿qué dominio firmó y la firma es válida?
3. DMARC: ¿al menos una vía válida está alineada con el dominio visible?

Prueba también tus procesos reales. Los reenvíos pueden romper SPF porque interviene otro servidor. DKIM puede sobrevivir si no se alteran indebidamente las partes firmadas. Los mensajes modificados y las listas de correo pueden producir otros resultados.

Qué no resuelven SPF, DKIM y DMARC

No cifran el contenido del correo. Tampoco protegen frente a todos los dominios parecidos ni frente a un buzón auténtico ya comprometido. Siguen siendo necesarios la protección de cuentas, el acceso seguro y procesos empresariales cuidadosos.

Superar las comprobaciones no garantiza llegar a la bandeja de entrada. La entrega directa requiere además una identidad de servidor adecuada y DNS inverso funcional. Consulta cómo comprobar PTR y DNS inverso.

Tu siguiente paso: un inventario completo

Empieza por la lista de servicios y un mensaje de prueba por sistema. Después comprueba SPF y DKIM, organiza una revisión real de informes DMARC y endurece la política con esa base.

Así tendrás un servicio de correo trazable que podrás mantener cuando cambies de proveedor. Encontrarás definiciones breves en el glosario.