Configurar el correo de un dominio ya no consiste únicamente en crear buzones y conseguir que los mensajes salgan.
Cuando envías desde nombre@tuempresa.es, el servidor que recibe ese correo necesita responder a varias preguntas:
tuempresa.es?SPF, DKIM y DMARC responden precisamente a esas preguntas.
Son tres mecanismos diferentes, pero funcionan mejor juntos. Microsoft los considera componentes interdependientes de la autenticación del correo y Google recomienda configurar los tres en los dominios de envío. Además, Gmail exige actualmente SPF o DKIM a los remitentes y SPF, DKIM y DMARC a determinados remitentes de gran volumen.
Para una pequeña empresa tienen dos funciones especialmente importantes:
Pero configurar estos registros mal también puede provocar justo lo contrario: correos que terminan en spam o incluso mensajes legítimos rechazados.
Una forma sencilla de diferenciarlos es esta:
| Sistema | Qué comprueba |
|---|---|
| SPF | Desde qué servidores está autorizado a enviarse correo para el dominio |
| DKIM | Si el mensaje contiene una firma digital válida asociada al dominio |
| DMARC | Si SPF o DKIM autentican correctamente el dominio que el destinatario ve en el campo From y qué hacer cuando no ocurre |
Hay un detalle importante.
DMARC no sustituye a SPF y DKIM. Se apoya en ellos.
Y tampoco basta necesariamente con que SPF o DKIM indiquen PASS. Para superar DMARC tiene que existir además lo que se denomina alineación.
Más adelante veremos por qué esto es importante.
Los tres sistemas dependen del DNS del dominio.
Esto provoca uno de los errores más frecuentes: entrar en la empresa donde compraste el dominio y añadir allí los registros, aunque los DNS estén realmente gestionados en otro proveedor.
Puedes tener:
El registro debe modificarse donde estén alojadas las DNS autoritativas del dominio.
Si no tienes clara esta diferencia, conviene revisar antes nuestra guía sobre cómo cambiar registros DNS sin romper la web ni el correo.
Añadir un TXT correcto en la zona DNS equivocada no servirá de nada.
SPF significa Sender Policy Framework.
Su función es indicar qué servidores están autorizados para enviar correo utilizando un determinado dominio en la identidad SMTP utilizada por SPF.
Para ello se publica un registro TXT en DNS.
Una configuración sencilla podría parecerse a esta:
v=spf1 include:SERVICIO-DE-CORREO -allNo copies este ejemplo literalmente. El valor que debes utilizar depende de quién envía realmente correo por tu dominio.
Por ejemplo, el proveedor puede pedirte autorizar:
Supongamos que un servidor recibe un mensaje relacionado con empresa.es.
El servidor receptor puede consultar el SPF publicado para comprobar si la infraestructura que está intentando entregar ese mensaje está autorizada.
Si coincide con una de las fuentes permitidas, SPF puede devolver PASS.
Si no coincide, el resultado dependerá de la configuración y de cómo gestione el receptor ese resultado.
La sintaxis SPF permite distintos calificadores. Entre los más habituales están:
-ally:
~all-all indica fail para las fuentes que no hayan sido autorizadas anteriormente.
~all indica softfail.
El estándar SPF define además otros resultados, como neutral.
Una empresa puede enviar correo desde varios lugares:
El SPF debe contemplar las fuentes legítimas que lo necesiten.
El problema aparece cuando alguien configura únicamente Microsoft 365 y meses después conecta otra plataforma.
El correo corporativo puede seguir funcionando perfectamente mientras las newsletters o los formularios fallan SPF.
Por eso un SPF no debería diseñarse preguntando:
¿Dónde tengo mis buzones?
La pregunta correcta es:
¿Qué sistemas envían correo utilizando mi dominio?
Otro error típico consiste en ir añadiendo un SPF independiente cada vez que aparece un proveedor.
Por ejemplo:
v=spf1 include:proveedor-a.example -ally además:
v=spf1 include:proveedor-b.example -allNo deberías resolver de esta manera la incorporación de nuevos remitentes.
Normalmente hay que integrar las fuentes autorizadas dentro de la política SPF correspondiente, siguiendo las instrucciones de los proveedores implicados.
Añadir registros sin comprender el que ya existe es una de esas modificaciones DNS aparentemente pequeñas que puede afectar al correo de toda la empresa.
Este caso es muy frecuente en WordPress.
El correo habitual de la empresa utiliza Microsoft 365 o Google Workspace, pero:
Si alguno de esos sistemas utiliza una infraestructura diferente, debes revisar cómo autentica su correo.
No des por hecho que tener correctamente configurado el buzón info@empresa.es significa que cualquier sistema que utilice esa dirección como remitente está automáticamente autorizado.
SPF tampoco puede crecer indefinidamente.
El estándar limita a 10 las consultas DNS provocadas por determinados mecanismos y modificadores durante la evaluación SPF. Superar ese límite debe producir un permerror.
Esto puede convertirse en un problema cuando el registro acumula numerosos:
include:y cada uno de esos proveedores realiza a su vez otras consultas.
Por eso no conviene añadir servicios indefinidamente al SPF sin revisar el resultado final.
SPF no verifica por sí mismo que el dominio que ve la persona en:
From: ventas@empresa.essea necesariamente el mismo que SPF está autenticando.
Esta diferencia es una de las razones por las que SPF, utilizado aisladamente, no resuelve completamente la suplantación del remitente visible.
Ahí empieza a ser importante DMARC.
DKIM significa DomainKeys Identified Mail.
En lugar de basarse principalmente en qué servidor entrega el mensaje, DKIM utiliza una firma criptográfica.
Cuando el proveedor envía un correo, añade una firma DKIM a sus cabeceras.
El servidor receptor puede consultar el DNS del dominio, obtener la clave pública correspondiente y comprobar esa firma.
Esto permite verificar que determinados elementos firmados del mensaje no han sido alterados después de generarse.
Microsoft describe DKIM precisamente como un mecanismo para firmar digitalmente elementos importantes del mensaje y permitir que el destinatario compruebe esa firma.
Puedes pensar en DKIM como un sistema formado por dos piezas.
El servicio que envía el mensaje conserva una clave privada.
En tus DNS se publica la información necesaria para acceder a la clave pública.
El receptor utiliza esa información para validar la firma.
La clave privada no debes publicarla en DNS.
DKIM introduce además otro concepto: el selector.
Puedes encontrarte registros como:
selector1._domainkey.empresa.eso:
google._domainkey.empresa.esEl selector permite identificar qué clave debe utilizarse para comprobar la firma.
Esto hace posible, entre otras cosas, utilizar distintas claves y rotarlas sin tener que alterar el funcionamiento global del dominio.
El proveedor de correo debe indicarte:
No deberías inventarlos.
No existe una receta única para copiar y pegar.
Algunos proveedores te pedirán crear un TXT.
Otros utilizan CNAME.
Microsoft 365, por ejemplo, utiliza CNAME para determinados registros DKIM de dominios personalizados.
Por eso una guía que te diga simplemente:
«Crea este DKIM»
sin saber qué proveedor utilizas es incompleta.
Este matiz provoca bastantes errores.
Puedes añadir correctamente el registro DNS y, aun así, que tus mensajes todavía no estén siendo firmados.
En muchos servicios hay dos pasos:
Por tanto, después de configurarlo debes enviar un mensaje real y comprobar sus cabeceras.
Lo importante no es que el TXT o CNAME exista.
Lo importante es que el mensaje salga realmente firmado y que la validación indique:
dkim=passLos más frecuentes son:
Google recomienda actualmente claves DKIM de 2048 bits cuando el proveedor las admite, y exige al menos 1024 bits para determinados mensajes dirigidos a Gmail.
DMARC significa Domain-based Message Authentication, Reporting and Conformance.
Es la pieza que conecta SPF y DKIM con el dominio que realmente ve el destinatario.
También permite decirle al receptor qué quieres que haga cuando el mensaje no cumple la política.
Un registro DMARC sencillo puede tener este aspecto:
v=DMARC1; p=none; rua=mailto:dmarc@empresa.esSe publica como TXT en:
_dmarc.empresa.esPero, de nuevo, es solo un ejemplo.
No deberías copiar una política DMARC sin comprender primero qué sistemas envían correo con tu dominio.
Aquí está uno de los puntos que más confusión provoca.
Supongamos que recibes un mensaje que visualmente muestra:
From: facturacion@empresa.esPuede ocurrir que SPF haya validado otro dominio utilizado durante la conversación SMTP.
O que DKIM haya firmado utilizando el dominio de la plataforma que envía el correo.
SPF podría indicar:
spf=passy DKIM:
dkim=passpero eso no significa automáticamente que DMARC tenga que aprobar el mensaje.
DMARC comprueba también la relación entre esos dominios y el dominio visible en From:. Microsoft describe DMARC precisamente como una comprobación de alineación entre las identidades autenticadas y el dominio mostrado al usuario.
Simplificando:
para superar DMARC, SPF o DKIM deben aprobar y además estar adecuadamente alineados con el dominio From.
No es obligatorio que pasen los dos.
Puede superar DMARC gracias a SPF correctamente alineado aunque falle DKIM, o gracias a DKIM alineado aunque SPF falle.
Esta segunda situación tiene especial importancia en determinados reenvíos de correo.
DMARC permite especificar qué política quieres aplicar cuando los mensajes no cumplen sus requisitos.
Las tres más conocidas son:
p=noneEjemplo:
v=DMARC1; p=none;Es básicamente una política de observación.
Los receptores pueden evaluar DMARC y generar informes, pero tú no estás pidiendo que los mensajes que fallen sean puestos en cuarentena o rechazados por esa política.
Suele ser el punto adecuado para empezar.
p=quarantineEjemplo:
v=DMARC1; p=quarantine;Estás solicitando que los mensajes que no superen DMARC sean tratados como sospechosos.
Dependiendo del receptor, pueden acabar por ejemplo en spam o cuarentena.
p=rejectEjemplo:
v=DMARC1; p=reject;Estás solicitando que los mensajes que fallen DMARC sean rechazados.
Es una política fuerte contra la suplantación, pero configurarla antes de identificar todos tus remitentes legítimos puede bloquear tus propios mensajes.
p=rejectEste es probablemente el error DMARC más peligroso.
Una empresa configura:
p=rejectporque parece la opción «más segura».
Pero nadie ha comprobado todavía:
Resultado: algunos correos legítimos empiezan a ser rechazados.
Google recomienda desplegar DMARC gradualmente: primero p=none, analizar los informes y después avanzar hacia políticas de cuarentena o rechazo una vez comprobados los distintos flujos de correo.
Ese enfoque tiene mucho más sentido que publicar una política estricta a ciegas.
DMARC no solo permite establecer una política.
También puede proporcionar información sobre quién está enviando correo utilizando tu dominio.
Para solicitar informes agregados se utiliza habitualmente la etiqueta:
rua=Por ejemplo:
v=DMARC1; p=none; rua=mailto:dmarc@empresa.es;Estos informes pueden ayudarte a detectar:
Google recomienda utilizar informes DMARC precisamente para monitorizar el correo que se envía —o parece enviarse— desde tu dominio.
El inconveniente es que los informes agregados suelen llegar en XML y pueden resultar poco manejables directamente.
Para organizaciones con bastante correo suele ser más práctico utilizar herramientas que los interpreten y agrupen.
No existe un único registro válido para todas las empresas.
La configuración depende de tu infraestructura.
Un procedimiento razonable sería este.
No empieces por DNS.
Empieza con una lista.
Incluye:
Si olvidas un sistema legítimo, una política posterior puede acabar perjudicándolo.
Comprueba los nameservers del dominio.
Eso te permite saber dónde debes publicar los registros.
No confundas:
Pueden ser cuatro empresas distintas.
Consulta la documentación de todos los servicios que deban incluirse.
Construye una única política coherente para ese dominio y comprueba que no exceda los límites técnicos de SPF.
No elimines el registro existente simplemente porque un nuevo proveedor te entregue otro ejemplo.
Primero entiende qué autoriza el anterior.
Genera o activa las claves desde el proveedor.
Publica los TXT o CNAME que te facilite.
Después activa la firma si el proveedor exige un paso adicional.
Envía correos a cuentas externas y revisa las cabeceras.
Busca resultados como:
spf=pass
dkim=pass
dmarc=passPero no te limites a comprobar un mensaje enviado manualmente desde Outlook o Gmail.
Prueba también:
Una configuración básica podría partir de:
v=DMARC1; p=none; rua=mailto:DIRECCION-PARA-INFORMES;La dirección debe existir o gestionarse mediante un servicio preparado para recibir esos informes.
Busca remitentes desconocidos y, sobre todo, remitentes legítimos que todavía estén fallando.
Corrige primero esos problemas.
Cuando conozcas bien los sistemas de envío y hayas comprobado que la autenticación funciona, puedes valorar políticas más estrictas.
El objetivo razonable no es llegar a p=reject cuanto antes.
Es llegar a una política estricta sin bloquear el correo legítimo.
Otro error frecuente consiste en interpretar:
SPF PASS
DKIM PASS
DMARC PASScomo:
Mi correo nunca irá a spam.
No funciona así.
La autenticación es muy importante, pero la entregabilidad también puede depender de otros factores:
Microsoft advierte expresamente que autenticar correctamente el correo no garantiza su entrega.
SPF, DKIM y DMARC permiten al receptor responder a una pregunta concreta:
¿Puedo comprobar que este mensaje está autorizado y relacionado correctamente con el dominio que afirma representarlo?
No obligan al receptor a colocarlo en la bandeja de entrada.
En una pyme es muy habitual encontrar esta combinación:
Correo corporativo → Microsoft 365
Web → otro hosting
Formularios → WordPress
Newsletter → plataforma externaEl propietario cree que solo utiliza Microsoft 365 porque ahí lee su correo.
Pero técnicamente hay tres o cuatro infraestructuras enviando mensajes.
Este tipo de dependencias es una de las razones por las que el mantenimiento de WordPress debería incluir también la revisión de formularios e integraciones importantes, no solamente actualizaciones de plugins.
Cuando hagas cambios técnicos importantes conviene probar estas funciones igual que probarías reservas, pagos o accesos. Nuestra guía sobre cómo actualizar WordPress sin romper la web explica precisamente la importancia de validar los procesos críticos después de una intervención.
Si tuviera que reducir todos los problemas anteriores a una lista de comprobación, prestaría atención a estos:
SPF PASS o DKIM PASS con DMARC PASS.p=reject sin haber monitorizado antes los remitentes legítimos.También merece la pena tratar estos registros como parte de la infraestructura de la empresa.
Los accesos al proveedor DNS, al correo, al dominio y a WordPress deberían estar controlados y documentados. En nuestra guía sobre seguridad WordPress para empresas explicamos por qué la seguridad depende también de saber quién controla cada componente y cada acceso.
Una configuración no está terminada hasta que la pruebas.
El procedimiento más útil consiste en enviar un correo real y revisar sus cabeceras.
En muchos proveedores encontrarás un bloque parecido a:
Authentication-Results:
spf=pass
dkim=pass
dmarc=passComprueba además qué dominios están implicados.
No busques únicamente la palabra pass.
Especialmente con DMARC interesa verificar que la autenticación está alineada con el dominio que utiliza el remitente visible.
Y realiza pruebas desde cada sistema que envía correo.
Que un mensaje enviado desde tu buzón corporativo supere SPF, DKIM y DMARC no demuestra que el formulario de WordPress haga lo mismo.
SPF, DKIM y DMARC parecen inicialmente tres registros DNS que hay que copiar.
Ese enfoque es demasiado simple.
Para configurarlos bien necesitas saber:
La parte complicada rara vez es escribir un TXT.
Lo difícil es conocer toda la infraestructura de envío y evitar que queden sistemas legítimos fuera de ella.
Por eso, si estás configurando el correo de una empresa, empieza haciendo inventario.
Después configura SPF y DKIM.
Comprueba mensajes reales.
Activa DMARC en modo de observación.
Analiza.
Y solo entonces endurece la política.
Es menos espectacular que copiar tres registros DNS en cinco minutos, pero reduce considerablemente la posibilidad de descubrir el error cuando una factura, una reserva o una solicitud de un cliente ya se ha perdido.
