Guía práctica de autenticación del correo electrónico

Tu dominio envía correo aunque no seas tú quien escribe los mensajes: newsletters, facturas, avisos del CRM, restablecimientos de contraseña. La seguridad del correo en el DNS es el conjunto de ajustes públicos que indican al mundo qué servidores pueden enviar correo en tu nombre y si un mensaje viene de verdad de tu organización. Los grandes proveedores de correo ya tratan una autenticación débil o inexistente como un problema de entrega, no como un extra opcional.

Qué te juegas si lo ignoras: las facturas acaban en la carpeta de spam de tus clientes, Gmail frena o bloquea tus campañas de marketing y cualquiera puede falsificar un correo de tu director general a tu equipo de finanzas sin tener acceso a nada de tu infraestructura. Es la suplantación (spoofing). Configura bien la autenticación una vez y la mayoría de estos problemas desaparecen.

Qué te llevas de esta guía: definiciones en lenguaje claro (dominio raíz, selector DKIM, alineación DMARC), una lista de lo que debes reunir antes de tocar el DNS, un orden de despliegue seguro y formas concretas de comprobarlo, sin memorizar números de RFC. Coordinar el acceso al registrador y a los proveedores también es trabajo de gobernanza: se parece a alinear equipos cuando la fiabilidad importa (DevOps y cómo romper los silos, en inglés).

En resumen

• SPF declara quién puede enviar correo en nombre de tu dominio.
• DKIM firma criptográficamente tu correo saliente para que los receptores puedan verificar que nadie lo ha alterado.
• DMARC vincula SPF y DKIM a la dirección «De» visible e indica a los receptores qué hacer cuando no coinciden.
• Empieza DMARC en modo de supervisión (p=none), corrige los orígenes que fallan en los informes y después pasa a quarantine y, por último, a reject.
• Compruébalo con herramientas online gratuitas o con Comprobar el correo, la herramienta gratuita de esta web: sin abrir el terminal.
• Hoy: envía la plantilla de petición de más abajo a quien controle tu DNS y confirma que los informes agregados de DMARC empiezan a llegar en una semana.

Haz clic para ampliar

Por qué «sin autenticación, mala entrega» se ha vuelto lo normal

Los proveedores de correo filtran un volumen enorme de abusos. Para proteger a sus usuarios, cada vez esperan más que los remitentes demuestren su identidad con la seguridad del correo en el DNS, en lugar de fiarse solo de la línea «De».

Google publica en su Centro de Ayuda lo que espera de los remitentes masivos para los administradores de Workspace, incluidas la autenticación y la responsabilidad sobre la tasa de spam^{[1]Google Workspace Admin Help. «Email sender guidelines». Consultado en 2026.}. Yahoo ofrece pautas parecidas en su portal de buenas prácticas para remitentes^{[1]Yahoo Inc. Yahoo Sending Guidelines (best practices).}.

La lección práctica para quien no es técnico es más sencilla que esas páginas de políticas: si tus registros DNS no coinciden con cómo envías el correo de verdad, tus campañas legítimas pueden acabar en spam (o rebotar) mientras los suplantadores siguen aprovechando los huecos.

Modelo mental: el DNS como el tablón de anuncios de la entrada de tu edificio

Piensa en el DNS como un tablón de anuncios público asociado a tu nombre de dominio. Cualquiera en internet puede leerlo; solo quien tiene acceso al registrador puede cambiarlo. Los protocolos de autenticación del correo son avisos colgados en ese tablón:

• SPF responde: «¿Qué direcciones IP y qué proveedores pueden enviar correo en nombre de nuestro dominio?»
• DKIM responde: «Aquí tienes una clave pública: los mensajes firmados con nuestra clave privada demuestran que nadie los ha alterado por el camino».
• DMARC responde: «Si SPF o DKIM no están alineados con el dominio visible del remitente, esto es lo que deben hacer los receptores; y enviadnos informes».

Tres términos en lenguaje claro que oirás en los paneles de DNS:

• Dominio raíz: tu dominio sin más (example.com), no un subdominio como mail.example.com. El SPF del correo saliente suele estar aquí, en un registro TXT (a menudo marcado como @).
• Selector DKIM: una etiqueta que elige tu proveedor de correo para poder rotar las claves; en el DNS se publica your-selector._domainkey.example.com.
• Alineación: los receptores comprueban que el dominio que ha superado SPF o DKIM coincide (o está relacionado) con el dominio que el destinatario ve en el campo «De»; si no, DMARC puede fallar aunque SPF y DKIM pasen por separado^{[1]IETF. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).}.

