Seguridad del correo electrónico: SPF, DKIM, DMARC, BIMI y ARC explicados

Publicada y revisada el 29 de septiembre de 2026. Incluye RFC 9989 (DMARCbis, mayo de 2026) y la propuesta del IETF para retirar ARC.

El correo electrónico se diseñó en los años ochenta para una red pequeña en la que todos se conocían. El protocolo que lo transporta, SMTP, no comprueba quién eres: cualquiera puede escribir en el remitente el dominio que quiera. Todo lo que hoy protege un dominio frente a la suplantación se añadió después, por encima, y por eso conviene entender primero cómo viaja un mensaje.

En las revisiones que hago, los problemas rara vez vienen de no conocer los acrónimos. Vienen de una plataforma de marketing que nadie autenticó, de un SPF que pasó de las diez consultas sin que nadie lo notara o de un DMARC en p=none desde hace años. Esta guía explica por qué ocurre cada cosa para que puedas decidir con criterio.

Cómo viaja un correo, de tu teclado a la bandeja de entrada

Un mensaje pasa por al menos cuatro programas distintos. Cada uno tiene un nombre y un papel. Merece la pena conocerlos, porque las cabeceras de un correo, los paneles de administración y los propios RFC hablan en esos términos.

En Microsoft 365 o Google Workspace, el MSA, el MTA y el MDA forman parte de la misma plataforma, pero las cabeceras Received siguen dejando rastro de cada salto interno. Un servidor puede actuar también como relay: acepta correo de otro servidor para reenviarlo. Si acepta el de cualquiera sin autenticar, es un open relay, uno de los errores clásicos que acaban en listas negras.

El registro MX es la pieza que conecta los dos mundos: publica qué servidores reciben el correo de un dominio y con qué preferencia (el número más bajo se prueba primero). Un dominio que no recibe correo puede decirlo con un MX nulo, 0 ., definido en RFC 7505.

La conversación SMTP y por qué cualquiera puede escribir tu dominio

Cuando un servidor entrega un correo a otro, mantienen una conversación de texto bastante legible. Esta es, resumida, la que tiene lugar cuando empresa.es envía una factura a destino.es:

Nada en esta conversación obliga a que MAIL FROM y From coincidan, ni a que ninguno de los dos pertenezca a quien se conecta. Es lo que permite la suplantación y, a la vez, lo que hace posibles usos legítimos: una plataforma de envío pone su propio sobre en un correo con tu From, y un reenvío conserva tu remitente aunque salga de otro servidor. SPF, DKIM y DMARC existen para distinguir un caso del otro.

El sobre y la carta: las identidades de un correo

La comparación con el correo postal funciona bien. El sobre lleva la dirección a la que devolver la carta si no se puede entregar; la carta, dentro, lleva la firma y el remitente que lee el destinatario. En un correo electrónico hay cuatro identidades distintas, y cada protocolo valida una:

Hay una quinta identidad que nadie valida: el nombre visible («Banco Ejemplo» o «Dirección General»). Por eso el phishing lo usa tanto, y por eso DMARC, aun bien configurado, no sustituye a la formación ni a los avisos de remitente externo.

Prueba tú: seis correos, seis desenlaces

Elige un escenario y mira qué comprueba el servidor del destinatario en cada paso. Todos suponen que empresa.es publica SPF, DKIM y DMARC con p=reject.

SPF: la lista de servidores autorizados

SPF (Sender Policy Framework, RFC 7208) es un registro TXT en el DNS de tu dominio que enumera qué servidores pueden enviar correo en su nombre. El servidor que recibe un mensaje compara la IP que se le ha conectado con esa lista, usando el dominio del sobre (MAIL FROM). Si la IP está autorizada, SPF da pass.

Cómo lo evalúa el receptor

1. Toma el dominio del MAIL FROM. Si el sobre va vacío, como ocurre en los avisos de rebote, usa el del saludo HELO.
2. Busca en ese dominio un TXT que empiece por v=spf1. Si encuentra dos, el resultado es un error permanente.
3. Recorre los mecanismos de izquierda a derecha hasta que uno coincide con la IP.
4. El calificador de ese mecanismo decide el resultado: + pass (el valor por defecto), - fail, ~ softfail y ? neutral.

v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:_spf.mlsend.com ~all

El límite de las diez consultas DNS

