Configuración de DKIM SPF DMARC para un dominio

Configuración de DKIM SPF DMARC para un dominio: una guía completa para la autenticación de correo electrónico

El correo electrónico sigue siendo una de las partes más vulnerables de cualquier dominio, y un sitio web puede estar bien construido y el servidor bien protegido. Si los mensajes enviados en nombre de la empresa son fáciles de falsificar, los problemas comienzan rápidamente: campañas de phishing, quejas de usuarios, pérdida de confianza y, en el peor de los casos, peor entregabilidad para tus propios correos electrónicos. Por eso Configuración de DKIM SPF DMARC para dominio no es un “pequeño detalle técnico” — es higiene básica de infraestructura de correo electrónico y una parte importante de la autenticación de correo electrónico.

Si alguna vez has tenido correos electrónicos en la carpeta de spam sin una razón obvia, o un cliente pregunta: “¿Realmente enviaste esto?” — ya es hora de trabajar en la autenticación de dominio. Y cuanto antes, mejor. En ese sentido, el correo electrónico funciona mucho como un sitio web: sin atención regular, incluso un sistema sólido comienza a comportarse de manera impredecible. A menudo hablamos de esto en el contexto de seguridad del sitio web: la protección no es un plugin o una configuración, sino un conjunto de medidas que trabajan juntas. Si te preguntas cómo configurar SPF DKIM DMARC, la clave es tratarlos como un proceso coordinado en lugar de soluciones separadas.

Qué son DKIM, SPF y DMARC y por qué son importantes

DKIM, SPF y DMARC resuelven un problema similar, pero lo hacen de diferentes maneras. Es importante no confundir sus roles si estás planeando la configuración de autenticación de correo electrónico para el dominio.

SPF responde a la pregunta: “¿Qué servidores están realmente autorizados a enviar correo en nombre de este dominio?” En DNS, publicas una lista de remitentes aprobados, y el servidor de correo del destinatario la compara con la dirección IP real de la que provino el mensaje.

DKIM añade una firma criptográfica al mensaje. El destinatario verifica si el correo electrónico fue realmente firmado por tu dominio y si fue modificado en el camino. Esto es más que solo una lista de permitidos — es prueba de la identidad del remitente y la integridad del mensaje.

DMARC une SPF y DKIM en una sola política, y le dice a los sistemas de correo qué hacer si un mensaje falla las verificaciones: entregarlo, enviarlo a cuarentena o rechazarlo de plano. DMARC también te permite recibir informes sobre quién está intentando enviar correo desde tu dominio y cómo.

Por eso, estos mecanismos no solo se trata de prevenir correos electrónicos falsificados. Afectan directamente la entregabilidad. Los servicios de correo cada vez miran no solo el contenido de un mensaje, sino también qué tan bien está configurada su autenticación. Para un dominio empresarial, esto es crítico: perder algunos mensajes es una cosa, pero terminar repetidamente en spam para clientes, socios y servicios es algo completamente diferente.

Cómo trabajan juntos DKIM SPF DMARC

Cada protocolo es útil por sí solo, pero juntos crean un sistema de verificación mucho más confiable.

SPF confirma que el mensaje provino de un servidor aprobado. Pero tiene una limitación: si el correo electrónico es reenviado, SPF puede "romperse" porque la dirección IP del último remitente cambia. DKIM a menudo ayuda en esos casos porque la firma sigue siendo válida incluso después del reenvío, siempre que el mensaje en sí no haya sido modificado.

DMARC, a su vez, verifica no solo si SPF y DKIM existen, sino si se alinean con el dominio en el campo De. Eso importa. Un mensaje puede estar técnicamente firmado, pero el usuario ve un dominio completamente diferente en el nombre del remitente, y DMARC ayuda a prevenir esa confusión y bloquea el suplantación obvia.