Juntos, estos registros cierran el agujero que permitiría a un estafador falsificar CEO@yourcompany.com sin tener acceso a tu infraestructura.

SPF (Sender Policy Framework)

SPF vive en un único registro TXT en el dominio raíz (a menudo @ en los paneles de DNS). Enumera los remitentes autorizados (tu servidor de correo, Microsoft 365, Google Workspace, Mailchimp, etc.), muchas veces mediante punteros include: a registros que gestiona cada proveedor.

Lo que debes saber sin memorizar la sintaxis:

• Exactamente un registro TXT de SPF en el dominio raíz. Si hay varias cadenas SPF, los receptores devuelven un error en la evaluación SPF^{[1]IETF. RFC 7208: Sender Policy Framework (SPF). Secciones 4.5 y 4.6 (registros múltiples y evaluación).}.
• Termina en -all (rechazo estricto, hard fail) o ~all (rechazo suave, soft fail) cuando confíes en tu inventario de remitentes. Durante una migración, los proveedores suelen recomendar un trato más suave hasta que los informes demuestren que todo está cubierto.

Qué hacer si no eres técnico: exporta tu cadena SPF del DNS y escribe a cada proveedor que envía en nombre de tu dominio (marketing, facturación, soporte) para confirmar que aparece en la lista.

Cuándo llamar a un especialista (SPF PermError)

Si usas muchas herramientas SaaS, a veces se supera el límite de consultas DNS que SPF permite durante la evaluación^{[1]IETF. RFC 7208, sección 4.6.4 (límites durante la evaluación SPF).}. Un síntoma típico son caídas misteriosas en la entrega después de añadir otro proveedor. Arreglarlo suele significar concentrar el correo saliente en menos servidores de envío o aplanar los include, y no es algo para hacer a ciegas en producción.

DKIM (DomainKeys Identified Mail)

DKIM añade una firma digital en las cabeceras del correo saliente. Los receptores obtienen tu clave pública del DNS a través de un registro de selector como selector1._domainkey.example.com.

Por qué a los receptores les gusta DKIM:

• Aguanta el reenvío. SPF suele romperse cuando el correo pasa por listas de distribución o reenvíos, porque cambia el servidor que se conecta; la firma puede sobrevivir a esos caminos si llega intacta.
• Delata las manipulaciones. Si se altera el cuerpo o alguna cabecera firmada, la firma normalmente deja de ser válida.

Sigue las indicaciones de tu proveedor sobre la longitud y la rotación de las claves; Google Workspace recomienda claves de 2048 bits al generar las claves DKIM^{[1]Google Workspace Admin Help. «Authenticate mail with DKIM». Consultado en 2026.}. El protocolo se define en el RFC 6376^{[1]IETF. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.}.

Qué hacer si no eres técnico: pide a tu informático o a tu proveedor SaaS el nombre del selector y el TXT que debe haber en el DNS, y comprueba que ese TXT existe. Si marketing usa otra plataforma, puede que publique un selector distinto: apúntalos todos en tu hoja de cálculo.

Vigila los selectores olvidados. Si cambias de plataforma de envío (ESP) y no borras el selector antiguo, DKIM sigue «pasando» a través de una infraestructura que ya no controlas. Rota las claves más o menos una vez al año y elimina del DNS los selectores en cuanto des de baja el servicio que los usaba.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Publica DMARC como registro TXT en _dmarc.example.com. Contiene la política (p=), las direcciones para los informes agregados (rua=) y los requisitos de alineación que hemos resumido antes^{[1]IETF. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).}.

Etiquetas de política que verás:

Los informes agregados RUA resumen en adjuntos XML los intentos de envío de todo el mundo^{[1]IETF. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).}. Envíalos a un buzón que alguien vigile o a un proveedor: durante el despliegue, alguien tiene que revisarlos cada semana.

Trata los paneles de DMARC como indicadores clave de la operación: destapan los envíos de herramientas que nadie controla (shadow IT) mucho antes de que marketing se acuerde de aquella integración SaaS abandonada.

Antes de tocar el DNS: reúne esto en un solo sitio

Ahora que tienes claros los tres protocolos, haz inventario antes de tocar el DNS. Usa una fila de la hoja de cálculo por proveedor u origen de correo:

