Si has buscado alguna vez cómo proteger el correo de tu empresa, te habrás topado con tres siglas que aparecen siempre juntas: SPF, DKIM y DMARC. La mayoría de las explicaciones asumen que ya sabes de DNS, cabeceras y protocolos. Esta no. Aquí van los tres, con analogías que se entienden a la primera y sin dar nada por sabido.
Empecemos por el problema que resuelven. El correo electrónico, tal como se diseñó, no comprueba quién envía cada mensaje. Cualquiera puede escribir un correo poniendo tu dominio en el remitente, y el sistema se lo cree. SPF, DKIM y DMARC son las tres capas que cierran esa puerta. Cada una responde a una pregunta distinta.
SPF: ¿quién tiene permiso para enviar en tu nombre?
Imagina la lista de invitados de un evento privado. En la puerta, seguridad comprueba si el que llega está en la lista. Si no está, no entra.
SPF (*Sender Policy Framework*) es esa lista. Es un registro que publicas en tu dominio diciendo: «los servidores autorizados a enviar correo en mi nombre son estos». Cuando llega un correo tuyo, el receptor mira si el servidor que lo envió está en la lista. Si está, bien. Si no, sospecha.
El punto débil de SPF: la lista tiene un límite de tamaño (no puede requerir más de 10 consultas). Si tu empresa usa muchas herramientas que envían correo —el buzón corporativo, la de facturación, la de campañas, el CRM—, es fácil pasarse. Y cuando te pasas, SPF deja de funcionar del todo. Es uno de los fallos más comunes y silenciosos que existen.
DKIM: ¿este correo es auténtico y llega intacto?
Ahora piensa en un sello de cera lacrada sobre una carta antigua. El sello demuestra dos cosas: que la carta la escribió quien dice, y que nadie la ha abierto ni manipulado por el camino.
DKIM (*DomainKeys Identified Mail*) es ese sello, en versión digital. Tu dominio firma cada correo con una clave criptográfica, y el receptor comprueba esa firma contra una clave pública que publicas en tu DNS. Si la firma cuadra, sabe dos cosas: el correo salió de verdad de tu dominio y el contenido no se ha alterado en tránsito.
SPF valida el servidor; DKIM valida el mensaje. Son complementarios, no intercambiables. Por eso necesitas los dos.
DMARC: ¿qué hago con los correos que no pasan?
SPF y DKIM comprueban cosas, pero por sí solos no le dicen al receptor qué hacer cuando algo falla. Ese es el trabajo de DMARC.
Piénsalo como las instrucciones que dejas al de seguridad: «si alguien no está en la lista y no trae el sello, no le dejes pasar, y avísame». DMARC (*Domain-based Message Authentication, Reporting and Conformance*) hace justo eso. Establece una política —qué hacer con los correos que no autentican— y, además, activa un sistema de informes: cada día, los proveedores de correo te envían un resumen de quién ha enviado en tu nombre y si pasó las comprobaciones.
La política DMARC tiene tres niveles:
– `p=none` — solo observa. Recoge información pero no bloquea nada. Es el punto de partida, no el destino.
– `p=quarantine` — los correos que fallan van a spam.
– `p=reject` — los correos que fallan se rechazan directamente. Nadie puede suplantarte. Este es el objetivo.
Aquí está el matiz clave: DMARC exige *alineación*. No basta con que SPF o DKIM pasen; el dominio que ves en el «De:» tiene que coincidir con el dominio validado. Una herramienta puede pasar la comprobación técnica y aun así fallar DMARC porque firma con su propio dominio, no con el tuyo. Detectar y arreglar eso es buena parte del trabajo real.
Por qué necesitas los tres, no uno
Resumido:
– SPF dice quién puede enviar.
– DKIM demuestra que el correo es auténtico e íntegro.
– DMARC decide qué pasa con lo que no cuadra, y te informa de todo.
Falta uno y el conjunto se cae. Con solo SPF, no proteges el contenido ni tienes visibilidad. Con solo DKIM, no controlas los servidores. Sin DMARC, ninguno de los dos sirve para *bloquear* nada, solo para observar.
El orden importa más que la prisa
El error más caro es publicar `p=reject` de golpe para «estar protegido ya». Si no has identificado antes todas las fuentes legítimas que envían en tu nombre, empezarás a rechazar tus propios correos: los de tu herramienta de facturación, tus newsletters, tu CRM. El camino correcto es al revés: empezar en `p=none`, recoger informes durante el tiempo necesario para ver *toda* la realidad de tu dominio, y subir la política solo cuando los datos confirman que es seguro. En una organización mediana, ese proceso suele llevar de 6 a 10 semanas.
Si prefieres no hacerlo a ciegas
Entender qué hace cada candado es una cosa; desplegarlos sin romper tus envíos es otra. En Reliant nos encargamos del proceso completo —auditoría, configuración por fases y vigilancia continua— y te explicamos cada cambio antes de tocarlo.
Empieza por saber cómo está tu dominio hoy: pide tu diagnóstico gratuito y te enviamos un informe con lo que tienes bien, lo que tienes mal y qué riesgo real corres.