Para que evaluar SPF no sobrecargue el DNS, RFC 7208 limita a diez los términos que obligan a hacer consultas: include, a, mx, ptr, exists y redirect, contando también los que hay dentro de cada include. Si una evaluación necesita más, el resultado es permerror. Además, recomienda no pasar de dos consultas vacías: nombres que no existen o que no devuelven nada.

Es el error que más veo en empresas que han ido sumando proveedores. Cada plataforma pide su include y nadie mira la suma. Lo engañoso es que el correo no falla siempre: el receptor deja de contar cuando encuentra una coincidencia, así que los mensajes que salen por los primeros include pasan y los que salen por los últimos dan error.

Cómo bajar de diez, de lo más limpio a lo más delicado:

• Quita los include de servicios que ya no usas. Es lo más habitual y lo más fácil.
• Sustituye a y mx por ip4: e ip6: cuando las direcciones sean tuyas y estables.
• No añadas el include de plataformas que alinean por su cuenta: Mailchimp, Brevo, Acumbamail, SendGrid con Automated Security o Amazon SES usan su propio sobre, y ese include no aporta nada a DMARC.
• Envía el marketing desde un subdominio (news.empresa.es) con su propio SPF. Además separas la reputación del correo comercial de la del correo de las personas.
• Usa servicios de «aplanado» que sustituyen los include por IP. Funcionan, pero si el proveedor cambia sus rangos y el servicio no se actualiza a tiempo, tu correo falla.

Lo que SPF no hace

SPF no protege el From que ve la persona: valida el sobre, y un atacante puede poner su propio dominio en el sobre y el tuyo en la carta. Tampoco sobrevive a los reenvíos, porque el mensaje llega desde la IP del reenviador, que no está en tu lista. Y no firma el contenido. Por eso, por sí solo, sirve de poco; su valor aparece cuando DMARC exige que el dominio del sobre coincida con el del From.

El riesgo de autorizar infraestructura compartida

Cuando incluyes el SPF de un proveedor, autorizas todas las IP que ese proveedor publica, también las que usan sus otros clientes. En 2024, el estudio BreakSPF, presentado en el congreso NDSS, encontró 23.916 dominios cuyo SPF autorizaba rangos de nubes, proxies y CDN compartidos, 23 de ellos entre los mil más visitados de Internet, y demostró que se podía enviar correo suplantado que pasaba SPF y DMARC. La lección práctica es doble: revisa los rangos amplios de tu SPF y haz que DMARC se apoye en DKIM, que no depende de la IP.

~all o -all

Durante años se recomendó -all como la opción «segura». Con DMARC aplicado, el matiz importa: algunos receptores rechazan por SPF al principio de la conexión, antes de leer el mensaje, y un reenvío que habría pasado gracias a DKIM se pierde sin aparecer en tus informes. RFC 9989 describe exactamente ese efecto, y Google recomienda ~all. Mi criterio: ~all en dominios que envían correo con DMARC aplicado; -all en dominios que no envían nada.

DKIM: la firma que viaja con el mensaje

DKIM (DomainKeys Identified Mail, RFC 6376) es una firma criptográfica que el servidor de salida añade a cada mensaje en la cabecera DKIM-Signature. El receptor busca la clave pública en el DNS del dominio firmante y comprueba que las cabeceras y el cuerpo no han cambiado desde que se firmaron. A diferencia de SPF, DKIM sobrevive a los reenvíos, porque la firma va dentro del mensaje.

Claves: longitud, selectores y rotación

RFC 8301 fija un mínimo de 1024 bits para las claves RSA y recomienda 2048, que es lo que hoy generan Google Workspace, SendGrid o Amazon SES. Microsoft 365 todavía crea claves de 1024 bits por defecto, aunque permite rotarlas a 2048. Las claves de 4096 bits no caben en una sola cadena TXT y algunos paneles DNS las cortan: no aportan nada práctico. Ed25519 (RFC 8463) produce firmas cortas y robustas, pero aún hay verificadores que no la reconocen, así que se usa como segunda firma junto a una RSA.

El selector permite tener varias claves a la vez: una por proveedor y dos por proveedor cuando rotan. M3AAWG, la asociación del sector contra el abuso, recomienda rotar las claves DKIM al menos cada seis meses. Microsoft 365 publica selector1 y selector2 precisamente para cambiar de uno a otro sin tocar tu DNS.

Un detalle que confunde a mucha gente: DKIM no permite listar los selectores de un dominio. Solo se puede preguntar por nombres concretos. Por eso cualquier comprobador «adivina» con una lista de selectores habituales, y por eso la forma segura de conocer el tuyo es mirar el s= de la cabecera DKIM-Signature de un correo que hayas enviado.

