Durante mucho tiempo, muchas empresas han tratado el correo electrónico como algo secundario: se crea una cuenta, se configura en Outlook, en Thunderbird o en el móvil y listo. Mientras los mensajes entren y salgan, parece que todo está correcto.
Pero, en mi opinión, esa forma de verlo se ha quedado corta.
Hoy el correo corporativo es una de las partes más delicadas de cualquier negocio. Por email se envían presupuestos, facturas, contratos, accesos, comunicaciones internas, avisos a clientes, respuestas de soporte y mensajes comerciales. No estamos hablando solo de una bandeja de entrada: estamos hablando de una herramienta que afecta directamente a la confianza, a la seguridad y a la reputación de una empresa.
Por eso, configurar SPF, DKIM y DMARC ya no debería verse como una opción técnica avanzada, sino como una medida básica cuando usas un correo con dominio propio.
Una dirección como info@tudominio.com transmite una imagen mucho más profesional que una cuenta genérica. Pero esa imagen también debe estar protegida. De poco sirve tener un correo corporativo si cualquiera puede intentar suplantar tu dominio o si tus mensajes legítimos acaban en la carpeta de spam por una mala configuración DNS.
Y aquí viene una idea importante: que un correo llegue no significa que esté bien configurado.
Puede que tus emails estén llegando hoy, pero eso no garantiza que todo esté correctamente autenticado. Mañana pueden empezar a caer en spam porque falta un registro, porque tienes varios servicios enviando en nombre del dominio o porque Gmail, Outlook u otros proveedores no reciben suficientes señales para confiar en tus mensajes.
SPF, DKIM y DMARC ayudan precisamente a resolver ese problema. Son tres mecanismos de autenticación que permiten a los servidores de correo comprobar si un mensaje enviado desde tu dominio es legítimo o si alguien está intentando falsificarlo.
Bien configurados, ayudan a:
- Reducir la suplantación de identidad.
- Mejorar la entregabilidad del correo.
- Proteger la reputación del dominio.
- Evitar que terceros envíen mensajes fraudulentos en tu nombre.
- Dar más confianza a proveedores como Gmail, Outlook o Yahoo.
- Detectar servicios que están enviando correos sin estar correctamente autorizados.
No hacen que una empresa sea invulnerable, pero sí construyen una base mucho más sólida.
Qué son SPF, DKIM y DMARC y cómo trabajan juntos
Antes de configurar nada, conviene entender qué papel cumple cada registro. No hace falta ser administrador de sistemas para entenderlo; basta con verlo como una cadena de confianza.
SPF, DKIM y DMARC no son lo mismo, pero trabajan juntos. Cada uno responde a una pregunta diferente:
- SPF: ¿qué servidores están autorizados a enviar emails por este dominio?
- DKIM: ¿este mensaje lleva una firma válida y no ha sido alterado?
- DMARC: ¿qué hacemos si el mensaje no supera las comprobaciones anteriores?
Cuando los tres están bien configurados, el dominio tiene una autenticación mucho más completa.
SPF: qué servidores pueden enviar correos por tu dominio
SPF significa Sender Policy Framework. Es un registro DNS que indica qué servidores o servicios tienen permiso para enviar correos en nombre de tu dominio.
Por ejemplo, imagina que tu empresa usa:
- El correo del hosting.
- Un formulario de contacto en WordPress.
- WooCommerce para enviar pedidos.
- Un CRM para responder a clientes.
- Una plataforma de email marketing.
- Un programa de facturación.
- Google Workspace o Microsoft 365.
Todos esos sistemas pueden estar enviando emails usando tu dominio. Si no están correctamente incluidos en el SPF, algunos mensajes pueden parecer sospechosos para los servidores receptores.
Dicho de forma sencilla: SPF le dice al mundo algo como “estos son los servidores que pueden enviar correos por mí”.
El problema aparece cuando se añaden servicios sin revisar el SPF. Esto pasa mucho. Una empresa empieza con el correo del hosting, después conecta una newsletter, luego un CRM, más tarde una tienda online y, al final, nadie sabe exactamente qué servicios están enviando correos desde el dominio.
También es habitual copiar un SPF de internet sin entender si realmente corresponde a ese dominio. Eso puede dejar fuera servidores legítimos o incluir servicios que no pintan nada.
DKIM: la firma digital que demuestra que el mensaje no ha sido alterado
DKIM significa DomainKeys Identified Mail. Su función es añadir una firma digital al correo saliente.
Esa firma permite que el servidor receptor compruebe dos cosas:
- Que el mensaje procede de un sistema autorizado.
- Que el contenido no ha sido alterado durante el envío.
Para mí, DKIM es una de las piezas más importantes porque añade una capa de confianza que SPF por sí solo no cubre completamente.
Una forma sencilla de entenderlo es esta:
SPF dice “este servidor puede enviar”, mientras que DKIM ayuda a demostrar que el mensaje mantiene una firma válida asociada al dominio.
Normalmente, DKIM se activa desde el proveedor de correo o desde el panel de hosting. Después, se publica una clave pública en las DNS del dominio mediante un registro TXT o CNAME, según el proveedor.
Si DKIM no está activo, algunos correos pueden seguir entregándose, pero pierden una señal importante de autenticación. Y cuando hablamos de correo corporativo, cada señal cuenta.
DMARC: la política que decide qué hacer cuando algo falla
DMARC significa Domain-based Message Authentication, Reporting and Conformance. Es el mecanismo que une SPF y DKIM y permite indicar qué debe hacer el servidor receptor cuando un mensaje no supera las comprobaciones.
Con DMARC puedes definir una política:
p=none: no bloquees nada, solo monitoriza.p=quarantine: marca como sospechosos los mensajes que fallen.p=reject: rechaza los mensajes que no superen la autenticación.
Aquí es donde muchas empresas cometen un error: quieren ir directamente a la política más estricta pensando que así estarán más seguras.
Yo no lo recomiendo.
Configurar un p=reject sin revisar antes todo el ecosistema de envío puede parecer muy seguro, pero también puede provocar que correos legítimos de la empresa dejen de entregarse si hay servicios mal autorizados.
Lo más prudente suele ser empezar con p=none, analizar qué servicios están enviando en nombre del dominio, corregir errores y, cuando todo esté claro, avanzar hacia políticas más estrictas.
Antes de tocar las DNS: identifica todos los servicios que envían correos
Uno de los errores más habituales al configurar SPF, DKIM y DMARC es empezar directamente por copiar registros DNS sin revisar antes desde dónde salen realmente los correos.
Y esto es clave.
Una empresa no siempre envía emails solo desde una cuenta tipo info@tudominio.com. Muchas veces hay más sistemas implicados de los que parece.
Antes de modificar SPF, activar DKIM o publicar DMARC, haz una lista de todos los puntos desde los que se pueden enviar correos usando tu dominio.
Correo del hosting, webmail, Outlook y Thunderbird
El primer punto suele ser el correo principal del hosting o del proveedor de correo corporativo.
Aquí entran las cuentas que usas desde:
- Webmail.
- Outlook.
- Thunderbird.
- Aplicaciones móviles.
- Clientes IMAP o POP.
- SMTP del proveedor.
Si tienes un servicio de correo corporativo con dominio propio, este será normalmente el sistema base que debe quedar autorizado en SPF y firmado con DKIM.
En el caso de servicios orientados a empresas, como HostingTG, tiene sentido que el correo corporativo se configure pensando no solo en crear buzones, sino también en la seguridad, el acceso por webmail, la compatibilidad con Outlook o Thunderbird, el soporte técnico, SSL, antivirus, antispam y la revisión de registros como SPF, DKIM y DMARC cuando hay problemas de spam o entregabilidad.
Porque el correo no va solo de “crear cuentas”. Va de que esas cuentas funcionen bien y sean fiables.
WordPress, formularios, WooCommerce y WHMCS
Después está la web.
Muchas empresas tienen WordPress y no siempre son conscientes de que la web también envía correos. Formularios de contacto, avisos de recuperación de contraseña, notificaciones internas, confirmaciones de pedidos, reservas o mensajes automáticos pueden salir desde el servidor web o desde un plugin SMTP.
Si usas WooCommerce, WHMCS o cualquier sistema similar, esto cobra todavía más importancia. Un pedido, una factura o una notificación de soporte que no llega puede convertirse en un problema comercial.
Aquí suele aparecer el típico caso: “mi correo funciona, pero los mensajes del formulario llegan a spam” o “los emails de WooCommerce no se entregan bien”.
Muchas veces el problema no está en el buzón, sino en que la web está enviando correos de una forma que no está correctamente alineada con SPF, DKIM y DMARC.
También hay que revisar herramientas externas.
Por ejemplo:
- CRM.
- Plataformas de email marketing.
- Software de facturación.
- Herramientas de soporte.
- Sistemas de reservas.
- Aplicaciones de automatización.
- Plataformas de presupuestos.
- Servicios de envío transaccional.
Todos estos servicios pueden enviar correos como si fueran tu dominio o en nombre de tu dominio.
Si no los tienes controlados, puedes terminar con un SPF desordenado, DKIM sin configurar en algunas herramientas y DMARC dando errores porque los mensajes no están alineados.
Por eso, antes de configurar nada, mi recomendación es sencilla: haz inventario.
Apunta:
- Qué proveedor gestiona tu correo principal.
- Desde dónde envías newsletters.
- Qué web o aplicaciones envían correos automáticos.
- Qué CRM o software de facturación usa tu dominio.
- Qué SMTP está configurado en WordPress.
- Qué servicios externos envían como
@tudominio.com.
Esa lista te evitará muchos problemas después.
Cómo configurar el registro SPF
El registro SPF se configura en la zona DNS del dominio. Dependiendo del proveedor, lo harás desde cPanel, Cloudflare, el panel del registrador, el panel del hosting o el gestor DNS correspondiente.
Normalmente se añade como un registro de tipo TXT.
Dónde añadir SPF en cPanel o en tu gestor DNS
Si usas cPanel, lo más habitual es entrar en una sección como:
- Zone Editor
- Editor de zonas DNS
- Zone Manager
- Email Deliverability
- Autenticación de correo
El nombre exacto puede cambiar según el proveedor, pero la lógica es la misma: tienes que editar la zona DNS del dominio y añadir o modificar un registro TXT.
Un punto importante: no debes tener varios registros SPF separados para el mismo dominio.
Este es uno de los errores más comunes. A veces una empresa tiene un SPF para el hosting, otro para Google Workspace, otro para Microsoft 365 y otro para una herramienta de marketing. Eso no es correcto. Lo recomendable es tener un único registro SPF que incluya todos los servicios autorizados.
Ejemplo de registro SPF
Un SPF básico puede tener un aspecto parecido a este:
v=spf1 include:_spf.tuproveedor.com ~allOtro ejemplo, si usas varios servicios, podría ser:
v=spf1 include:_spf.tuproveedor.com include:_spf.google.com include:spf.protection.outlook.com ~allEsto es solo un ejemplo. No debes copiarlo tal cual si no usas esos servicios.
Cada proveedor te dirá qué valor debes incluir. Por eso es importante revisar la documentación del servicio de correo, CRM, newsletter o plataforma que estés usando.
La parte final del registro también importa:
~allSuele indicar una política flexible, es decir, que los servidores no incluidos deberían tratarse como sospechosos, pero no necesariamente rechazarse de forma estricta.
También existe:
-allQue es más estricto. Puede tener sentido en configuraciones maduras, pero no conviene usarlo a ciegas si no tienes claro que todos tus servicios legítimos están bien autorizados.
Errores habituales al configurar SPF
Los errores más comunes son:
- Tener más de un registro SPF.
- Copiar un SPF genérico sin adaptarlo.
- No incluir el proveedor de email marketing.
- Olvidar el servidor que envía desde la web.
- No autorizar el CRM o el software de facturación.
- Dejar registros antiguos de proveedores que ya no se usan.
- Crear un SPF demasiado largo o con demasiados
include. - Usar
-allsin haber revisado todo antes.
En mi caso, este es uno de los puntos donde más insisto: un registro SPF mal construido puede dejar fuera servidores legítimos.
Y eso se traduce en problemas reales: correos que no llegan, formularios que caen en spam, facturas que no se entregan o mensajes importantes que pierden confianza ante los proveedores de correo.
Cómo configurar DKIM
DKIM suele configurarse desde el proveedor de correo. En muchos hostings con cPanel, puedes activarlo desde una sección relacionada con la entregabilidad de email. En otros servicios, como Google Workspace, Microsoft 365, plataformas SMTP o herramientas de email marketing, se genera una clave DKIM que después debes publicar en las DNS.
La idea es sencilla: el sistema que envía el correo firma el mensaje con una clave privada, y el dominio publica una clave pública para que el receptor pueda verificar esa firma.
Dónde activar DKIM en el proveedor de correo
En cPanel, puedes encontrar opciones como:
- Email Deliverability.
- Entregabilidad de correo.
- Autenticación de email.
- DKIM.
- Repair o reparar registros DNS.
En otros proveedores, normalmente encontrarás DKIM dentro de la configuración de dominio, autenticación del remitente o seguridad del correo.
Una vez activado, el proveedor te mostrará un registro que debes añadir a DNS. Puede ser de tipo TXT o CNAME.
El nombre del registro suele tener un selector, por ejemplo:
default._domainkey.tudominio.comO algo parecido, dependiendo del proveedor.
Cómo publicar la clave DKIM en DNS
El proveedor te dará dos datos:
- Nombre o host del registro.
- Valor del registro.
El valor suele ser una clave larga. Algo similar a:
v=DKIM1; k=rsa; p=CLAVE_PUBLICA_MUY_LARGANo hace falta memorizarla ni escribirla a mano si puedes copiarla desde el panel del proveedor. Lo importante es no cortarla, no modificarla y no añadir espacios incorrectos.
Después de publicarla, puede tardar un tiempo en propagarse. En muchos casos se verifica en minutos, pero a veces puede tardar más dependiendo del proveedor DNS.
Errores habituales al configurar DKIM
Los errores más comunes con DKIM son:
- Activarlo en el proveedor pero no publicar la clave en DNS.
- Publicar la clave en el dominio equivocado.
- Copiar el valor incompleto.
- Confundir el nombre del host.
- No configurar DKIM en servicios externos que también envían correos.
- Pensar que DKIM del hosting firma todos los correos, aunque algunos salgan por un CRM, newsletter o SMTP externo.
Este último punto es importante. Si tu web envía correos a través de un servicio externo, ese servicio también debe estar correctamente autenticado. No basta con que el buzón principal tenga DKIM si después WooCommerce, el CRM o la herramienta de email marketing envían sin firma válida.
Para mí, DKIM es una pieza clave porque ayuda a demostrar que el mensaje no ha sido alterado y que está asociado correctamente al dominio. En un entorno profesional, esa señal puede marcar la diferencia entre un correo que genera confianza y uno que parece sospechoso.
Cómo configurar DMARC sin bloquear correos legítimos
DMARC es el registro que muchas empresas dejan para el final. Y tiene sentido, porque conviene configurar primero SPF y DKIM.
Pero dejarlo olvidado tampoco es buena idea.
DMARC permite indicar qué debe hacer un servidor receptor cuando recibe un correo que dice venir de tu dominio, pero no supera correctamente las comprobaciones de autenticación.
El registro DMARC también se publica en DNS, normalmente como un TXT en:
_dmarc.tudominio.comUn ejemplo básico sería:
v=DMARC1; p=none; rua=mailto:dmarc@tudominio.comEste registro indica que la política es de monitorización y que los informes agregados se enviarán a la dirección indicada.
Por qué empezar con p=none
Mi recomendación es clara: no empieces directamente con una política agresiva si no has revisado antes todo tu ecosistema de envío.
La política p=none no bloquea mensajes. Sirve para observar.
Esto te permite detectar:
- Qué servidores envían correos usando tu dominio.
- Qué servicios están bien autenticados.
- Qué mensajes fallan SPF.
- Qué mensajes fallan DKIM.
- Qué herramientas externas no están alineadas.
- Si alguien está intentando suplantar tu dominio.
Es una fase de monitorización. No es el final del camino, pero es un primer paso muy prudente.
En empresas que usan muchos sistemas —web, CRM, facturación, newsletter, formularios, soporte— empezar con p=none ayuda a evitar sustos.
Cuándo pasar a p=quarantine o p=reject
Cuando ya has revisado los informes y has corregido errores, puedes endurecer la política.
La evolución habitual sería:
p=noneDespués:
p=quarantineY finalmente:
p=rejectp=quarantine indica a los servidores receptores que los mensajes que fallen deberían tratarse como sospechosos. Pueden acabar en spam o cuarentena.
p=reject indica que los mensajes que no pasen DMARC deberían rechazarse.
Esta última política es potente, pero hay que usarla con cabeza. Configurar un p=reject sin revisar puede bloquear correos válidos de la empresa si tienes sistemas legítimos mal autorizados.
Por eso me gusta verlo como una escalera, no como un interruptor.
Primero observas.
Luego corriges.
Después endureces.
Cómo usar los informes DMARC para detectar problemas
DMARC permite recibir informes sobre los correos que se envían en nombre de tu dominio. Estos informes pueden ser muy útiles, aunque para un usuario no técnico pueden resultar difíciles de leer directamente.
Aun así, la idea principal es muy valiosa: puedes saber quién está enviando correo como tu dominio y si esos envíos están pasando SPF, DKIM y DMARC.
Esto ayuda a detectar:
- Servicios olvidados.
- Configuraciones incompletas.
- Proveedores antiguos.
- Intentos de suplantación.
- Correos legítimos que necesitan ajustes.
- Problemas de alineación entre dominio visible y dominio autenticado.
En un negocio, esta información vale oro. No solo estás configurando un registro técnico: estás ganando visibilidad sobre cómo se usa tu dominio en el correo.
Cómo comprobar si SPF, DKIM y DMARC están bien configurados
Después de configurar los registros, toca comprobar. No basta con publicarlos y olvidarse.
La comprobación es importante porque un pequeño error en DNS puede hacer que el registro no funcione como esperas.
Comprobación desde cPanel
Si usas cPanel, revisa si tienes una sección llamada Email Deliverability o Entregabilidad de correo.
Desde ahí, algunos proveedores permiten comprobar si SPF y DKIM están correctamente configurados. En algunos casos incluso ofrecen una opción de reparación automática.
Esto puede ser muy útil cuando el dominio usa las DNS del propio hosting, porque el panel puede generar los registros adecuados.
Aun así, revisa siempre qué está haciendo el sistema. No des por hecho que todo está bien solo porque el panel muestre un botón de reparación.
Comprobación con herramientas externas
También puedes usar herramientas externas para comprobar:
- SPF.
- DKIM.
- DMARC.
- Registros DNS.
- Cabeceras de correo.
- Reputación del dominio.
- Entregabilidad.
Estas herramientas suelen pedirte el dominio y después te muestran si los registros existen, si tienen errores o si hay advertencias.
Otra forma práctica es enviar un correo de prueba a una cuenta de Gmail o similar y revisar las cabeceras del mensaje. Ahí puedes ver si SPF, DKIM y DMARC aparecen como pass o si alguno falla.
Lo ideal es que el resultado sea algo parecido a:
SPF: pass
DKIM: pass
DMARC: passSi alguno aparece como fail, softfail o neutral, conviene revisar la configuración.
Qué revisar si los correos siguen llegando a spam
Puede pasar que tengas SPF, DKIM y DMARC configurados y aun así algunos correos lleguen a spam.
Eso no significa necesariamente que los registros no sirvan. La entregabilidad depende de más factores:
- Reputación del dominio.
- Reputación de la IP.
- Contenido del mensaje.
- Enlaces incluidos.
- Historial de envíos.
- Volumen de correo.
- Quejas de usuarios.
- Listas negras.
- Configuración del servidor.
- Uso correcto del SMTP.
Aun así, SPF, DKIM y DMARC son una base imprescindible. Si fallan, partes con desventaja.
Mi forma de verlo es sencilla: no garantizan por sí solos la bandeja de entrada, pero sin ellos estás dejando señales importantes sin cubrir.
Errores comunes al configurar SPF, DKIM y DMARC
Configurar SPF, DKIM y DMARC no es especialmente complicado, pero sí requiere orden. La mayoría de problemas aparecen por improvisar.
Estos son los errores que conviene evitar.
Tener varios registros SPF
Solo debe haber un registro SPF por dominio. Si tienes varios, los servidores receptores pueden interpretar la configuración como inválida.
La solución no es crear otro SPF, sino fusionar correctamente todos los servicios autorizados en uno solo.
Copiar registros sin adaptarlos
Copiar un registro de una guía puede servir para entender la estructura, pero no para usarlo directamente.
Cada dominio tiene su propio proveedor de correo, sus herramientas externas y sus servicios de envío. Tu SPF, tu DKIM y tu DMARC deben reflejar tu caso real.
No tener en cuenta la web
Muchos problemas de entregabilidad vienen de formularios de contacto, WordPress, WooCommerce o sistemas que envían desde el servidor web.
El buzón principal puede estar perfecto, pero si la web envía mal, seguirás teniendo problemas.
Activar DKIM solo en una parte
Si usas varias plataformas de envío, revisa DKIM en cada una. No des por hecho que activar DKIM en el hosting cubre automáticamente todo.
Empezar DMARC con p=reject
Ya lo he dicho, pero merece repetirse: DMARC debe endurecerse con prudencia.
Un p=reject mal planteado puede bloquear correos legítimos. No porque DMARC sea malo, sino porque la configuración previa no estaba preparada.
No revisar informes ni resultados
Publicar DMARC y no mirar nada después es quedarse a medias.
Si vas a usar DMARC, aprovéchalo para entender qué está pasando con tu dominio.
Pensar que esto se configura una vez y ya está
El correo cambia. Hoy usas una herramienta, mañana añades un CRM, pasado conectas una newsletter y dentro de unos meses cambias de hosting.
Cada cambio puede afectar a SPF, DKIM o DMARC.
Por eso, cada vez que añadas un servicio que envíe correos en nombre de tu dominio, revisa la autenticación.
Recomendaciones para empresas que usan correo corporativo
Si usas correo corporativo con dominio propio, mi recomendación es que trates SPF, DKIM y DMARC como parte natural de la configuración inicial.
No lo dejes para cuando empiecen los problemas.
Una pyme puede depender muchísimo del correo: ventas, soporte, administración, facturación, contratos, comunicación interna y atención al cliente. Si esos mensajes no llegan bien o si alguien consigue suplantar el dominio, el daño no es solo técnico. También afecta a la confianza.
Para mí, el correo corporativo debe entenderse como una parte estratégica del negocio. No es solo una bandeja de entrada. Es una herramienta de comunicación, ventas, soporte, administración y reputación.
Mi orden recomendado sería este:
- Identifica todos los servicios que envían correo por tu dominio.
- Revisa dónde se gestionan las DNS.
- Configura un SPF limpio, sin duplicidades.
- Activa DKIM en el proveedor de correo.
- Configura DKIM también en servicios externos si los usas.
- Publica DMARC empezando con
p=none. - Analiza los resultados.
- Corrige servicios que fallen.
- Avanza progresivamente a
p=quarantineop=reject. - Revisa la configuración cada vez que añadas una nueva herramienta de envío.
También recomiendo documentarlo. Algo tan simple como una tabla con los servicios autorizados puede ahorrarte muchos dolores de cabeza.
Por ejemplo:
| Servicio | ¿Envía correos? | ¿Incluido en SPF? | ¿Tiene DKIM? | Observaciones |
|---|---|---|---|---|
| Hosting/correo principal | Sí | Sí | Sí | Buzones corporativos |
| WordPress | Sí | Revisar | Revisar | Formularios |
| WooCommerce | Sí | Revisar | Revisar | Pedidos y facturas |
| CRM | Sí | Revisar | Revisar | Emails comerciales |
| Newsletter | Sí | Revisar | Revisar | Campañas |
| Facturación | Sí | Revisar | Revisar | Envío de facturas |
Esta tabla parece básica, pero ayuda muchísimo. Sobre todo cuando varias personas o proveedores han ido tocando la configuración a lo largo del tiempo.
Sobre SPF, DKIM y DMARC
Configurar SPF, DKIM y DMARC es una de esas tareas que muchas empresas posponen porque “el correo ya funciona”. Pero esa frase puede ser engañosa.
Que un correo salga y llegue no significa que esté bien autenticado. Tampoco significa que tu dominio esté protegido frente a suplantaciones o que tus mensajes tengan todas las señales necesarias para generar confianza.
SPF indica qué servidores pueden enviar correos por tu dominio. DKIM añade una firma digital que ayuda a demostrar que el mensaje no ha sido alterado. DMARC define qué hacer cuando algo falla y permite obtener visibilidad sobre quién está enviando en tu nombre.
Los tres juntos forman una base sólida para proteger el correo corporativo.
No hacen magia. No garantizan que nunca tengas problemas de spam. No sustituyen a una buena configuración del servidor, una reputación cuidada o buenas prácticas de envío. Pero sí ayudan a mejorar la autenticación, reducir la suplantación y aumentar la confianza de los servidores receptores.
En mi opinión, cualquier empresa que use un dominio propio debería tener estos registros correctamente configurados. Y no solo por una cuestión técnica, sino por reputación.
Cuando un cliente recibe un correo de una empresa, espera que sea auténtico. Si alguien consigue suplantar el dominio para enviar facturas falsas, avisos fraudulentos o mensajes maliciosos, el daño puede ir mucho más allá del email.
Por eso merece la pena hacerlo bien: revisar todos los servicios, configurar SPF sin duplicidades, activar DKIM, publicar DMARC con prudencia y comprobar los resultados antes de endurecer la política.
El correo corporativo no es un detalle menor. Es una parte esencial de la confianza digital de cualquier negocio.
Dudas de la comunidad
¿Qué es SPF?
SPF es un registro DNS que indica qué servidores están autorizados a enviar correos en nombre de tu dominio. Ayuda a evitar que servidores no autorizados envíen emails falsificando tu dirección.
¿Qué es DKIM?
DKIM añade una firma digital al correo. Esa firma permite comprobar que el mensaje no ha sido alterado y que está asociado a un dominio autorizado.
¿Qué es DMARC?
DMARC es una política que usa SPF y DKIM para decidir qué hacer cuando un correo no supera las comprobaciones de autenticación. También permite recibir informes sobre los envíos realizados en nombre del dominio.
¿Tengo que configurar los tres registros?
Sí, lo recomendable es configurar SPF, DKIM y DMARC. Cada uno cumple una función diferente y juntos ofrecen una autenticación más completa.
¿Puedo tener más de un registro SPF?
No es recomendable. Lo correcto es tener un único registro SPF que incluya todos los servicios autorizados para enviar correos por tu dominio.
¿Qué política DMARC debo usar al principio?
Lo más prudente suele ser empezar con:
p=noneAsí puedes monitorizar sin bloquear correos legítimos. Después, cuando todo esté revisado, puedes avanzar a políticas más estrictas.
¿Cuándo conviene usar p=reject?
Conviene usar p=reject cuando ya has comprobado que todos los servicios legítimos están correctamente autenticados con SPF y/o DKIM. No es buena idea activarlo sin revisar antes.
¿Por qué mis correos llegan a spam aunque tenga SPF?
Porque SPF es solo una parte de la entregabilidad. También influyen DKIM, DMARC, reputación del dominio, IP de envío, contenido del mensaje, enlaces, historial de envíos y comportamiento de los destinatarios.
¿Dónde se configuran SPF, DKIM y DMARC?
Se configuran en la zona DNS del dominio. Puede ser desde cPanel, Cloudflare, el panel del hosting, el registrador del dominio o el proveedor DNS que estés usando.
¿Cuánto tarda en propagarse un cambio DNS?
Puede tardar desde unos minutos hasta varias horas. Depende del proveedor DNS, del TTL configurado y de la caché de los servidores.
¿SPF, DKIM y DMARC evitan todos los ataques de phishing?
No evitan todos los ataques, pero reducen el riesgo de suplantación directa del dominio y ayudan a los servidores receptores a detectar mensajes no autorizados.
¿Debo revisar SPF, DKIM y DMARC si uso WordPress?
Sí. Si WordPress envía correos mediante formularios, WooCommerce, plugins SMTP o notificaciones automáticas, conviene comprobar que esos envíos están correctamente autenticados.
