Respuesta rápida (actualizada el 04-11-2026): Si tu dominio no tiene registro DMARC, tu servidor de correo no tiene ninguna instrucción tuya sobre qué hacer con un mensaje que dice llegar desde tu empresa: no se marca como falso, no se bloquea y nadie te avisa de que pasó. Y si lo tienes en modo
p=none, tampoco: ese modo solo registra, no bloquea. De 22 dominios de empresas chilenas con respuesta concluyente, medidos por Personnn el 04-11-2026, 11 no tenían registro DMARC: la mitad de la muestra. De los 11 que sí lo tenían, 8 estaban enp=none, 2 enp=quarantiney 1 enp=reject. La medición se hizo con consultas DNS públicas, con la muestra y la fecha indicadas al final.
Qué es DMARC y por qué te importa
DMARC es un registro DNS que le dice a los servidores de correo qué hacer con los mensajes que dicen llegar desde tu dominio, y de paso, dónde enviar los reportes de lo que pasa. Es un mecanismo estándar: el RFC 7489 de la IETF (marzo 2015) lo define como la forma de distribuir la política del dominio sobre qué hacer con los mensajes que fallan la verificación, desde no hacer nada hasta rechazarlos.
Sin ese registro, el control de si un correo es legítimo queda en manos del servidor que recibe. En la práctica, un atacante puede enviar un mensaje que dice llegar desde el correo de tu empresa, o desde el de tu área de cobranzas, desde un servidor que no tiene nada que ver contigo. El correo puede llegar a la bandeja del cliente con el nombre de tu empresa y tu logo.
La diferencia entre los modos importa más que tener el registro:
p=none: solo observa. Se recopilan los reportes, pero no se bloquea nada. El correo falso sigue llegando a la bandeja del cliente.p=quarantine: el mensaje que no pasa la verificación va a cuarentena, es decir, a la carpeta de spam. Empieza a proteger, con algunas interrupciones.p=reject: el mensaje que no pasa la verificación se rechaza. Es el único modo que de verdad frena la suplantación.
Por eso, una empresa puede tener "el DMARC configurado" y seguir siendo vulnerable. La pregunta correcta no es si existe el registro, sino en qué modo está.
Un matiz que conviene no saltarse. DMARC no autentica por sí solo: se apoya en SPF y DKIM, que son los que dicen si la máquina que envía estaba autorizada. Lo que DMARC agrega es la política (qué hacer con lo que no pasa la verificación) y los reportes (quién intentó usar tu dominio). Si tu SPF y tu DKIM están bien, un atacante que no es una de tus máquinas autorizadas sigue sin pasar, aunque no tengas DMARC. Lo que pierdes sin DMARC es el control y el aviso: nadie te cuenta que lo intentaron.
Lo que medimos en empresas chilenas
El 04-11-2026 consultamos el DNS público de 23 dominios de empresas chilenas con sitio propio (estudios jurídicos, clínicas, veterinarias, inmobiliarias y consultoras), preguntando por el subdominio _dmarc y su registro TXT. El resultado:
- 23 dominios consultados, 22 con respuesta concluyente. Uno (dentaltrinidad.cl) quedó fuera porque sus servidores de nombres rechazaron la consulta.
- 11 de los 22 no tienen registro DMARC. La consulta al subdominio
_dmarcdevuelve "no existe el nombre". Es la mitad exacta de la muestra. Uno de esos once (encuentrahogar.cl) no resuelve siquiera en DNS: la consulta al dominio completo devuelve "no existe el nombre" a nivel de zona, así que no podría tener registro ni aunque lo quisiera. - De los 11 que sí lo tienen, 8 están en
p=none(solo registran), 2 enp=quarantiney 1 enp=reject.
La lectura incómoda es esta: de los once dominios que tienen el registro, solo uno está en el modo que de verdad frena la suplantación. Tener "DMARC" anotado en el checklist no sirve de nada si el modo es none.
Los nombres de los dominios revisados están en el anexo, al final.
Por qué esto termina en una factura falsa
El riesgo teórico es conocido. El daño concreto es el que una empresa chica reconoce de inmediato:
Facturas y cobros falsos. El cliente recibe un correo que parece de tu área de cobranzas, con el logo y el formato de siempre, pidiendo una transferencia a una cuenta distinta. El cliente paga, o peor, deja de pagar al proveedor real porque cree que ya pagó. La disputa aparece después, cuando el cliente muestra el correo, y ahí la empresa tiene que explicar que ese correo no era suyo.
Robo de credenciales. Un correo que "es de tu empresa" lleva a un portal falso donde el cliente o un empleado escribe su contraseña. Si el remitente es convincente porque el dominio es el real, la confianza es el mecanismo de ataque.
Pérdida de confianza. Un solo fraude con tu marca basta para que tu cliente revise el remitente antes de pagarte. A partir de ahí, cada aviso de cobro tuyo se lee con desconfianza.
Qué hacer, en orden
1. Publica el registro DMARC en modo p=none primero. Es el modo que no rompe nada: empieza a juntar reportes de quién intenta suplantarte. Necesitas un subdominio para recibir los reportes, por ejemplo _dmarc.tuempresa.cl, con un rua=mailto:correo-de-tu-empresa.
2. Revisa los reportes durante unas semanas. Con p=none ves qué fuentes fallan la alineación: los sistemas que todavía no sabes que envían correo por tu cuenta.
3. Ajusta SPF y DKIM para que todo lo legítimo pase. SPF (RFC 7208, IETF, abril 2014) autoriza a los servidores que pueden enviar por tu dominio: si tu registro termina en ~all, el sistema avisa pero no rechaza; en -all, los que no deberían enviar quedan rechazados. DKIM es lo que firma tus mensajes para que no se puedan alterar en el camino.
4. Sube a p=quarantine y después a p=reject. Solo cuando los reportes muestren que lo legítimo ya pasa la verificación. El orden importa: subir a reject antes de tiempo deja fuera correos legítimos de clientes y proveedores, y el problema se manifiesta como "ya no me llegan los correos", que es más difícil de diagnosticar que un phishing.
5. Revisa DKIM en los proveedores que envían por ti. Si tu plataforma de facturación o tu CRM mandan correos con tu dominio, ellos son parte de tu superficie: o firman con DKIM o terminan rechazados cuando subas a p=reject.
Lo que esto no arregla
DMARC protege tu dominio como remitente. No protege tu buzón: si alguien obtiene la contraseña de una casilla o hay un compromiso de equipo, el correo sale legítimo y DMARC no interviene. Para eso están otras medidas, como el segundo factor de autenticación y el registro de todo lo que sale.
Tampoco crea la autenticación. Si no tienes SPF ni DKIM, publicar un DMARC no hace que tus correos sean más confiables: el registro solo define qué hacer con los que fallan, y si todos fallan, todos caen al mismo destino.
Y tampoco detecta un dominio parecido al tuyo (tuempresa-cl.cl en vez de tuempresa.cl). Eso se combate con educación de clientes y con vigilancia de dominios secuestrados, no con un registro DNS.
Fuentes
- Medición propia de Personnn (04-11-2026): consultas DNS públicas con
dns.google/resolve?name=_dmarc.DOMAIN&type=TXTsobre 23 dominios de empresas chilenas con sitio propio: estudios jurídicos, clínicas, veterinarias, inmobiliarias y consultoras. Resultado: 22 respuestas concluyentes; 11 sin registro DMARC; de los 11 con registro, 8 enp=none, 2 enp=quarantiney 1 enp=reject. - Dónde se consultó: en el dominio organizacional de cada empresa, que es donde se publica el registro y donde el receptor busca primero. En el caso de wolfenson.cl se verificó además el subdominio en.wolfenson.cl: no tiene registro propio y, según el RFC 7489, queda cubierto por el del dominio principal.
- Anexo — muestra medida (04-11-2026): sin registro DMARC: maaslegal.cl, gmvabogadas.cl, bozzoeibarra.cl, iwood.cl, encuentrahogar.cl, mcrodontologia.cl, pichichus.cl, smileandmore.cl, sanmartinvet.cl, valdipets.cl, imasinmobiliaria.com. Con registro: wolfenson.cl (
p=none), cbg.cl (p=none), amplusodontologia.cl (p=none), clinicadentalzenit.cl (p=none), veterinariamagister.cl (p=none), lexlitis.cl (p=none), redabogadoschile.cl (p=none), riosconsultores.cl (p=none), clinicadentalsantiago.cl (p=reject), vetsdelvalle.cl (p=quarantine), coredevx.com (p=quarantine). Sin respuesta concluyente: dentaltrinidad.cl. - Nota de alcance: la muestra es de 23 dominios de empresas pyme chilenas con sitio propio; sirve para dimensionar el problema, no como censo nacional ni como veredicto sobre el sector.
- RFC 7489, IETF, marzo 2015, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)": qué es DMARC, dónde se busca el registro y cuáles son los modos de política
none,quarantineyreject. - RFC 7208, IETF, abril 2014, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email": cómo se autoriza a los servidores que envían por un dominio y qué significan
~ally-all.
Próximo paso
- Personnn Servicios: revisa tu sitio y mira qué encuentra — cabeceras, certificado, DMARC y SPF — con el comando para reproducir cada hallazgo. El plan de corrección y el arreglo se cotizan aparte.
- Crea tu cuenta en Personnn: gratis y sin tarjeta. Con esa cuenta entras a PersonnnOS y a Personnn Inference.
- Habla con el equipo: cuéntanos tu caso y vemos si conviene un ajuste de DNS o una revisión más amplia.
- Personnn Mail: si tu problema además es que nadie sepa qué correos salieron de tu empresa, mira Personnn Mail, que guarda la traza firmada y sellada por un tercero de todo lo que envían tus agentes.