Qué rompe una firma DKIM

• Las listas de correo que añaden una etiqueta al asunto ([Lista]) o un pie al final del mensaje.
• Las pasarelas de seguridad que reescriben enlaces o añaden avisos de «remitente externo» antes de reenviar.
• Los servidores intermedios que reformatean el mensaje, sobre todo con canonicalización simple.
• Una clave publicada mal: partida en dos registros, con comillas de más o truncada por el panel DNS.

Reutilización de firmas (DKIM replay)

Una firma DKIM válida lo sigue siendo mientras no cambien las partes firmadas. Los atacantes lo aprovechan: consiguen que tu plataforma firme un mensaje inofensivo y lo reenvían a miles de destinatarios, con tu dominio autenticado. Las defensas están en el lado del emisor: firmar dos veces From, To, Subject y Date (oversigning) para que no se puedan añadir cabeceras, poner una caducidad corta con x= y no firmar contenido que otras personas puedan controlar, como formularios que envían copias a direcciones arbitrarias.

DMARC: la política que une SPF y DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 9989) es un registro TXT en _dmarc.tudominio que exige que SPF o DKIM validen un dominio alineado con el del From, dice qué hacer con el correo que no lo consiga y pide informes a los receptores. Es la pieza que convierte a SPF y DKIM en protección real contra la suplantación del remitente visible.

La alineación, que es donde todo se decide

Un mensaje pasa DMARC si al menos una de estas dos condiciones se cumple:

• SPF da pass y el dominio del sobre está alineado con el del From.
• DKIM da pass y el dominio d= de la firma está alineado con el del From.

«Alineado» tiene dos modos. En modo relajado, el que se usa por defecto, basta con que ambos dominios compartan el mismo dominio organizativo: news.empresa.es y empresa.es están alineados. En modo estricto (adkim=s, aspf=s) tienen que ser idénticos.

El tercer caso es el que más sorprende en las auditorías: SPF y DKIM dan pass en las cabeceras y, aun así, el correo falla DMARC. Pasan para el dominio de la plataforma, no para el tuyo.

La política: none, quarantine o reject

Las etiquetas del registro

v=DMARC1; p=quarantine; np=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Los informes: tu mapa de quién envía con tu dominio

Con rua, los grandes receptores te envían cada día un informe agregado en XML, normalmente comprimido. No incluye el contenido de los correos: dice qué IP enviaron mensajes con tu dominio, cuántos, qué resultado dieron SPF y DKIM y qué hizo el receptor. Es la única forma fiable de descubrir la plataforma de encuestas que alguien de marketing contrató hace dos años.

Los informes de fallo (ruf) contienen datos de mensajes concretos. Por privacidad, la mayoría de los grandes proveedores no los envían, así que no cuentes con ellos.

Si los informes van a otro dominio, por ejemplo a un servicio especializado, ese dominio tiene que autorizarlo publicando empresa.es._report._dmarc.servicio.com con v=DMARC1 (RFC 9990). Los servicios lo hacen solos; si montas tu propio buzón en otro dominio, es un paso que se olvida a menudo. Puedes leer tus XML sin subirlos a ningún sitio en la pestaña de informes de la herramienta.

Subdominios y dominio organizativo

Si un correo usa facturas.empresa.es y ese subdominio no tiene registro DMARC propio, el receptor sube por el árbol DNS hasta encontrar el del dominio organizativo y aplica su etiqueta sp, o np si el subdominio ni siquiera existe. RFC 9989 sustituyó la lista de sufijos públicos que se usaba antes por un recorrido del DNS, con un máximo de ocho consultas:

La etiqueta np=reject es de las mejores inversiones que puedes hacer: bloquea que alguien invente soporte-seguridad.empresa.es para suplantarte, sin afectar a ningún subdominio real.

¿Siempre hay que llegar a p=reject?

La mayoría de las guías dan por hecho que sí. RFC 9989 matiza. Pide pasar por p=none al menos un mes y por p=quarantine otro tanto antes de rechazar; exige que quien publica p=reject firme con DKIM, porque SPF no sobrevive a los reenvíos; y desaconseja p=reject en dominios cuyos usuarios escriben a listas de correo, porque sus mensajes rebotan en los suscriptores y la lista acaba dándolos de baja. También pide a los receptores que no rechacen solo por la política.

