Un proveedor recibe un correo de [email protected] con un cambio de cuenta bancaria. El remitente es idéntico al de siempre, letra por letra, y nadie desconfía. Si ese dominio no tiene SPF, DKIM y DMARC bien configurados, cualquiera puede escribir esa dirección en el campo De y muchos servidores la aceptarán sin protestar.
SPF, DKIM y DMARC: qué es cada uno y qué problema resuelve
SPF, definido en el RFC 7208 de abril de 2014, publica la lista de servidores autorizados a enviar correo por un dominio. El receptor compara la dirección IP de quien entrega el mensaje con esa lista. Comprueba la identidad del sobre, llamada MAIL FROM, y la del saludo HELO, no la dirección que usted ve en pantalla.
DKIM, descrito en el RFC 6376 de septiembre de 2011, añade una firma criptográfica a cada mensaje. El servidor de envío firma con una clave privada y publica la clave pública en el DNS. Si alguien altera el asunto o el cuerpo en el camino, la firma deja de cuadrar y el receptor lo detecta.
DMARC une las dos piezas y añade lo que les faltaba: una política y un canal de informes. Exige que el dominio visible en el campo De coincida con el dominio validado por SPF o por DKIM, y le dice al receptor si debe entregar, enviar a spam o rechazar el mensaje que no cumple.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Qué comprueba | IP del servidor que entrega | Firma criptográfica del mensaje | Alineación con el dominio del campo De |
| Dónde se publica | TXT en el dominio | TXT o CNAME en selector._domainkey | TXT en _dmarc |
| Norma | RFC 7208 | RFC 6376 | RFC 9989 (antes RFC 7489) |
| Identidad que valida | MAIL FROM y HELO | Dominio d= de la firma | Dominio del campo De |
| Envía informes | No | No | Sí, con rua |
Qué es un registro TXT y cómo consultarlo
Un registro TXT es una entrada de texto libre en la zona DNS de un dominio. Nadie la ve al abrir la web, pero cualquier servidor del mundo puede leerla en milisegundos. SPF y DMARC viven en registros de este tipo, y DKIM también, salvo en servicios como Microsoft 365, que usan registros CNAME apuntando a sus propias claves.
En Windows, la consulta se hace desde el símbolo del sistema con nslookup -type=txt ejemplo.ec, que devuelve todos los registros TXT del dominio, entre ellos el SPF. Para ver la política DMARC se pregunta por el subdominio especial: nslookup -type=txt _dmarc.ejemplo.ec. El mismo comando sirve para cualquier dominio ajeno, incluido el de un banco.
En Linux y macOS la herramienta habitual es dig. El comando dig TXT ejemplo.ec +short muestra solo los valores, sin el resto de la respuesta, y dig TXT s2026._domainkey.ejemplo.ec +short devuelve la clave DKIM de ese selector. Conviene saber el nombre del selector de antemano, porque el DNS no ofrece una lista de los que existen.
Quien no quiere abrir una consola tiene verificadores en línea. Check MX, dentro de Google Admin Toolbox, revisa los registros MX y SPF de un dominio y acepta un selector DKIM opcional. El DMARC Lookup de MXToolbox interpreta la política y ejecuta pruebas de diagnóstico. Ambos son gratuitos y leen exactamente los mismos datos públicos del DNS.
Registro SPF: sintaxis y ejemplo para un dominio .ec
Un registro SPF siempre empieza por v=spf1 y termina con un mecanismo all. En medio van las fuentes autorizadas. Un ejemplo para una empresa que usa Google Workspace y además envía facturas desde un servidor propio en la dirección 203.0.113.25 quedaría así, publicado como TXT en la raíz de ejemplo.ec:
v=spf1 ip4:203.0.113.25 include:_spf.google.com ~allEl mecanismo ip4 autoriza una dirección o un rango, y no consume consultas DNS. El mecanismo include delega en el registro SPF de otro dominio, en este caso el de Google. Con Microsoft 365, la documentación de Microsoft indica include:spf.protection.outlook.com, y si una plataforma de boletines envía con su dominio, su propio include se añade al mismo registro.
El final decide qué pasa con lo que no está en la lista. Según el RFC 7208, ~all es un fallo suave, una declaración débil de que el servidor probablemente no está autorizado, y -all es un fallo explícito. Google recomienda ~all en su guía de Workspace; Microsoft recomienda -all para Microsoft 365 cuando DKIM y DMARC también funcionan.
Esa contradicción entre dos fabricantes confunde a mucha gente, pero tiene explicación. Microsoft advierte que un fallo suave sin firma DKIM deja a DMARC sin margen para actuar, mientras Google prefiere no castigar envíos legítimos olvidados. Con DMARC en reject, la diferencia práctica se reduce mucho, porque la decisión final la toma la política DMARC.
El límite de diez consultas DNS
El RFC 7208 fija un máximo de diez términos que generan consultas DNS al evaluar un registro: include, a, mx, ptr, exists y un modificador adicional cuentan. Si la evaluación pasa de diez, el resultado es un error permanente, permerror, y el SPF deja de proteger. Cada include anidado dentro de otro suma sus propias consultas.
Hay otro error frecuente que no depende de la cantidad: publicar dos registros SPF. Al contratar un servicio nuevo, alguien crea un segundo TXT que empieza por v=spf1 en lugar de editar el existente. El RFC 7208 trata esa duplicidad como permerror. La regla es simple: un solo registro SPF por dominio o subdominio, con todas las fuentes dentro.
DKIM: selector, clave pública y un ejemplo de registro
DKIM funciona con un par de claves. La privada queda en el servidor que firma y la pública se publica en un nombre con esta forma: selector._domainkey.dominio. El receptor lee en la firma del mensaje la etiqueta d=, que indica el dominio responsable, y la etiqueta s=, que indica el selector, y con ambas arma la consulta.
Un ejemplo de registro DKIM para ejemplo.ec con el selector s2026 se publicaría como TXT en s2026._domainkey.ejemplo.ec. La clave real es una cadena larga en Base64 que entrega la plataforma de correo; aquí aparece recortada para que se lea. La etiqueta v=DKIM1 indica la versión, k=rsa el tipo de clave y p= el contenido de la clave pública:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3x...IDAQABGoogle Workspace usa por defecto el selector google y ofrece claves de 2048 o 1024 bits; conviene la de 2048 si el proveedor de DNS la admite. Las directrices de Gmail exigen al menos 1024 bits. Un detalle técnico útil: un registro p= vacío significa que la clave fue revocada, según el RFC 6376.
Registro DMARC: etiquetas, ejemplo y alineación
El registro DMARC se publica como TXT en el subdominio _dmarc del dominio. Debe empezar por v=DMARC1 y llevar la etiqueta p con la política. Este ejemplo para ejemplo.ec pide informes agregados a un buzón dedicado y aplica una política de cuarentena, con alineación relajada, que es el valor por defecto:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=rLa etiqueta p admite tres valores: none, que solo observa; quarantine, que pide tratar el mensaje como sospechoso, normalmente enviándolo a spam; y reject, que pide rechazarlo durante la entrega. La etiqueta sp fija una política distinta para los subdominios y rua indica adónde enviar los informes agregados que mandan los grandes receptores de correo.
La alineación es el concepto que más se pasa por alto. No basta con que SPF o DKIM den un resultado positivo: el dominio que validaron debe coincidir con el del campo De. En modo relajado basta con el mismo dominio organizativo, de modo que factura.ejemplo.ec alinea con ejemplo.ec; en modo estricto, adkim=s o aspf=s, deben ser idénticos.
En mayo de 2026 se publicó el RFC 9989, que reemplaza al RFC 7489 de 2015 como norma de DMARC. Retira la etiqueta pct, que según el propio texto casi nunca se aplicaba con exactitud salvo en 0 y 100, y crea la etiqueta t para el modo de prueba. Muchas guías, incluida la de Google, todavía muestran pct.
De p=none a p=reject: cómo endurecer la política sin perder correo
Publicar p=reject el primer día es la forma más rápida de descubrir que el sistema de facturación, el CRM o la impresora multifunción enviaban correo con el dominio sin autenticarse. Google recomienda que SPF y DKIM lleven al menos 48 horas funcionando antes de activar DMARC, y que la política empiece en none mientras se leen los informes.
Fase 1: observar con p=none
Con p=none los receptores no cambian la entrega, pero envían a diario informes XML a la dirección de rua. Esos informes listan las direcciones IP que enviaron correo con su dominio y si pasaron SPF y DKIM alineados. Leerlos en bruto es tedioso; hay servicios que los agregan en paneles, y para un dominio pequeño basta una revisión semanal.
Fase 2: cuarentena
Cuando los informes muestran que todo el envío legítimo pasa la alineación, se sube a p=quarantine. Para escalonar, la guía de Google usa pct con porcentajes crecientes hasta llegar al 100; con el RFC 9989, el equivalente es t=y, que aplica la política un nivel por debajo de lo publicado mientras dura la prueba.
Fase 3: rechazo
El último paso es p=reject. A partir de ahí, un mensaje que usa ejemplo.ec en el campo De sin autenticarse no debería llegar a ningún buzón de un receptor que respete DMARC. Mantenga la dirección de rua activa: cada nuevo proveedor que contrate la empresa aparecerá primero como un fallo en esos informes.
Requisitos de Gmail, Yahoo y Outlook.com para remitentes masivos
Desde el 1 de febrero de 2024, Google exige a quien envía 5.000 mensajes diarios o más a cuentas personales de Gmail configurar SPF y DKIM, publicar un registro DMARC, alinear el dominio del campo De, ofrecer baja con un clic en correos de marketing y mantener el spam por debajo del 0,30 %, según sus directrices para remitentes.
Yahoo anunció reglas casi idénticas en el mismo mes de febrero de 2024. Pide SPF y DKIM, una política DMARC de al menos p=none que pase con alineación relajada, una cabecera de baja con un clic y atender las bajas en un plazo de dos días. Para cualquier remitente, sin importar el volumen, exige SPF o DKIM como mínimo.
Microsoft se sumó el 5 de mayo de 2025. Los dominios que envían más de 5.000 correos diarios a cuentas de Outlook.com deben pasar SPF y DKIM y publicar DMARC con al menos p=none, alineado con uno de los dos. Lo que no cumple va a correo no deseado y puede acabar rechazado con el código 550 5.7.515.
Por qué importa en Ecuador: suplantación de bancos e instituciones
El informe regional de ESET de 2023, recogido por Primicias, situó a Ecuador como el país de América Latina con más ataques de phishing detectados. Una parte de esos mensajes usa remitentes parecidos al real, como un dominio con una letra cambiada; otra usa el dominio exacto de la entidad cuando este carece de una política DMARC en reject.
DMARC no frena los dominios parecidos ni los mensajes desde cuentas gratuitas con el nombre del banco. Por eso sigue siendo necesario saber cómo reconocer un correo de phishing y revisar la dirección completa. Lo que sí elimina es la suplantación más convincente: la que muestra el dominio real, sin ninguna diferencia, en el campo De.
Para una empresa, el riesgo más caro suele ser el falso proveedor o el falso gerente que pide una transferencia urgente. INCIBE recomienda activar SPF, DKIM y DMARC frente a ese fraude y, si el correo está alojado en un proveedor externo, confirmar con él que aplica estas protecciones. El catálogo de estafas habituales recoge variantes.
Cómo verificar SPF, DKIM y DMARC de su dominio y de un mensaje
Verificar los registros es la mitad del trabajo. La otra mitad es comprobar que un mensaje real los supera. En Gmail se abre el correo, se pulsa Más junto a Responder y luego Mostrar original, que muestra el encabezado completo. Ese encabezado puede pegarse en la herramienta Messageheader de Google Admin Toolbox para analizarlo paso a paso.
Decodificador de registros SPF, DKIM y DMARC
| Parte | Qué significa |
|---|
Fuentes: RFC 7208 (SPF) · RFC 6376 (DKIM) · RFC 9989 (DMARC, mayo de 2026) · Google, requisitos para remitentes
Datos verificados al por la redacción de dds.ec · Método editorial
Cómo se calcula
El texto se separa en etiquetas o mecanismos y cada uno se compara con las reglas de su norma: el límite de diez consultas DNS y el cierre con all del RFC 7208, la clave vacía o corta del RFC 6376 y las etiquetas de DMARC según el RFC 9989, que retiró pct y creó t. El largo de la clave DKIM se estima por la longitud del texto en Base64. Los include no se resuelven: cada uno cuenta como una consulta, más las que haga por dentro.
Si sospecha que alguien ya entró en el buzón de la empresa, el problema es otro: SPF, DKIM y DMARC autentican los mensajes enviados desde una cuenta comprometida, porque salen del servidor legítimo. En ese caso conviene seguir los pasos para recuperar una cuenta de Gmail con intrusos y revisar reglas de reenvío y sesiones abiertas.
Lista de comprobación paso a paso
- Haga un inventario de todo lo que envía correo con el dominio: buzones, boletines, facturación electrónica, CRM, formularios web y equipos de oficina.
- Consulte el TXT actual con nslookup o dig y confirme que existe un solo registro que empieza por v=spf1.
- Reúna en ese registro todas las fuentes, cuente las consultas DNS y manténgase por debajo de diez.
- Active DKIM en cada plataforma, publique su selector y compruebe la clave con dig.
- Publique _dmarc con p=none y una dirección rua dedicada.
- Espere al menos 48 horas y lea los informes durante varias semanas.
- Corrija los envíos que fallan la alineación y suba a p=quarantine.
- Pase a p=reject cuando los informes estén limpios.
- Publique v=spf1 -all y una política DMARC en reject en los dominios que no envían correo.
El último punto se olvida con frecuencia. Los dominios registrados que no envían correo, por ejemplo una variante .com.ec comprada para proteger la marca, son el blanco ideal para suplantar porque nadie los vigila. Microsoft documenta el registro v=spf1 -all para estos dominios aparcados, y una política DMARC en reject cierra la puerta del todo.
Quien no tiene personal técnico para configurar SPF, DKIM y DMARC puede apoyarse en su proveedor de correo o en una de las empresas de ciberseguridad que trabajan en Ecuador. Términos como alineación, selector o permerror están en el glosario de ciberseguridad. El primer comando a ejecutar hoy es nslookup -type=txt _dmarc seguido de su dominio.