"Les mandé el presupuesto el lunes y dicen que no les ha llegado nada." Si tienes una empresa, te habrá pasado. Miras en enviados, el mensaje está ahí, la dirección es correcta, y aun así al otro lado no aparece. Está en la carpeta de spam, o peor: ni siquiera eso.
La causa casi nunca es lo que escribiste. Es que el servidor que recibe el correo no tiene forma de comprobar que lo has enviado tú, y ante la duda, lo descarta. Tres registros de tu dominio, SPF, DKIM y DMARC, son los que resuelven esa duda.
Por qué el correo es tan fácil de falsificar
El correo electrónico se diseñó en una época en la que nadie pensaba en suplantaciones. Cualquiera puede escribir facturas@tuempresa.com en el campo "De" de un mensaje, y el protocolo básico no comprueba nada. Es exactamente lo que hacen los estafadores cuando envían un falso aviso de pago con tu nombre.
Los grandes proveedores llevan años defendiéndose con filtros cada vez más estrictos. Desde 2024, Gmail y Yahoo exigen autenticación a quienes envían volúmenes altos, y Outlook.com se sumó en 2025. Aunque tú envíes cuatro correos al día, esos mismos filtros te juzgan con la misma vara: un dominio sin autenticar parte con sospecha.
SPF: quién puede enviar en tu nombre
SPF (Sender Policy Framework) es una lista de los servidores autorizados a enviar correo con tu dominio. Se publica como un registro TXT, de los que hablamos en DNS explicado sin jerga, y tiene este aspecto:
v=spf1 include:_spf.google.com include:mailing.ejemplo.com ~all
Se lee así: "pueden enviar los servidores de Google y los de este servicio de mailing; cualquier otro, desconfía". Cuando llega un mensaje, el servidor receptor consulta esa lista y comprueba si el remitente está en ella.
Los errores más habituales son dos. El primero, tener dos registros SPF en lugar de uno solo que los reúna todos: eso invalida ambos. El segundo, superar el límite de diez consultas DNS que permite el estándar, algo muy común cuando se han ido acumulando servicios (el correo, el CRM, la tienda, la herramienta de newsletters) y nadie ha limpiado la lista.
DKIM: la firma que demuestra que nadie ha tocado el mensaje
DKIM (DomainKeys Identified Mail) funciona como un sello de lacre. Tu servidor de correo firma cada mensaje con una clave privada, y tú publicas en el DNS la clave pública correspondiente. El receptor la usa para verificar dos cosas: que el mensaje viene realmente de tu dominio y que no se ha modificado por el camino.
La clave pública también va en un registro TXT, normalmente bajo un nombre como selector._domainkey.tudominio.com. Esa parte no la inventas tú: te la proporciona tu proveedor de correo o de mailing, y tú solo la copias en el DNS. Si cambias de proveedor y no actualizas este registro, los mensajes empiezan a salir sin firma válida.
DMARC: qué hacer cuando algo no cuadra
SPF y DKIM comprueban, pero ninguno de los dos dice qué debe hacer el receptor cuando la comprobación falla. Eso lo decide DMARC, otro registro TXT en _dmarc.tudominio.com. Tiene dos funciones:
Establecer una política. Hay tres niveles: p=none (solo observa, no actúa), p=quarantine (manda a spam los mensajes que no pasan) y p=reject (los rechaza). Lo razonable es empezar en none, revisar qué ocurre durante unas semanas y endurecer poco a poco.
Enviarte informes. Con la etiqueta rua=mailto:... recibes resúmenes periódicos de quién está enviando correo con tu dominio, incluidos servicios que habías olvidado y posibles suplantaciones. Son archivos XML poco amigables, pero existen herramientas gratuitas que los traducen a gráficos legibles.
Un registro de partida sencillo sería:
v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com
Cómo comprobar tu configuración en cinco minutos
Sin instalar nada, tienes dos caminos:
- Envía un correo a una dirección de Gmail y abre el mensaje. En los tres puntos, "Mostrar original": arriba verás si SPF, DKIM y DMARC aparecen como
PASSo comoFAIL. - Usa un comprobador externo como mail-tester.com o MXToolbox. Te envían una puntuación y señalan qué registro falta o está mal escrito.
Si ves un FAIL, el mensaje de error suele indicar con bastante precisión el registro culpable.
El caso típico: la web envía correos y nadie lo ha configurado
Un escenario que vemos continuamente: el formulario de contacto de la web, o los avisos automáticos de una tienda, envían correos "desde" info@tuempresa.com, pero lo hacen desde el servidor donde está alojada la web, que no figura en el SPF ni firma con DKIM. Para el receptor, es indistinguible de una suplantación.
La solución pasa por una de estas dos vías: añadir ese servidor al SPF y configurar su firma DKIM, o, mejor, enviar a través del mismo proveedor de correo que usas a diario, mediante SMTP autenticado. Es una de esas cosas que conviene dejar bien resueltas al montar una web, y que se olvidan con facilidad en una migración.
Nada de esto es difícil, pero casi nadie lo revisa hasta que un cliente dice que no le ha llegado el presupuesto. Dedica media hora a comprobar tu dominio, deja DMARC en modo observación y vuelve a mirar los informes dentro de un mes. Y si el correo es una de las piezas que cambias al migrar tu sitio, guarda antes una copia de los registros TXT: es lo que más se pierde por el camino.