Los grandes buzones son un buen termómetro. Así estaban sus propios registros el 29 de septiembre de 2026:

Mi recomendación práctica: p=reject para dominios y subdominios que solo envían correo automatizado (facturas, notificaciones, marketing) y para los que no envían; p=quarantine como destino razonable del dominio principal cuando la plantilla participa en listas externas, salvo que aceptes ese coste a cambio de la protección extra.

Lo que DMARC no protege

• Dominios parecidos: empresa-es.com o ernpresa.es son de otra persona, que puede autenticarlos perfectamente. Se combate vigilando registros de dominios, con BIMI y con formación.
• El nombre visible: «Empresa <[email protected]>» pasa DMARC para gmail.com.
• Cuentas comprometidas: si roban el buzón de alguien de tu empresa, sus correos pasan DMARC, porque son legítimos a efectos técnicos.
• El contenido: DMARC dice quién envía, no si el mensaje es de fiar.

Qué cambia con DMARCbis (RFC 9989)

En mayo de 2026 el IETF publicó RFC 9989, conocido durante años como DMARCbis, junto con RFC 9990 (informes agregados) y RFC 9991 (informes de fallo). Sustituyen a RFC 7489, de 2015, y convierten DMARC en estándar del IETF. Tu registro v=DMARC1 sigue funcionando; estos son los cambios que importan:

Qué conviene hacer: quitar pct (con 100 es inofensivo; con otro valor, cada receptor lo interpreta a su manera), añadir np=reject y, si publicas registros en subdominios con estructuras complejas, revisar que el recorrido DNS encuentra el dominio organizativo que esperas.

ARC: la cadena de custodia de los reenvíos, y su relevo

ARC (Authenticated Received Chain, RFC 8617) permite que un intermediario —una lista de correo, un reenviador, una pasarela— certifique qué resultados de autenticación tenía el mensaje cuando llegó a sus manos. Así, el receptor final puede aceptar un correo que falla DMARC por culpa del intermediario si confía en quien lo selló.

Cada intermediario añade un juego de tres cabeceras numeradas con i=:

• ARC-Authentication-Results: lo que comprobó al recibirlo (SPF, DKIM, DMARC).
• ARC-Message-Signature: una firma del mensaje tal y como lo reenvía, parecida a DKIM.
• ARC-Seal: una firma de la cadena, con cv= indicando si la cadena anterior era válida (none en el primer eslabón).

Gmail, Microsoft 365 y Yahoo usan ARC. En Microsoft 365 puedes declarar tus pasarelas o servicios de terceros como trusted ARC sealers, y el código compauth 130 en las cabeceras indica que un sello ARC de confianza anuló un fallo de DMARC.

El experimento, sin embargo, se acaba. En abril de 2026 el grupo de trabajo DMARC del IETF publicó un borrador que propone reclasificar RFC 8617 como Historic, porque ARC no consiguió un modelo de confianza útil entre desconocidos. Su sucesor es DKIM2, que se trabaja en el grupo DKIM del IETF (borrador draft-ietf-dkim-dkim2-spec): cada servidor que toca el mensaje añade su firma, formando una cadena verificable de quién lo manejó. Mientras DKIM2 no esté desplegado, ARC seguirá funcionando en los grandes proveedores; si administras una lista, un reenviador o una pasarela, sigue sellando.

BIMI: tu logotipo en la bandeja de entrada

BIMI (Brand Indicators for Message Identification) es un registro TXT en default._bimi.tudominio que apunta a tu logotipo en formato SVG y, opcionalmente, a un certificado que acredita que la marca es tuya. Los buzones compatibles muestran el logotipo junto a tus correos, pero solo si el mensaje pasa DMARC y tu política está aplicada. BIMI no es un RFC: es un borrador del IETF que impulsa el BIMI Group.

Requisitos

1. DMARC aplicado en el dominio y en los subdominios: p=quarantine o p=reject, sin sp=none y, si aún lo usas, con pct=100.
2. El logotipo en SVG Tiny Portable/Secure (SVG Tiny PS): cuadrado, con baseProfile="tiny-ps", con un elemento <title>, sin scripts, sin imágenes incrustadas ni enlaces externos, servido por HTTPS. El BIMI Group recomienda que no pase de 32 KB.
3. Para Gmail y Apple Mail, un certificado: VMC (Verified Mark Certificate), que exige una marca registrada, o CMC (Common Mark Certificate), que exige haber usado el logotipo públicamente durante al menos 12 meses.
4. El registro: default._bimi.empresa.es TXT "v=BIMI1; l=https://empresa.es/bimi/logo.svg; a=https://empresa.es/bimi/vmc.pem"

