Última actualización: julio de 2026
En resumen: la «autenticación de correo» son en realidad dos capas. Una demuestra quién envió un mensaje — eso son SPF, DKIM y DMARC. La otra protege el mensaje en tránsito — eso son TLS, MTA-STS, DANE y TLS-RPT. Quieres las dos. Esta página explica cómo encajan las piezas y te lleva directo a la guía de configuración de tu proveedor.
SMTP, el protocolo que mueve el correo, se diseñó en una era de confianza mutua. No tiene ninguna forma integrada de demostrar que un remitente es quien dice ser, ni ninguna garantía integrada de que un mensaje viaje cifrado. Todo lo que hoy llamamos «autenticación de correo» es un conjunto de estándares añadidos encima para cerrar esos dos huecos. Entender qué hueco cierra cada estándar es todo el juego.
Capa uno: ¿quién envió esto? (identidad)
Tres registros, publicados en el DNS de tu dominio, permiten a un servidor receptor juzgar si un mensaje realmente vino de ti.
SPF — qué servidores pueden enviar por ti
SPF (Sender Policy Framework, RFC 7208) es un registro TXT que lista los servidores de correo autorizados a enviar con tu dominio como remitente. El valor empieza con v=spf1 y termina con una política como ~all o -all. El receptor lo consulta en cada mensaje entrante y comprueba si el servidor que entrega está en tu lista. Sin SPF, cualquiera puede poner tu dominio en el sobre «From». Es el punto de partida más fácil — mira las guías de configuración de SPF para tu proveedor.
DKIM — una firma criptográfica
DKIM (DomainKeys Identified Mail, RFC 6376) añade una firma digital a cada mensaje. Tu servidor de correo firma el correo saliente con una clave privada; la clave pública correspondiente vive en tu DNS como registro v=DKIM1 bajo un selector. El receptor verifica la firma, lo que demuestra dos cosas: el mensaje realmente pasó por tu infraestructura y no fue alterado por el camino. A diferencia de SPF, DKIM sobrevive al reenvío — la firma viaja con el mensaje.
DMARC — la política que lo une todo
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) es donde SPF y DKIM se vuelven útiles. Un registro TXT v=DMARC1 dice a los receptores qué hacer cuando un mensaje falla ambas comprobaciones — p=none (solo observar), p=quarantine (carpeta de spam) o p=reject (rechazarlo). También pide a los receptores que te envíen informes agregados, para que veas quién envía en tu nombre antes de apretar las tuercas. El camino recomendado es none → quarantine → reject, leyendo los informes en cada paso.
Los tres se construyen uno sobre otro: SPF y DKIM son las comprobaciones, DMARC es el veredicto. Profundizamos en cómo se engranan en SPF vs DKIM vs DMARC: cómo encajan entre sí.
Capa dos: ¿estuvo protegido en tránsito? (transporte)
Demostrar la identidad es solo la mitad de la historia. Un mensaje puede estar perfectamente autenticado y aun así ser leído o manipulado en la red si la conexión entre servidores no está cifrada y verificada.
TLS y STARTTLS — cifrado oportunista
Los servidores de correo modernos ofrecen STARTTLS, que eleva una conexión SMTP a una cifrada. El problema: por defecto es oportunista. Si el handshake falla, o un atacante elimina la oferta de STARTTLS, la entrega cae silenciosamente a texto plano. El cifrado ocurre cuando puede, no cuando debe. Los dos estándares siguientes convierten el «puede» en «debe».
MTA-STS — imponer TLS mediante una política HTTPS
MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) publica un archivo de política por HTTPS que dice a los servidores emisores: para mi dominio, TLS es obligatorio y el certificado debe ser válido. Eso cierra el hueco de degradación sin necesitar DNSSEC, y por eso funciona en casi cualquier proveedor. Es la opción práctica para la mayoría — lee MTA-STS en hosting compartido para saber quién puede desplegarlo y quién no.
DANE — imponer TLS mediante DNSSEC
DANE (DNS-Based Authentication of Named Entities, RFC 6698) llega a la misma meta — TLS obligatorio y autenticado — pero ancla la confianza en DNSSEC y un registro TLSA en tu MX. Es más fuerte, pero solo el operador de tu servidor de correo entrante puede desplegarlo, así que queda fuera del alcance de la mayoría de los clientes de hosting compartido. Detallamos exactamente quién cumple los requisitos en DANE para el correo: quién puede usarlo.
TLS-RPT — enterarte cuando la entrega falla
TLS-RPT (SMTP TLS Reporting, RFC 8460) es el canal de retorno. Un pequeño registro TXT que contiene TLSRPTv1 pide a los servidores emisores que te envíen informes diarios sobre cómo fue la entrega TLS a tu dominio — los éxitos y, más importante, los fallos. Uses MTA-STS o DANE, TLS-RPT es cómo te enteras de que algo se rompió, en vez de enterarte por un cliente enfadado.
La recompensa: BIMI
Una vez que DMARC está en aplicación (p=quarantine o p=reject), puedes añadir BIMI (Brand Indicators for Message Identification). Muestra tu logo junto al correo autenticado en las bandejas compatibles. BIMI no aporta nada a la seguridad por sí mismo — es la recompensa visible por haber hecho el trabajo de autenticación. Mira las guías de configuración de BIMI cuando tu DMARC esté en aplicación. El estándar lo gestiona el BIMI Group.
Cómo desplegar todo esto en la práctica
Un orden de operaciones sensato:
- SPF — publica o verifica tu registro. Un registro, una política.
- DKIM — activa la firma en tu proveedor, publica la clave pública.
- DMARC — empieza en
p=noney lee los informes durante unas semanas. - Endurece DMARC — pasa a
quarantine, luego areject, cuando los informes estén limpios. - Transporte — añade MTA-STS (o DANE si cumples los requisitos) y TLS-RPT.
- BIMI — el toque final, cuando DMARC esté en aplicación.
Cada paso tiene detalles específicos de cada proveedor. Elige tu proveedor en las guías por proveedor y sigue el paso a paso.
Verifica el resultado
El escáner MXAudit gratuito lo comprueba todo en una pasada: sintaxis de SPF y número de lookups, claves DKIM, tu política DMARC, más MTA-STS, DANE, TLS-RPT y BIMI. Es la forma más rápida de ver cuál de las dos capas tienes realmente cubierta — y dónde están los huecos.