Cómo evitar que suplanten tu dominio en correos: SPF, DKIM y DMARC paso a paso
· Equipo Tucango

Un cliente te llama para preguntarte por una "factura pendiente" que le llegó desde tu correo. Tú nunca la mandaste. Alguien usó el nombre de tu empresa para engañarlo, y lo peor es que tu dominio no tenía cómo impedirlo.
Esto se llama suplantación de dominio (o spoofing), y se evita con tres registros que se configuran en el DNS de tu dominio: SPF, DKIM y DMARC. No necesitas ser ingeniero para entenderlos. En esta guía te explicamos qué hace cada uno, cómo revisar tu dominio en 10 minutos con herramientas gratis y cuál es la ruta segura para dejarlo protegido sin que tus propios correos dejen de llegar.
Qué es la suplantación de dominio y por qué te debería importar
El correo electrónico se diseñó hace décadas sin un sistema para comprobar quién envía cada mensaje. Por eso, cualquiera puede escribir facturacion@tuempresa.cl en el campo "De" de un correo. El estándar de SPF lo reconoce de entrada: cualquier servidor puede usar el nombre de dominio que quiera al enviar un correo (RFC 7208).
Si tu dominio no está protegido, te expones a tres problemas:
- Phishing a tus clientes y proveedores. Correos falsos con tu marca que piden pagos, datos o claves. El CSIRT de Gobierno de Chile informa que la Red de Conectividad del Estado bloqueó más de 700 mil correos maliciosos en 2023, y por eso recomienda implementar estos tres protocolos (CSIRT, Manual SPF, DKIM y DMARC).
- Peor entregabilidad. Gmail advierte que los mensajes que no se autentican pueden marcarse como spam o rechazarse (Google, Directrices para remitentes). Es decir, tus cotizaciones y newsletters legítimos pueden terminar en la carpeta de spam.
- Daño a tu reputación. Si tu marca aparece en una estafa, el cliente no distingue entre "me suplantaron" y "esta empresa no es confiable".
SPF, DKIM y DMARC explicados simple
Piensa en tu dominio como un edificio con conserjería.
SPF: la lista de quién puede enviar en tu nombre
SPF (Sender Policy Framework) es un registro TXT en tu DNS que lista los servidores autorizados para enviar correos con tu dominio (RFC 7208). Si usas Google Workspace y además un servicio de newsletters, ambos deben estar en esa lista. Google lo resume así: el registro SPF debe incluir a todos los remitentes de correo de tu dominio (Google).
Se ve más o menos así: v=spf1 include:_spf.google.com ~all
DKIM: la firma que demuestra que el correo es tuyo
DKIM (DomainKeys Identified Mail) agrega una firma digital a cada correo que envías. Tu servidor firma con una clave privada y publicas la clave pública en el DNS, en un nombre del tipo selector._domainkey.tudominio.cl (RFC 6376). Así, quien recibe el correo puede comprobar que lo enviaste tú y que nadie lo modificó en el camino (Yahoo Sender Hub).
Gmail exige una clave de al menos 1.024 bits y recomienda 2.048 bits si tu proveedor de DNS lo permite (Google).
DMARC: la regla que dice qué hacer con los impostores
DMARC une a los dos anteriores. Es un registro TXT publicado en _dmarc.tudominio.cl que les dice a Gmail, Outlook y compañía qué hacer con los correos que dicen venir de tu dominio pero no pasan SPF ni DKIM: dejarlos pasar (p=none), mandarlos a spam (p=quarantine) o rechazarlos (p=reject) (RFC 9989).
Además, DMARC exige alineación: no basta con pasar SPF o DKIM, el dominio que se autentica tiene que coincidir con el que aparece en el "De" del correo (Google). Y con la etiqueta rua te llegan informes diarios con todos los que envían correos usando tu dominio, incluidos los impostores.
Dato actualizado: en mayo de 2026 DMARC pasó a ser estándar oficial de Internet con la RFC 9989, que reemplaza a la antigua RFC 7489. Lo esencial no cambia, pero la etiqueta
pct(aplicar la política a un porcentaje) quedó en desuso y la reemplazat=y, un modo de prueba.
Paso a paso: revisa tu dominio en 10 minutos
No necesitas acceso técnico para hacer este diagnóstico. Solo tu dominio y estas herramientas gratis.
1. Haz el chequeo general con Google Admin Toolbox
Entra a Check MX de Google Admin Toolbox, escribe tu dominio y revisa las alertas. Te dirá si falta SPF, DKIM o DMARC y si hay problemas de configuración. Google la recomienda para revisar y corregir la configuración de tu dominio (Google).
2. Mira cada registro con Dig o MXToolbox
Con Dig de Google Admin Toolbox (eligiendo TXT) o con MXToolbox revisa:
- SPF: busca un TXT en tu dominio raíz que empiece con
v=spf1. Debe haber uno solo: dos registros SPF generan un error permanente (RFC 7208, sección 4.5). - DKIM: busca el TXT en
selector._domainkey.tudominio.cl. Si usas Google Workspace, el selector predeterminado esgoogle, así que el nombre esgoogle._domainkey(Google, Configura DKIM). - DMARC: busca el TXT en
_dmarc.tudominio.cl. Fíjate en el valor dep=y en si existerua=. En MXToolbox también tienes un verificador de DMARC.
3. Revisa un correo real
Envíate un correo desde tu dominio a una cuenta de Gmail, abre el menú ⋮ y elige "Mostrar original". Ahí verás si SPF, DKIM y DMARC dicen PASS. Repite la prueba con cada herramienta que envíe correos por ti: tu CRM, tu plataforma de newsletters o tu tienda online.
Errores comunes (y cómo evitarlos)
Dejar DMARC en p=none para siempre
p=none sirve para partir, porque te permite recibir informes sin afectar la entrega. Pero el propio estándar lo llama "modo de monitoreo" y lo distingue del estado de protección real, que es cuando la política ya no es none (RFC 9989). Si llevas meses en none, tu dominio sigue igual de expuesto.
Malinterpretar el ~all del SPF
~all (softfail) indica que un servidor probablemente no está autorizado, y el estándar dice que no se debería rechazar un correo solo por ese resultado (RFC 7208, sección 8.5). Ojo: Google recomienda usar ~all (Google, Configura SPF), así que no es un error en sí mismo. El problema aparece cuando ~all va acompañado de un DMARC en none: ahí nadie está pidiendo bloquear a los impostores. La protección real la da DMARC en quarantine o reject.
Pasarte de 10 consultas DNS en el SPF
Cada include, a, mx, ptr, exists o redirect consume una consulta DNS, y el límite es 10. Si lo superas, el SPF da error permanente y deja de servir (RFC 7208, sección 4.6.4). Considera que cada include puede tener otros include adentro. Pasa mucho cuando se van sumando herramientas y nadie limpia las que ya no se usan.
Publicar la clave DKIM en el lugar equivocado
La clave va en selector._domainkey.tudominio.cl, no en la raíz ni en _dmarc. Un error muy común es pegar el valor v=DKIM1; k=rsa; p=... en el campo de nombre incorrecto del panel DNS.
Olvidar servicios que envían en tu nombre
Mailchimp, Elastic Email, MailPoet, tu CRM, tu sistema de facturación o el servidor de tu sitio web: cada uno debe estar autorizado en SPF y, idealmente, firmar con DKIM usando tu dominio. Microsoft lo pide explícitamente para los servicios externos: que firmen con DKIM con tu dominio y que tu SPF incluya sus servidores (Microsoft Support). Cada proveedor te entrega los valores exactos en su panel de "autenticación de dominio".
La ruta segura: de p=none a reject
El CSIRT de Gobierno recomienda implementar estos protocolos de forma gradual para no interrumpir el correo legítimo (CSIRT). Esta es la ruta que proponemos, basada en la guía de Google (Implementación recomendada de DMARC):
- Configura SPF y DKIM con todos tus remitentes. Google pide hacerlo al menos 48 horas antes de activar DMARC.
- Publica DMARC en modo monitoreo:
v=DMARC1; p=none; rua=mailto:dmarc@tudominio.cl. Revisa los informes durante al menos una semana (Google indica que suele bastar para ver todos tus flujos de correo). - Corrige cada remitente legítimo que aparezca fallando.
- Pasa a cuarentena:
p=quarantine. Si quieres ir con cautela, puedes agregart=ymientras pruebas (RFC 9989). - Llega a rechazo:
p=reject. Ojo: con rechazo, los correos que fallen DMARC no se entregan nunca (Google).
Sigue revisando los informes después: cada vez que sumes una herramienta nueva, tendrás que autorizarla.
Lo que exigen Gmail, Yahoo y Outlook
Esto ya no es solo buena práctica. Los grandes proveedores lo exigen.
Gmail (desde el 1 de febrero de 2024) (Google):
- Todos los remitentes: SPF o DKIM, DNS directo e inverso válido, conexión TLS y tasa de spam bajo 0,30 % en Postmaster Tools (lo ideal es bajo 0,10 %).
- Si envías más de 5.000 correos al día a cuentas de Gmail: SPF, DKIM y DMARC (puede ser
p=none), alineación con el "De" y baja con un clic en los correos de marketing, con un enlace visible en el cuerpo.
Yahoo (desde febrero de 2024) (Yahoo Sender Hub):
- Remitentes masivos: SPF y DKIM, DMARC válido con al menos
p=noney aprobado, tasa de spam bajo 0,3 %, baja con un clic y procesar las bajas en un plazo de 2 días.
Outlook.com, Hotmail y Live (desde el 5 de mayo de 2025) (Microsoft Postmaster y Microsoft Support):
- Dominios que envían 5.000 correos o más a los servicios de correo personal de Microsoft: SPF y DKIM aprobados, DMARC publicado (al menos
p=none) y alineado. Los que no cumplen reciben el rechazo550 5.7.515.
Si mandas newsletters a tu base, revisa esto antes de tu próxima campaña. Y si también haces campañas por WhatsApp, revisa nuestra guía de WhatsApp masivo sin bloqueos.
Extras para cuando ya estés protegido
- BIMI: permite mostrar el logo de tu marca junto a tus correos en los proveedores compatibles. Requiere DMARC en
quarantineoreject; no funciona conp=none(Google, Configura BIMI). - MTA-STS: protege los correos que recibes, porque obliga a que lleguen por una conexión cifrada con TLS (RFC 8461).
Preguntas frecuentes
¿Qué diferencia hay entre SPF, DKIM y DMARC?
SPF lista los servidores que pueden enviar correos con tu dominio. DKIM firma cada correo para demostrar que es tuyo y que no lo modificaron. DMARC indica qué hacer con los correos que no pasan esas pruebas y te envía informes.
¿Basta con tener SPF?
No. SPF por sí solo no protege el "De" que ve tu cliente. Para evitar la suplantación necesitas DMARC en quarantine o reject, apoyado en SPF y DKIM alineados con tu dominio.
¿Configurar DMARC puede hacer que mis correos dejen de llegar?
En p=none no afecta la entrega. El riesgo aparece al pasar a quarantine o reject sin haber autorizado todos tus servicios. Por eso conviene avanzar por etapas y revisar los informes.
¿Cuánto se demora en aplicarse un cambio en el DNS?
Depende del TTL de cada registro y de tu proveedor de DNS. Por eso Google recomienda configurar SPF y DKIM al menos 48 horas antes de activar DMARC.
¿Envío menos de 5.000 correos al día? ¿Igual me afecta?
Sí. Gmail exige SPF o DKIM a todos los remitentes, y los correos sin autenticar pueden ir a spam o ser rechazados. Además, la suplantación afecta a cualquier dominio, envíe poco o mucho.
¿Cómo sé si alguien está suplantando mi dominio?
Activa DMARC con la etiqueta rua. Los informes diarios te muestran qué servidores envían correos con tu dominio y si pasan o fallan la autenticación.
¿Quieres saber si tu dominio está protegido?
En Tucango revisamos tu dominio y la configuración de correo de tu empresa: SPF, DKIM, DMARC y cada herramienta que envía correos en tu nombre. Te entregamos un diagnóstico claro y te acompañamos hasta llegar a p=reject sin perder ni un correo legítimo.
- ¿Mandas newsletters o campañas? Lo vemos junto con tu estrategia de marketing digital.
- ¿Tu sitio o tu correo están con nosotros? Lo incluimos en nuestro servicio de hosting y soporte.
👉 Escríbenos y revisamos tu dominio.
Fuentes
- Directrices para remitentes de correos — Ayuda de Gmail / Google — https://support.google.com/a/answer/81126?hl=es
- Implementación recomendada de DMARC — Google Workspace — https://support.google.com/a/answer/10032473?hl=es
- Configura DKIM — Google Workspace — https://support.google.com/a/answer/174124?hl=es
- Configura SPF — Google Workspace — https://support.google.com/a/answer/10685031?hl=es
- Configura BIMI — Google Workspace — https://support.google.com/a/answer/10911320?hl=es
- Google Admin Toolbox: Check MX y Dig — Google — https://toolbox.googleapps.com/apps/checkmx/ y https://toolbox.googleapps.com/apps/dig/
- Sender Best Practices (requisitos para remitentes) — Yahoo Sender Hub — https://senders.yahooinc.com/best-practices/
- Fix NDR error "550 5.7.515" in Outlook.com — Microsoft Support — https://support.microsoft.com/topic/fix-ndr-error-550-5-7-515-in-outlook-com-34cfe8f8-6fbf-457e-9e8b-9e4dbaf4e0ef
- Outlook.com Postmaster: Requirements for High-Volume Senders — Microsoft — https://postmaster.outlook.com/
- RFC 7208: Sender Policy Framework (SPF) — IETF, abril 2014 — https://datatracker.ietf.org/doc/html/rfc7208
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — IETF, septiembre 2011 — https://datatracker.ietf.org/doc/html/rfc6376
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF, mayo 2026 — https://www.rfc-editor.org/rfc/rfc9989.html
- RFC 7489: DMARC (versión anterior, reemplazada por la RFC 9989) — https://datatracker.ietf.org/doc/rfc7489/
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) — IETF, septiembre 2018 — https://datatracker.ietf.org/doc/html/rfc8461
- Manual: Implementación SPF, DKIM y DMARC en servicios públicos — CSIRT de Gobierno de Chile, abril 2024 — https://csirt.gob.cl/documents/4563/Manual_SPF_DKIM_y_DMARC.pdf
- MXToolbox SuperTool y DMARC Lookup — https://mxtoolbox.com/SuperTool.aspx y https://mxtoolbox.com/dmarc.aspx