Apple ofrece además su propio sistema, Branded Mail, dentro de Apple Business Connect: no usa BIMI ni certificados y solo afecta al correo que se lee en dispositivos de Apple. ¿Merece la pena BIMI? Si tu marca envía mucho correo a particulares y ya tienes DMARC aplicado, sí: refuerza el reconocimiento y dificulta la imitación. Si tu DMARC sigue en p=none, el orden correcto es el contrario.

Cifrado en tránsito: STARTTLS, MTA-STS, TLS-RPT y DANE

SPF, DKIM y DMARC dicen quién envía. El cifrado protege que nadie lea o altere el mensaje entre servidores. Entre MTA, el cifrado se negocia con STARTTLS, que es oportunista: si un atacante en medio elimina el anuncio 250-STARTTLS, los servidores siguen hablando en claro sin avisar a nadie. Tres mecanismos cierran esa puerta:

Gmail valida MTA-STS al enviar. Exchange Online valida DANE al enviar desde 2022 y lo admite para el correo entrante desde octubre de 2024, aunque hay que activarlo expresamente. Empieza siempre con MTA-STS en modo testing y TLS-RPT, y pasa a enforce cuando los informes estén limpios.

Lo que exigen Gmail, Yahoo y Microsoft

Hasta 2024, autenticar el correo era una buena práctica. Desde entonces, los grandes buzones lo exigen, y desde 2025 lo hacen cumplir con rechazos.

El umbral de 5.000 se cuenta por dominio del From y sumando todo lo que envías, no por campaña. Y una vez que lo superas, Google considera que eres remitente masivo de forma permanente.

Proveedor a proveedor: lo que no cuenta la documentación

Estas notas salen de configurar y revisar estos servicios. La herramienta genera los registros exactos para cada combinación.

Microsoft 365

• DKIM no se activa solo para tus dominios. Hasta que lo haces, Microsoft firma con tudominio.onmicrosoft.com, que no está alineado: DMARC depende únicamente de SPF y falla en cuanto alguien reenvía un correo.
• Desde mayo de 2025, los dominios nuevos reciben CNAME que terminan en .dkim.mail.microsoft; los antiguos siguen apuntando a .onmicrosoft.com. Cópialos siempre del portal o de Get-DkimSigningConfig.
• La clave por defecto es de 1024 bits. Rotate-DkimSigningConfig -KeySize 2048 la sube a 2048; el cambio tarda cuatro días en aplicarse.
• Si tus MX apuntan a una pasarela (Mimecast, Proofpoint…), activa Enhanced Filtering for Connectors. Sin él, Microsoft ve la IP de la pasarela y SPF falla en todo tu correo entrante.
• Desde septiembre de 2025 puedes rechazar el Direct Send no autorizado con Set-OrganizationConfig -RejectDirectSend $true, una vía usada en campañas de phishing contra usuarios de Microsoft 365.

Google Workspace

• Sin clave propia, Gmail firma con un dominio técnico del tipo tudominio-com.<fecha>.gappssmtp.com, que no alinea. Genera la clave en Aplicaciones › Google Workspace › Gmail › Autenticar correo y pulsa «Iniciar autenticación».
• Si tu proveedor DNS no admite TXT largos, divide la clave de 2048 bits en varias cadenas dentro del mismo registro en lugar de bajar a 1024.
• _spf.google.com ya publica sus rangos directamente: cuesta una sola consulta.

Hostings y paneles (IONOS, OVHcloud, Arsys, Dinahosting, cPanel, Plesk)

• Si el hosting gestiona tu DNS, activar DKIM desde su panel suele publicar el registro solo. Si tu DNS está en otro sitio, tienes que copiar tú los registros, y es ahí donde se quedan a medias.
• El SPF que proponen los paneles tipo cPanel suele ser a mx y alguna IP. Sustituir a y mx por las IP reales ahorra consultas y evita autorizar de más.
• Los formularios de WordPress envían con la función mail() del servidor, con un sobre del propio servidor: es la fuente de correo no alineado más común en pymes. Configura el envío por SMTP autenticado.
• El include de OVHcloud usa ptr, desaconsejado, y termina en ?all; el de IONOS también termina en ?all. No afecta a tu resultado, que decide tu propio all, pero conviene saberlo al leer el árbol.