• Quién gestiona el DNS del dominio (el registrador, Cloudflare o tu proveedor de servicios gestionados).
• Dónde están los buzones (Google Workspace, Microsoft 365, Fastmail, etc.).
• Cada sistema que envía en nombre de tu dominio (CRM, facturación, plataforma de email marketing, alertas).
• Los selectores DKIM que cada proveedor espera que publiques (consulta su documentación de soporte o pregunta a tu informático).
• Adónde deben llegar los informes agregados de DMARC (rua): un buzón al que solo tengan acceso quienes los analizan.
• Una captura de pantalla o una exportación del TXT de SPF actual del dominio raíz antes de editarlo.

Mensaje inicial para tu informático o tu proveedor de DNS

El objetivo de este mensaje es abrir una conversación, no darle a tu informático una lista de tareas. Tu equipo técnico o tu proveedor ya conocen los detalles técnicos; lo que necesitan de ti es contexto (por qué ahora), permiso (quieres que sea una prioridad) y una invitación a que decidan ellos el orden técnico. Úsalo como mensaje inicial y deja que lo lleven ellos a partir de ahí:

Asunto: Revisión de la autenticación del correo de example.com: ¿qué opinas?

Hola, [nombre]:

Me gustaría revisar cómo está configurada la autenticación del correo
de nuestro dominio. El motivo: [elige lo que encaje: las newsletters
acaban en spam, vamos a añadir una nueva plataforma de envío, nos han
hablado de los requisitos de Google/Yahoo para remitentes masivos,
o simplemente queremos partir de una base limpia antes de la próxima
campaña importante].

¿Podrías pasarme lo siguiente?

1. El estado actual de nuestros registros SPF, DKIM y DMARC (me sirve
   una captura o una copia de lo que hay publicado).
2. Qué herramientas envían hoy correo en nombre de nuestro dominio:
   Workspace/M365, nuestras plataformas de envío de marketing y
   transaccional, el CRM, la facturación o cualquier otra.
3. Tu opinión sobre si hay algo que no está bien y qué próximos pasos
   recomendarías.

Mi objetivo es que el correo legítimo se autentique sin problemas y
avanzar hacia una política DMARC más estricta en cuanto sepamos quién
envía en nuestro nombre. Me fío de tu criterio en cuanto al orden y
los plazos.

¡Gracias!

Resiste la tentación de añadir a este mensaje v=DMARC1, p=none|quarantine|reject o valores concretos de registros, aunque acabes de leer sobre ellos. Si los incluyes, parecerá que los has copiado de un artículo o que cuestionas lo que sabe tu informático. Mantén la petición en el terreno de la intención y la visibilidad; deja que quienes tienen acceso de administrador propongan las respuestas técnicas.

Orden de despliegue seguro (no te saltes pasos)

• Observa: publica DMARC con p=none y recoge los informes rua.
• Haz inventario: apunta cada remitente autorizado, su selector DKIM y los include de SPF.
• Corrige los fallos: ajusta SPF y DKIM hasta que el correo legítimo los supere de forma estable.
• Sube la política: pasa a quarantine, si quieres con pct= para aplicarla de forma escalonada cuando el receptor lo admita. pct=20 aplica tu política al 20 % del correo que falla: es útil para endurecerla de forma controlada antes de llegar al 100 %.
• Rechaza: solo cuando las herramientas muestren tasas de aprobados altas y sostenidas, y los responsables acepten los riesgos.

Haz los cambios en el DNS poco a poco: baja los TTL durante las migraciones si tu proveedor de DNS lo permite y vuelve a subirlos después.

Seguridad del transporte: MTA-STS y TLS-RPT (cuando el cifrado no puede desactivarse sin avisar)

La autenticación demuestra la identidad del remitente; la seguridad del transporte protege los mensajes entre servidores. El TLS oportunista puede acabar enviando sin cifrar si alguien bloquea el intento de cifrado.

MTA-STS te permite anunciar «solo saltos cifrados hacia servidores MX con identidad verificada». Publicas un TXT de referencia en _mta-sts.example.com y alojas un pequeño archivo de política por HTTPS en mta-sts.example.com^{[1]IETF. RFC 8461: SMTP MTA Strict Transport Security (MTA-STS).}.

TLS-RPT añade informes agregados cuando falla la negociación TLS^{[1]IETF. RFC 8460: SMTP TLS Reporting.}.