Para decirlo de manera simple: SPF es una lista de invitados en la entrada, DKIM es un sello en el documento, y DMARC es la regla de seguridad sobre qué hacer con los visitantes que no tienen ni un pase ni un sello. Una medida sin las otras deja un vacío.

Por eso deben implementarse juntas. Esto es especialmente importante para las empresas que utilizan múltiples fuentes de correo electrónico: sistemas CRM, servicios de boletines, plataformas de tickets, formularios de contacto, notificaciones transaccionales. Si estos no están alineados, la infraestructura de correo electrónico comienza a comportarse como una colección de islas desconectadas.

Preparándose para la configuración: dominio, DNS y servicio de correo electrónico

Antes de crear cualquier registro, necesitas entender quién envía correos en nombre del dominio. Puede ser un servicio de correo electrónico, o varios: correo corporativo, una plataforma de mailing, un sistema de notificaciones, un servicio SMTP separado para el sitio web. Sin esa información, corres el riesgo de permitir demasiado o, por el contrario, bloquear accidentalmente a un remitente necesario.

Necesitarás acceso al panel DNS del dominio. Normalmente, esa es la interfaz del registrador, tu proveedor de hosting, o un proveedor DNS separado. Es importante saber exactamente dónde se editan los registros: a veces una persona busca el problema en el servicio de correo, mientras que el registro en realidad está con otro proveedor.

Otro paso esencial es recopilar detalles del proveedor de correo electrónico. Normalmente necesitarás:

• datos SPF o un registro SPF recomendado;
• una clave DKIM o instrucciones para generar una;
• el nombre del selector DKIM, si el proveedor utiliza uno;
• recomendaciones DMARC;
• una lista de dominios y subdominios utilizados para enviar;
• una comprensión de qué servicios envían correos ahora y cuáles se agregarán más tarde.

Si no estás trabajando con un nuevo dominio, es una buena idea revisar primero la configuración actual. A veces el SPF ya existe, pero aún lista servicios antiguos. A veces el DKIM se habilitó en algún momento, pero el sistema de mailing luego se trasladó a otro proveedor. Y a veces el DMARC está presente, pero solo 'para mostrar', sin informes y sin una política significativa, y es mejor detectar estas cosas antes de hacer cambios, no después de las quejas de los usuarios.

Configurando SPF para el dominio

Un registro SPF se publica en DNS como un registro TXT. Su función es listar las fuentes de envío aprobadas. La idea básica es simple: especificas qué servicios y servidores están autorizados a enviar correos en nombre del dominio, y todo lo demás se considera no autorizado.

Al configurarlo, recuerda esto: un dominio debe tener un registro SPF. No dos, no tres, uno. Si agregas múltiples registros TXT con SPF, muchos destinatarios lo tratarán como un error. Este es uno de los problemas más comunes en el soporte de infraestructura de correo electrónico, y la configuración de autenticación de correo electrónico para el dominio es especialmente sensible a los detalles aquí.

La lógica típica de SPF se basa en mecanismos como include, ip4, ip6 y mx. En la práctica, eso significa que puedes incluir un servicio de correo de terceros, direcciones IP específicas o los servidores de correo del dominio. Pero hay un inconveniente: cada entrada adicional hace que el registro sea más largo y complejo.

Otro error común es ser demasiado amplio. A veces, las personas utilizan reglas demasiado permisivas solo para “evitar romper algo”. Como resultado, se permiten más remitentes de los necesarios. Eso es conveniente al principio, pero peor para la seguridad, y si protegerse contra mensajes falsificados es importante para ti, SPF debe ser preciso, no solo “aproximadamente correcto”.

Después de publicar el registro, verifica que sea realmente visible en DNS y coincida con tus fuentes de envío actuales. Si envías correos a través de múltiples plataformas, verifica cada una. De lo contrario, puedes terminar fácilmente en una situación donde los correos de CRM pasan, pero las notificaciones del sitio web no.

Configurando DKIM: generando una clave y publicando el registro DNS