Plataformas de marketing (Mailchimp, Brevo, Acumbamail, MailerLite…)

• Casi todas usan su propio dominio en el sobre, así que SPF nunca alinea con el tuyo y DMARC pasa solo por DKIM. Por eso autenticar el dominio en la plataforma, con sus CNAME, es imprescindible, y añadir su include a tu SPF muchas veces no sirve de nada.
• Brevo puede ofrecerte sustituir tu DMARC por el suyo al autenticar el dominio de forma automática. Si ya tienes uno con tus propios destinos de informes, hazlo de forma manual.
• Mi consejo: envía el marketing desde un subdominio (news.empresa.es). Separas reputaciones y puedes llevar ese subdominio a p=reject sin afectar al correo de las personas.

Correo transaccional (SendGrid, Amazon SES, Mailgun, Postmark)

• SendGrid con Automated Security te da tres CNAME: uno convierte un subdominio tuyo en el sobre (em1234.empresa.es) y alinea SPF. No añadas además include:sendgrid.net a tu SPF raíz.
• Amazon SES usa por defecto su propio sobre (amazonses.com). Poner include:amazonses.com en tu dominio raíz es un error frecuente que no alinea nada; lo que alinea SPF es configurar un MAIL FROM personalizado en un subdominio.
• Mailgun recomienda un subdominio de envío (mg.empresa.es) con su propio SPF. En la región europea el include es eu.mailgun.org, que cuesta 2 consultas frente a las 5 del global.
• Postmark alinea SPF con un CNAME pm-bounces; sin él, DMARC depende solo de DKIM.

CRM, soporte y pasarelas

• HubSpot te da un include propio de tu cuenta y dos CNAME DKIM (hs1-…, hs2-…): cópialos tal cual.
• include:email.freshdesk.com consume 7 de tus 10 consultas. Si usas Freshdesk con Microsoft 365 y alguna plataforma más, pasarás del límite.
• Con Mimecast, usa el include de tu región (eu._netblocks.mimecast.com, una consulta) y no el global (nueve).

Los errores que más veo

1. Dos registros SPF. Cada proveedor pidió «añadir un TXT» y se añadieron dos. El resultado es permerror: hay que fusionarlos en uno.
2. SPF por encima de diez consultas. Funciona a ratos, que es peor que no funcionar. Mide el árbol completo, no solo tu registro.
3. DKIM publicado pero no activado. Los CNAME están en el DNS, pero nadie pulsó «Habilitar» en Microsoft 365 o «Iniciar autenticación» en Google Workspace.
4. CNAME de DKIM con el proxy de Cloudflare activo. El nombre deja de devolver la clave. Los registros de correo van siempre en «solo DNS».
5. El dominio repetido. El panel añade el dominio al final y el registro acaba en _dmarc.empresa.es.empresa.es. Comprueba siempre desde fuera.
6. rua sin mailto: o con comas donde van puntos y coma. El registro deja de funcionar o pierdes los informes.
7. Informes a otro dominio sin autorizar. Falta el registro _report._dmarc y los receptores no te mandan nada.
8. p=reject el primer día. Se pierden las facturas que salían por el ERP y el boletín que nadie había autenticado.
9. p=none para siempre. Recibes informes que nadie lee y el dominio sigue siendo suplantable.
10. sp=none olvidado. El dominio principal está protegido, pero cualquiera puede usar facturas.empresa.es.
11. Dominios secundarios sin proteger. El .com, el nombre antiguo o el de una campaña no envían correo, pero cualquiera puede enviar con ellos.
12. Claves de 1024 bits sin rotar desde hace años. Funcionan, pero están por debajo de lo recomendado y nadie sabe ya quién tiene la privada.

Dominios que no envían correo

Cada dominio que registras es un dominio que alguien puede usar para suplantarte. Si no envía correo, díselo al mundo con estos registros:

empresa-antigua.es.            TXT  "v=spf1 -all"
_dmarc.empresa-antigua.es.     TXT  "v=DMARC1; p=reject; sp=reject; np=reject"
*._domainkey.empresa-antigua.es. TXT "v=DKIM1; p="
empresa-antigua.es.            MX   0 .

El último registro, el MX nulo, dice que el dominio tampoco recibe correo. Si lo recibe, quita esa línea y deja las otras tres.

Plan de despliegue sin perder correo

Marca lo que ya tienes. Las marcas se quedan en tu navegador y no se envían a ningún sitio.