Qué hacer si no eres técnico: confirma con tu equipo técnico si MTA-STS tiene sentido antes de activar el modo enforce, porque una lista de MX mal configurada puede cortar el correo durante las pruebas.

Una mejora rápida y gratuita: CAA

Un registro CAA limita qué autoridades de certificación pueden emitir certificados TLS para tu dominio. Publicarlo es un cambio de cinco minutos sin riesgo operativo si incluyes las autoridades que usas de verdad, y reduce bastante la probabilidad de que alguien emita por error o con fraude un certificado a tu nombre^{[1]IETF. RFC 8659: DNS Certification Authority Authorization (CAA).}.

Pide a tu informático que publique un registro CAA con las autoridades de certificación que usas hoy (p. ej., letsencrypt.org, digicert.com). En la mayoría de dominios basta con confirmar con qué autoridad se hacen las renovaciones.

Temas avanzados (DNSSEC, DANE, BIMI)

Lo primero, para la mayoría de las organizaciones, es dejar bien resueltos SPF, DKIM y DMARC. Considera todo lo que sigue avanzado y consulta a especialistas en DNS o seguridad antes de activar nada.

Si estas filas te suenan a chino, no pasa nada: guárdalas para tu interlocutor técnico.

Compruébalo sin abrir el terminal

Tres opciones gratuitas y fiables para revisar tus registros DNS y los resultados de autenticación:

• Comprobar el correo, la herramienta gratuita de esta web: hace las mismas comprobaciones de SPF, DKIM, DMARC, MX, MTA-STS y TLS-RPT que la línea de comandos, en tu navegador. Sin instalar nada y sin registro.
• MXToolbox: una herramienta veterana de consulta de TXT y MX, con un informe centrado en la entrega.
• Google Postmaster Tools: si envías un volumen significativo a Gmail, es la referencia fiable de cómo ve Google tu dominio.

Después de publicar los registros, envía un mensaje de prueba desde cada plataforma de envío a una cuenta personal de Gmail o de Outlook y lee los resultados de autenticación (el nombre exacto de los menús puede variar según el idioma y la versión):

• Gmail: abre el mensaje, haz clic en el menú de los tres puntos → Mostrar original y busca spf=pass, dkim=pass y dmarc=pass en el bloque Authentication-Results.
• Outlook (web o escritorio): abre el mensaje → … → Ver → Ver origen del mensaje (o Archivo → Propiedades → Encabezados de Internet) y busca las mismas líneas Authentication-Results.

Las herramientas comerciales de DMARC (dmarcian, Postmark DMARC Digests, Valimail, etc.) convierten los informes XML en paneles y van más allá, pero a pequeña escala son opcionales.

Uses la herramienta que uses, recuerda que solo lee registros MX y TXT públicos: por sí sola no demuestra que el correo llegue a la bandeja de entrada ni que esté alineado. Los Authentication-Results de un mensaje de prueba real son la prueba definitiva.

Problemas que conviene mencionar al hablar con proveedores

• Varias cadenas TXT de SPF en el dominio raíz: hay que fusionarlas en un único registro^{[1]IETF. RFC 7208: Sender Policy Framework (SPF). Secciones 4.5 y 4.6 (registros múltiples y evaluación).}.
• Marketing en un subdominio sin alineación: a veces se resuelve con DMARC o DKIM específicos para el subdominio, en lugar de forzar a ciegas la alineación con el dominio principal.
• Un remitente SaaS olvidado tras cancelar un contrato: quita sus include del SPF cuando un proveedor se vaya.

Conclusión

La seguridad del correo en el DNS es gobernanza del dominio, no una casilla que se marca una vez. SPF enumera las vías de envío autorizadas, DKIM demuestra la integridad, DMARC vincula la identidad con la política, y los proveedores de correo exigen cada vez más una autenticación coordinada, tanto para el correo masivo como para el transaccional^{[1]Google Workspace Admin Help. «Email sender guidelines». Consultado en 2026.}.

Esta semana, haz estas tres cosas:

• Envía la plantilla de petición de más arriba a quien controle tu DNS y pide los valores actuales antes de cambiar nada.
• Publica (o confirma) DMARC en _dmarc.example.com con p=none y un buzón rua= que funcione.
• Lee tu primer informe agregado e identifica los uno o dos remitentes con más fallos de alineación.

Endurece la política solo cuando los informes se vean estables. Para revisar ahora mismo tus registros, usa Comprobar el correo, gratis; si quieres ayuda para interpretar fallos raros, escríbeme desde la página de contacto.