DKIM funciona con un par de claves: la clave privada se queda con el remitente y la clave pública se publica en DNS, y cuando se envía un mensaje, el servidor lo firma con la clave privada. El destinatario toma la clave pública de DNS y verifica la firma. Si todo coincide, el mensaje se considera auténtico.

DKIM generalmente se configura a través del servicio de correo electrónico. En el panel del proveedor, seleccionas el dominio, generas una clave o recibes configuraciones listas, y luego publicas un registro TXT con la parte pública de la clave. A menudo se incluye un selector en el registro: un nombre especial que ayuda a distinguir una clave de otra. Esto es especialmente útil si el dominio tiene varios sistemas de envío o planeas rotar claves.

Después de publicar el registro DNS, necesitas habilitar la firma para los mensajes salientes en el propio servicio, y sin eso, el registro DNS es inútil: la clave estará en la zona, pero los correos electrónicos permanecerán sin firmar. Desde el punto de vista de la solución de problemas, esta es una trampa común: “El registro fue agregado, pero DKIM no funciona.” En realidad, simplemente no se habilitó la firma en el lado del remitente, así que el la configuración de autenticación de correo electrónico para el dominio permanece incompleto.

Técnicamente, es importante verificar:

• si el selector coincide entre DNS y la configuración del servicio;
• si el registro TXT se publicó correctamente;
• si la clave se cortó accidentalmente al pegarla;
• si todos los tipos de mensajes necesarios están firmados, no solo algunos de ellos;
• si el mensaje cambia después de la firma, por ejemplo, debido a un procesamiento adicional por un servicio intermedio.

DKIM es especialmente útil para correos electrónicos transaccionales: confirmaciones de registro, restablecimientos de contraseña, notificaciones de pedidos. Estos mensajes necesitan llegar de manera consistente. Si el sitio tiene una estructura bien organizada y un sólido soporte post-lanzamiento, como soporte del sitio web después del lanzamiento, la autenticación de correo electrónico suele ser una de las cosas que no se posponen “para más tarde”. Y ese es el enfoque correcto.

Configurando la política y los informes de DMARC

DMARC añade control. Sin él, puedes ver SPF y DKIM por separado, pero no tienes una regla clara sobre qué hacer con los mensajes sospechosos. Un registro DMARC también se publica en DNS como un registro TXT, generalmente bajo el subdominio _dmarc.

Al principio, muchas personas eligen una política de ninguno. Este es un modo de monitoreo: los mensajes no se bloquean, pero el propietario del dominio recibe informes y puede ver quién está enviando correo, si las verificaciones están pasando y dónde están las brechas. Es un primer paso sensato, especialmente si la infraestructura es compleja y no quieres cortar de repente mensajes legítimos.

Después de un período de monitoreo, la política puede endurecerse: la cuarentena envía mensajes sospechosos a spam o cuarentena, mientras que el rechazo los bloquea por completo. Qué opción elegir depende de cuán madura esté tu configuración de correo electrónico y cuán seguro estés de que todas las fuentes legítimas ya están contabilizadas.

En los informes de DMARC, es útil buscar no solo errores, sino también fuentes de envío inesperadas, y a veces aparecen allí servicios antiguos, plataformas de prueba o integraciones olvidadas. Esa es una buena oportunidad para limpiar las cosas.

Si estás implementando DMARC para un dominio corporativo, vale la pena verificar si procesos importantes dependen de servicios de terceros. Por ejemplo, si el sitio web utiliza activamente formularios y notificaciones por correo electrónico, y la estructura del sitio está construida de tal manera que los mensajes pasan por varios módulos, ayuda alinear cada punto de envío por adelantado. También cubrimos preguntas relacionadas en el tema de estructura del sitio web corporativo: cuanto más clara sea la arquitectura, menos sorpresas habrá a nivel de correo electrónico y más fluido será el proceso de configuración de la autenticación de correo electrónico.