Preguntas frecuentes

¿Qué diferencia hay entre SPF, DKIM y DMARC?

SPF publica qué servidores pueden enviar con tu dominio y se comprueba contra el dominio del sobre (Return-Path). DKIM firma cada mensaje y el receptor verifica la firma con una clave pública publicada en tu DNS. DMARC exige que al menos uno de los dos valide el mismo dominio que aparece en el From, dice qué hacer con lo que falle y te envía informes.

¿Necesito los tres?

Sí. SPF y DKIM autentican, pero ninguno protege por sí solo el remitente que ve la persona; eso lo hace DMARC exigiendo alineación. Además, Gmail, Yahoo y Outlook.com exigen los tres a quien envía más de 5.000 correos al día.

¿Puedo tener dos registros SPF?

No. Si un dominio publica dos registros que empiezan por v=spf1, el resultado es permerror y SPF deja de funcionar. Hay que fusionarlos en un único registro con todos los mecanismos.

¿Cuántas consultas DNS puede tener un registro SPF?

Diez. Cuentan los mecanismos include, a, mx, ptr y exists y el modificador redirect, también los que están dentro de cada include. Si una evaluación necesita más, el resultado es permerror. RFC 7208 recomienda además no pasar de dos consultas vacías.

¿Por qué falla DMARC si SPF y DKIM pasan?

Porque pasan para otro dominio. Una plataforma de envío sin configurar autentica con su propio dominio en el sobre y en la firma; DMARC exige que alguno de los dos coincida con el dominio del From. La solución es autenticar tu dominio en la plataforma para que firme DKIM con él.

¿Tengo que llegar a p=reject?

No siempre. RFC 9989 pide pasar por p=none y p=quarantine al menos un mes cada una, exige firmar con DKIM a quien publica reject y desaconseja p=reject en dominios cuyos usuarios escriben a listas de correo. Para dominios que solo envían correo automatizado o que no envían, reject es lo adecuado.

¿Es mejor terminar el SPF en ~all o en -all?

Con DMARC aplicado, ~all es lo que recomienda Google, y RFC 9989 advierte de que con -all algunos receptores rechazan en SPF antes de mirar DMARC, con lo que se pierden reenvíos que DKIM habría salvado. En dominios que no envían correo, -all.

¿Cada cuánto llegan los informes DMARC?

Los grandes receptores suelen enviar un informe agregado al día por dominio, en XML comprimido. Incluye las IP que enviaron con tu dominio, cuántos mensajes y los resultados de SPF, DKIM y DMARC, sin el contenido de los correos.

¿Qué es BIMI y qué necesito para usarlo?

BIMI muestra el logotipo de tu marca junto a tus correos. Necesitas DMARC en quarantine o reject, el logotipo en SVG Tiny PS y, para Gmail y Apple Mail, un certificado: VMC, que exige marca registrada, o CMC, que exige 12 meses de uso público del logotipo. Apple solo acepta VMC y Outlook no muestra BIMI.

¿ARC va a desaparecer?

El IETF propuso en abril de 2026 reclasificar ARC (RFC 8617) como histórico y trabaja en DKIM2 como sucesor. Mientras tanto, Gmail, Microsoft 365 y Yahoo siguen validando cadenas ARC, así que listas de correo, reenviadores y pasarelas deberían seguir sellando.

¿DMARC me protege de los dominios que se parecen al mío?

No. Un dominio como empresa-es.com pertenece a otra persona, que puede autenticarlo correctamente. DMARC solo protege el uso de tu propio dominio. Contra los dominios parecidos ayudan la vigilancia de registros, BIMI y la formación.

¿Qué cambia con DMARCbis (RFC 9989)?

Publicado en mayo de 2026, convierte DMARC en estándar del IETF, sustituye la Public Suffix List por un recorrido del árbol DNS, elimina pct, rf y ri, añade np, t y psd, y lleva los informes a RFC 9990 y 9991. Los registros v=DMARC1 existentes siguen funcionando.

Glosario

Alineación

Coincidencia entre el dominio del From y el dominio validado por SPF (el del sobre) o por DKIM (el d= de la firma). En modo relajado basta con compartir el dominio organizativo; en modo estricto tienen que ser idénticos.

ARC

Authenticated Received Chain (RFC 8617). Cadena de sellos que añaden los intermediarios para certificar los resultados de autenticación que tenía el mensaje al llegarles. En 2026 el IETF propone declararlo histórico.

BIMI

Brand Indicators for Message Identification. Registro TXT en default._bimi que apunta a un logotipo SVG y a un certificado; los buzones compatibles lo muestran si el correo pasa DMARC con la política aplicada.

CMC

Common Mark Certificate. Certificado para BIMI que no exige marca registrada, sino 12 meses de uso público del logotipo. Gmail lo acepta sin mostrar la marca de verificación; Apple no lo acepta.

compauth

Resultado de autenticación compuesta que Microsoft 365 añade a las cabeceras, con un código de motivo de tres cifras (por ejemplo, 000 para un fallo explícito de DMARC o 130 para un sello ARC de confianza).

DANE

DNS-based Authentication of Named Entities (RFC 7672 para SMTP). Publica en registros TLSA la huella del certificado de un servidor de correo, validada con DNSSEC.

DKIM

DomainKeys Identified Mail (RFC 6376). Firma criptográfica que el servidor de salida añade a cada mensaje y que el receptor verifica con la clave pública publicada en el DNS.

DKIM2

Sucesor de DKIM y ARC en desarrollo en el IETF: cada servidor que maneja el mensaje añade su firma, formando una cadena de custodia verificable.

DMARC

Domain-based Message Authentication, Reporting and Conformance (RFC 9989). Política publicada en _dmarc que exige alineación de SPF o DKIM con el From, indica qué hacer con lo que falle y pide informes.

DMARCbis

Nombre con el que se conoció durante su elaboración la revisión de DMARC publicada en mayo de 2026 como RFC 9989, 9990 y 9991.

DNSSEC

Extensiones de seguridad del DNS que firman las respuestas para evitar que se falsifiquen. Es requisito para DANE.

Dominio organizativo

El dominio que DMARC usa para la alineación relajada y para heredar la política. RFC 9989 lo determina con un recorrido del árbol DNS en lugar de con la Public Suffix List.

HELO / EHLO

Saludo con el que un servidor se identifica al iniciar una conversación SMTP.

MAIL FROM

Dirección del sobre SMTP (RFC 5321) a la que vuelven los rebotes. Queda registrada como Return-Path y es la que comprueba SPF.

MDA

Mail Delivery Agent. Programa que deposita el mensaje en el buzón y aplica filtros.

MSA

Mail Submission Agent. Servidor que recibe el correo de los usuarios autenticados, normalmente en el puerto 587 o 465.

MTA

Mail Transfer Agent. Servidor que transfiere el correo entre dominios usando SMTP.

MTA-STS

Mecanismo (RFC 8461) con el que un dominio exige que el correo que recibe llegue por TLS con un certificado válido.

MUA

Mail User Agent. El programa con el que una persona lee y escribe correo: Outlook, Gmail, Apple Mail, Thunderbird.

MX

Registro DNS que indica qué servidores reciben el correo de un dominio y con qué preferencia.

MX nulo

Registro MX con valor «0 .» (RFC 7505) que declara que un dominio no acepta correo.

Oversigning

Firmar con DKIM más veces una cabecera de las que aparece en el mensaje, para que nadie pueda añadir otra copia sin romper la firma.

PTR

Registro de DNS inverso que asocia una IP a un nombre. Gmail y Yahoo exigen DNS inverso válido a las IP que les envían correo.

Return-Path

Cabecera que el servidor receptor añade con la dirección del MAIL FROM.

rua / ruf

Etiquetas de DMARC que indican dónde enviar los informes agregados (rua) y los informes de fallo (ruf).

Selector DKIM

Nombre que identifica una clave DKIM concreta; la clave pública se publica en <selector>._domainkey.<dominio>.

SMTP

Simple Mail Transfer Protocol (RFC 5321). Protocolo con el que se envía y transfiere el correo.

SPF

Sender Policy Framework (RFC 7208). Registro TXT con la lista de servidores autorizados a enviar correo con un dominio.

STARTTLS

Orden SMTP que convierte una conexión sin cifrar en una cifrada con TLS. Por sí sola es oportunista y puede eliminarse con un ataque intermedio.

SVG Tiny PS

Perfil restringido de SVG que exige BIMI para los logotipos: sin scripts ni recursos externos.

TLS-RPT

Mecanismo (RFC 8460) con el que un dominio pide informes de los fallos de entrega cifrada.

VMC

Verified Mark Certificate. Certificado para BIMI que acredita una marca registrada. Gmail muestra con él una marca de verificación y Apple Mail lo exige.