Verificación y solución de problemas después de la implementación

Después de la configuración, no confíes en la sensación de que “parece funcionar”. La verificación debe ser deliberada y metódica.

Primero, asegúrate de que el registro SPF sea visible en DNS y contenga solo fuentes actuales. Luego envía un mensaje de prueba y verifica los encabezados en el lado del destinatario: generalmente muestran si SPF pasó, si hay una firma DKIM y si se activó DMARC.

Si el mensaje falla la verificación, busca la causa paso a paso:

1. ¿se han ingresado correctamente los registros DNS;
2. ¿ha pasado suficiente tiempo para la propagación de DNS;
3. ¿coincide el dominio en From con el dominio de firma;
4. ¿está el mensaje siendo firmado por el servicio que esperas;
5. ¿hay un sistema intermedio modificando el mensaje después de la firma?

Es muy útil probar no solo un mensaje, sino varios escenarios: un formulario en el sitio web, un correo electrónico de CRM, una notificación de registro, un boletín enviado a través de un servicio de marketing por correo electrónico. A veces, el problema aparece en solo un canal mientras que los otros lucen perfectos.

También vale la pena comprobar cómo se están interpretando los registros DNS. Los errores pueden ser triviales: un espacio extra, la comilla incorrecta, un selector incorrecto, múltiples registros SPF en lugar de uno. Detalles pequeños como estos pueden arruinar el resultado, incluso cuando todo parece correcto a primera vista.

Preguntas comunes y recomendaciones para mantener la configuración saludable

¿Qué debes hacer si tu servicio de correo electrónico cambia? Primero, añade el nuevo remitente a SPF, configura DKIM con el nuevo proveedor, prueba el envío y solo entonces apaga el antiguo, y no puedes simplemente “cambiar” servicios y esperar que los registros antiguos dejen de importar por sí solos. La infraestructura de correo electrónico necesita precisión, y la configuración de autenticación de correo electrónico para el dominio requiere una secuencia.

¿Qué pasa si se envían varios mensajes, y algunos provienen del sitio web mientras que otros provienen de una plataforma externa? Entonces es importante hacer una lista completa de todos los remitentes. Para un sitio web, eso podría incluir un plugin SMTP, un sistema de notificaciones, un servicio de mailing e incluso una herramienta de formulario de contacto separada. Cuanto más clara sea la lista, más fácil será mantener SPF y DMARC sin conflictos.

¿Los ajustes necesitan revisiones regulares? Sí. Especialmente si cambiaste de hosting, moviste el dominio, conectaste un nuevo CRM o actualizaste tu sistema de mailing. A veces, los registros DNS permanecen desactualizados simplemente porque nadie los recuerda. Y los registros olvidados son a menudo una fuente oculta de errores.

Si no estás seguro de que tu configuración actual de envío de correos electrónicos sea transparente, tiene sentido mirarlo en su conjunto: quién envía, quién firma, dónde se almacenan los registros y quién es responsable de los cambios. En proyectos más complejos, esto se convierte en parte del soporte general y la arquitectura técnica, no en una “tarea de TI” de cinco minutos.

Y un consejo práctico más: no te apresures a habilitar una política de rechazo estricta si el dominio es antiguo y tiene muchos remitentes no relacionados. Primero recopila los datos, activa los informes, elimina lo innecesario y solo entonces ajusta gradualmente la política, y en la autenticación de correo electrónico, apresurarse casi siempre conduce a bloquear el correo que realmente necesitas.

Si deseas un dominio que no solo se vea bien en la barra de direcciones, sino que también pase las verificaciones de correo con confianza, SPF, DKIM y DMARC deben ser tratados como una parte obligatoria del proyecto. Esta no es una medida decorativa: es una forma de proteger tu marca, construir confianza y hacer que la entrega de correos electrónicos sea predecible. Y la previsibilidad, como muestra la práctica, vale más que cualquier configuración llamativa pero frágil.