Puntos clave
- Un registro DMARC es un registro TXT de DNS publicado en _dmarc.tudominio.com. Indica a los servidores de correo qué hacer con los mensajes de correo electrónico que no superan las comprobaciones de SPF o DKIM.
- Es necesario tener configurados SPF o DKIM antes de aplicar DMARC. La supervisión con p=none funciona correctamente sin ellos, pero las opciones de cuarentena o rechazo no funcionarán hasta que al menos uno de ellos supere la verificación.
- Para publicar un registro DMARC, añade un registro TXT llamado _dmarc en tu proveedor de DNS. La propagación puede tardar hasta 48 horas; comprueba que el registro esté activo utilizando una herramienta de verificación de DMARC o las comandos dig/nslookup.
- La mayoría de los errores de DMARC se deben a unos cuantos errores sencillos: falta de puntos y comas, tipo de registro incorrecto, publicación en el dominio raíz en lugar de en _dmarc.tudominio.com, o tener dos registros cuando solo debería haber uno.
- Gmail, Yahoo y Microsoft exigen la aplicación de DMARC a los remitentes masivos. Si gestionas pagos con tarjeta, la norma PCI DSS v4.0 también exige la implantación de controles contra el phishing.
Un registro DMARC es un registro TXT de DNS que indica a los servidores de correo receptores cómo gestionar los correos electrónicos que no superan las comprobaciones de autenticación. Esta guía te explica paso a paso cómo crear tu registro DMARC, publicarlo en el DNS de tu dominio, comprobar que funciona y comprender la norma de 2026 (RFC 9989) que ahora rige el protocolo.
Tanto si estás configurando la autenticación del correo electrónico por primera vez como si estás actualizando tu registro para cumplir con los requisitos de cumplimiento normativo de 2025/2026, puedes generar y publicar un registro DMARC operativo en menos de 10 minutos. Esta guía está dirigida a profesionales de TI, administradores de dominios, proveedores de servicios gestionados (MSP) y responsables de cumplimiento normativo.
Nota: DMARC se actualizó en mayo de 2026 (RFC 9989). Todos los ejemplos de registros que aparecen en esta guía se ajustan al estándar actualizado.
¿Qué es un registro DMARC?
Un registro DMARC es un registro TXT de DNS publicado en _dmarc.tudominio.com que indica a los servidores de correo receptores cómo gestionar los correos electrónicos que afirman proceder de tu dominio y que no superan las comprobaciones de autenticación.
DMARC se basa en dos protocolos de autenticación de correo electrónico ya existentes:
- SPF (Sender Policy Framework): autoriza a direcciones IP concretas a enviar correos electrónicos desde tu dominio
- DKIM (DomainKeys Identified Mail): firma criptográficamente los correos electrónicos para demostrar que proceden de tu dominio.
Sin DMARC, no existe ninguna política que indique a los destinatarios qué deben hacer cuando fallan SPF o DKIM. Estos toman sus propias decisiones, lo que a menudo permite que se filtren correos electrónicos falsificados.
El papel de DMARC en la autenticación del correo electrónico
- El SPF comprueba la dirección IP del remitente verificando si el servidor que envía este correo electrónico está autorizado por el registro SPF del dominio.
- DKIM valida la firma comprobando si la firma digital del correo electrónico coincide con la clave DKIM publicada del dominio.
- DMARC determina la acción que se debe llevar a cabo si SPF y/o DKIM fallan. Tu política DMARC (y las reglas de alineación) indican al destinatario que rechace, ponga en cuarentena o acepte el correo electrónico.
Antes de publicar el registro DMARC
Los registros DMARC requieren que se publiquen al menos los protocolos SPF o DKIM y que estén alineados con tu dominio de envío. Puedes publicar un registro DMARC con p=none (supervisión) sin ellos, pero la aplicación de la política (p=quarantine o p=reject) requiere que al menos uno de los protocolos supere la verificación.
Comprobaciones rápidas:
Anatomía de un registro DMARC
Un registro DMARC es una cadena de pares «etiqueta-valor» separados por punto y coma. Solo son obligatorias dos etiquetas; el resto es opcional, aunque se recomienda incluirlo.
Etiquetas activas
| Etiqueta | Propósito | Valores permitidos | Ejemplo | Requisito |
|---|---|---|---|---|
| v | Versión de DMARC | DMARC1 | v=DMARC1 | Requerido |
| p | Política DMARC | ninguno, cuarentena, rechazar | p=nada | Requerido |
| sp | Política de subdominios | ninguno, cuarentena, rechazar | sp=rechazar | Opcional |
| np | Política sobre subdominios inexistentes | ninguno, cuarentena, rechazar | np = rechazar | Opcional |
| rua | Correo con el informe agregado | Dirección de correo electrónico válida | rua=mailto:[email protected] | Recomendado |
| ruf | Correo electrónico de notificación de fallos | Dirección de correo electrónico válida | ruf=mailto:[email protected] | Opcional |
| psd | Indicador de dominio con sufijo público | y (sí)/n (no)/u (se desconoce) | psd=y | Opcional |
| t | Modo de prueba | y (sí) | t = y | Opcional |
| adkim | Modo de alineación DKIM | r (flexible)/s (estricto) | adkim=r | Opcional |
| aspf | Modo de alineación SPF | r (flexible)/s (estricto) | aspf=s | Opcional |
| para | Opciones de informe de fallos | 0, 1, d, s | fo=1 | Opcional |
Nota sobre psd=: Esta etiqueta está destinada principalmente a los operadores de sufijos públicos (PSO), como los registros de códigos de país o los operadores de gTLD. La mayoría de los titulares de dominios habituales deberían omitirla por completo. Solo es relevante si tu dominio es un sufijo público, como .gov.uk o .bank.
Nota sobre ruf=: Los principales receptores (Google, Microsoft, Yahoo) ya no envían informes de error.
Etiquetas obsoletas
La RFC 9989 dejó de recomendar o eliminó tres etiquetas que provocaban inconsistencias en la implementación:
| Etiqueta | Qué era | ¿Por qué se ha dejado de utilizar? | Acción |
|---|---|---|---|
| pct | Porcentaje de correos electrónicos a los que se aplica la política | Se ha implementado de forma inconsistente en los distintos receptores, lo que da lugar a resultados impredecibles | Eliminar de los nuevos registros. Utiliza «t=y» en su lugar para indicar el modo de prueba. |
| ri | Formato del informe | Solo se utilizó un valor (afrf); redundante | Eliminar de los registros existentes al editarlos. |
| rf | Intervalo de generación de informes (en segundos) | Los receptores no le prestaron atención durante el entrenamiento | Eliminar de los registros existentes al editarlos. |
Nota: Si tus registros actuales incluyen estas etiquetas, siguen funcionando, ya que los destinatarios simplemente las ignoran. No obstante, la próxima vez que edites un registro, puedes eliminarlas para cumplir con la norma RFC 9989 y no incluirlas al publicar nuevos registros.
Comparación de políticas DMARC
| Política | Acción del receptor | Nivel de protección | Requisitos para los remitentes masivos de ESP | Cuándo utilizarlo |
|---|---|---|---|---|
| ninguno | Solo supervisión; sin rechazo | Ninguno | Aceptable | Implementación inicial; supervisión del tráfico |
| cuarentena | Enviar a la carpeta de spam/correo no deseado | Moderado | Cumple los requisitos | Para una aplicación gradual |
| rechace | Bloquear y rechazar por completo | Alta | Cumple los requisitos | Cuando se considere oportuno, se aplicará la normativa en su totalidad. |
Ejemplos de registros DMARC
Todos los ejemplos que figuran a continuación se ajustan a la RFC 9989, ya que omiten las etiquetas obsoletas e incluyen las nuevas cuando procede.
Ejemplo 1: Modo de supervisión (empieza aquí)
v=DMARC1; p=none; rua=mailto:[email protected]
Caso de uso: Primera configuración de DMARC. Sin aplicación de políticas. Se envían informes agregados diariamente para realizar un seguimiento de los resultados de la autenticación.
Función de cada etiqueta:
- v=DMARC1: indica que se trata de un registro DMARC
- p=ninguna No tomar ninguna medida; limitarse a supervisar
- rua= mailto:[email protected] Enviar informes diarios a esta dirección de correo electrónico
Ejemplo 2: Aplicación parcial (transitoria)
v=DMARC1; p=cuarentena; sp=cuarentena; np=rechazo; rua=mailto:[email protected]
Caso de uso: Avanzar hacia la aplicación de las normas. Poner en cuarentena los correos electrónicos que no superen la comprobación. Política más estricta para los subdominios inexistentes.
Novedades:
- sp=cuarentena: Los subdominios heredan la política de cuarentena
- np=rechazar: Se rechazan los subdominios inexistentes (protección según RFC 9989)
Ejemplo 3: Aplicación íntegra
v=DMARC1; p=rechazar; sp=rechazar; np=rechazar; rua=mailto:[email protected]
Caso de uso: Aplicación estricta en entorno de producción. Rechazar todos los correos electrónicos que no cumplan los requisitos. El dominio no aloja listas de correo.
Ejemplo 4: Dominio sin correo / Dominio aparcado
v=DMARC1; p=rechazar; sp=rechazar; np=rechazar; adkim=s; aspf=s
Caso de uso: dominio que no envía correos electrónicos, pero que necesita protección contra la suplantación de identidad.
¿En qué se diferencia?:
- adkim=s; aspf=s Alineación estricta (no se necesita el modo flexible)
- No rua= No se supervisan los informes (el dominio no los envía)
- np=rechazar: incluso los subdominios inexistentes rechazan los correos electrónicos falsificados
Incluso los dominios inactivos deben protegerse, ya que los atacantes pueden suplantar dominios en desuso en campañas de phishing.
Ejemplo 5: Subdominio con una política más estricta
Dominio principal: v=DMARC1; p=quarantine; rua=mailto:[email protected]
Subdominio (marketing.yourdomain.com): v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]
Caso de uso: El dominio principal permite la cuarentena (ha reenviado el correo). El subdominio de marketing es un remitente dedicado; aplicar p=rechazar.
Ejemplo 6: Microsoft 365 / Google Workspace
v=DMARC1; p=reject; rua=mailto:[email protected]
Nota: Ni Microsoft 365 ni Google Workspace requieren una sintaxis DMARC específica. El registro se publica en el DNS como en cualquier otra implementación de DMARC. Antes de aplicar las medidas, comprueba la configuración de SPF y DKIM para todas las fuentes de envío.
Si deseas un tutorial detallado, puedes consultar nuestras guías de configuración de DMARC para Microsoft 365 y Google Workspace.
Cómo crear un registro DMARC
Método 1: Utilizar el generador gratuito de PowerDMARC
1. Accede al generador de registros DMARC
2. Selecciona el nivel de aplicación que desees (Ninguno / Supervisión, Cuarentena, Rechazo)
3. Introduce tu dominio y la dirección de correo electrónico para recibir los informes
4. Activa la política de subdominios y protege los subdominios inexistentes si lo deseas (opcional)
5. Haz clic en «Generar»
6. Se ha creado el registro DMARC
Método 2: Crear manualmente
Abre un editor de texto y escribe el registro a mano:
v=DMARC1; p=none; rua=mailto:[email protected]
Empieza con p=none (supervisión). Ajustarás la política más adelante, una vez que conozcas tu tráfico de correo electrónico.
Requisitos:
- v=DMARC1 (siempre)
- p= (tu política: ninguna, cuarentena o rechazar)
- rua= (tu correo electrónico de notificación)
Cómo publicar un registro DMARC: guía paso a paso del proveedor de DNS
El DNS de tu dominio lo gestiona tu registrador de dominios (GoDaddy, Namecheap, etc.), tu proveedor de alojamiento web (cPanel) o tu CDN (Cloudflare). Inicia sesión en la plataforma correspondiente y sigue los pasos que se indican a continuación para tu proveedor.
Pasos generales (si tu proveedor no aparece en la lista):
1. Busca la consola de gestión de DNS
2. Haz clic en el dominio para el que quieras configurar DMARC
3. Crear un nuevo registro TXT
4. Nombre del registro: _dmarc (o _dmarc.tudominio.com si el formulario requiere el nombre de host completo)
5. Valor del registro: pega la cadena de tu registro DMARC
6. Guarda los cambios y espera a que se propaguen (24-48 horas)
7. Utiliza el verificador DMARC para comprobar
Publicar el registro DMARC en GoDaddy
1. Inicia sesión en tu cartera de dominios de GoDaddy
2. Haz clic en «DNS» junto a tu dominio
3. Desplázate hasta «Registros DNS»
4. Haz clic en «Añadir nuevo registro»
5. Tipo: TXT
6. Nombre: _dmarc
7. Valor: pega tu registro DMARC
8. Haz clic en «Guardar»
Publicar el registro DMARC en Cloudflare
1. Inicia sesión en tu panel de control de Cloudflare
2. Selecciona tu dominio
3. Ve a DNS > Registros
4. Haz clic en «Añadir registro»
5. Tipo: TXT
6. Nombre: _dmarc
7. Contenido: pega tu registro DMARC
8. TTL: Automático (o 3600)
9. Estado del proxy: solo DNS (sin proxy)
10. Haz clic en «Guardar»
Nota: Configura el estado del proxy en «Solo DNS» (nube gris), no en naranja. DMARC debe consultarse directamente en el DNS, sin pasar por Cloudflare.
Publicar el registro DMARC en cPanel / WHM
1. Inicia sesión en tu cuenta de cPanel
2. Ve al «Editor de zonas» (en la sección «Dominios»)
3. Haz clic en «Gestionar» junto a tu dominio
4. Haz clic en «+ Añadir nuevo registro»
5. Tipo: TXT
6. Nombre: _dmarc.tudominio.com
7. Valor (datos TXT): pega tu registro DMARC
8. Haz clic en «Añadir un registro»
Publicar el registro DMARC en Namecheap
1. Inicia sesión en tu cuenta de Namecheap
2. Ve a Panel de control > Lista de dominios
3. Haz clic en «Gestionar» junto a tu dominio
4. Ve a «DNS avanzado»
5. Haz clic en «Añadir nuevo registro»
6. Tipo: Registro TXT
7. Servidor: _dmarc
8. Valor: pega tu registro DMARC
9. TTL: Automático (3600)
10. Haz clic en la marca de verificación para guardar
Publicar el registro DMARC en Amazon Route 53
1. Inicia sesión en la Consola de administración de AWS > Route 53
2. Ve a «Zonas alojadas» y selecciona tu dominio
3. Haz clic en «Crear registro»
4. Nombre del registro: _dmarc
5. Tipo de registro: TXT
6. Valor: pega tu registro DMARC entre comillas dobles
- Ejemplo: «v=DMARC1; p=none; rua=mailto:[email protected]»
- La ruta 53 requiere comillas; sin ellas, el registro no se guardará.
7. TTL: 300 (o 3600)
8. Haz clic en «Crear registros»
Nota: La ruta 53 requiere que los valores de los registros TXT se escriban entre comillas dobles. Copia y pega tu registro tal cual y, a continuación, envuélvelo entre «…».
Publicar el registro DMARC en Microsoft 365 / Azure DNS
Si tu DNS se gestiona en Azure DNS:
1. Inicia sesión en el Portal de Azure > Zonas DNS
2. Selecciona tu dominio
3. Haz clic en «+ Registrar conjunto»
4. Nombre: _dmarc
5. Tipo: TXT
6. TTL: 3600
7. Valor: pega tu registro DMARC
8. Haz clic en «Aceptar»
Si tu DNS está en un registrador (GoDaddy, Namecheap, etc.):
- Sigue los pasos indicados anteriormente por el registrador
¿Cuánto tiempo tarda en propagarse un registro DMARC?
Los cambios en el DNS se controlan mediante un parámetro denominado TTL (Time To Live), que indica a los servidores durante cuánto tiempo deben mantener en caché un registro DNS antes de comprobar si hay actualizaciones. La mayoría de los proveedores de DNS establecen el TTL en 3600 segundos (1 hora) de forma predeterminada.
Plazos habituales:
- En la mayoría de los lugares, la propagación del DNS se produce en un plazo de 1 a 2 horas.
- En casos excepcionales, la propagación total a nivel mundial puede tardar hasta 48 horas.
- No te asustes si tu verificador de DMARC muestra «sin registro» durante la primera hora; espera al menos entre 30 y 60 minutos y vuelve a intentarlo.
Comprueba la propagación a nivel mundial: utiliza nuestra herramienta de comprobación de propagación de DNS para verificar que tu registro está activo en varios servidores DNS de todo el mundo.
Cómo comprobar que tu registro DMARC funciona correctamente
Método 1: Herramienta de verificación DMARC de PowerDMARC
1. Accede al verificador de registros DMARC
2. Introduce tu nombre de dominio
3. Haz clic en «Comprobar»
4. Los resultados muestran que:
- Válido: el registro tiene el formato correcto y se ha publicado
- No válido: error de sintaxis; revisa tu registro
- No se ha encontrado ningún registro: comprueba la propagación del DNS o verifica que el registro se haya guardado en el DNS
Método 2: Línea de comandos (nslookup o dig)
En Windows (línea de comandos):
nslookup -type=TXT _dmarc.tu-dominio.com
En Mac/Linux (Terminal):
dig TXT _dmarc.tu dominio.com
Resultado correcto:
_dmarc.tudominio.com. 3600 IN TXT «v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]»
Si no ves ningún resultado, es que el DNS aún no se ha propagado o el registro no se ha guardado correctamente.
Método 3: Comprobar el encabezado del correo electrónico (Authentication-Results)
Envía un correo electrónico de prueba y comprueba los encabezados.
Pasos:
1. Envíate un correo electrónico de prueba desde tu dominio (o pide a alguien de otra empresa que te envíe un correo electrónico)
2. En Gmail:
- Abre el correo electrónico
- Haz clic en el menú de los tres puntos (⋮) > Mostrar original
- Buscar resultados de autenticación
3. En Outlook:
- Abre el correo electrónico
- Haz clic en «Archivo» > «Propiedades» > «Encabezados de Internet»
- Buscar resultados de autenticación
Qué hay que tener en cuenta:
✅ DMARC superado:
Resultados de autenticación: mx.google.com;
dmarc=aprobado (p=RECHAZAR sp=RECHAZAR np=RECHAZAR dis=NINGUNO) header.from=tudominio.com
❌ Error de DMARC:
Resultados de autenticación: mx.google.com;
dmarc=fail (p=REJECT sp=REJECT) header.from=yourdomain.com reason=”SPF no coincide”
Qué significa «aprobado»: tu firma SPF o DKIM coincide con el dominio que figura en el encabezado «From», y se ha aplicado tu política DMARC.
Qué significa «error»: el SPF o el DKIM han fallado o no coinciden. Comprueba tu registro SPF y la configuración de DKIM.
Cuándo recibirás tu primer informe DMARC
Los informes agregados se envían en un plazo de entre 24 y 72 horas tras la publicación de tu registro.
Contenido del informe:
- Resumen diario de todos los correos electrónicos enviados desde tu dominio
- Resultados de la autenticación (SPF: correcto/incorrecto, DKIM: correcto/incorrecto, DMARC: correcto/incorrecto)
- Direcciones IP de origen y su volumen
- Países de origen
- Medidas de aplicación de la política adoptadas por los administradores judiciales
¿Qué ha cambiado en el RFC 9989 en relación con los registros DMARC?
En mayo de 2026, el RFC 9989 sustituyó al RFC 7489 como estándar oficial de DMARC. Tu registro actual sigue funcionando. Estos son los cambios principales para los nuevos registros:
Se han añadido tres nuevas etiquetas:
- np= (política de subdominios inexistentes): Añade «np=reject» o «np=quarantine» para proteger los subdominios inexistentes. Antes de la RFC 9989, los atacantes podían suplantar subdominios aleatorios sin registros DMARC. Ahora puedes establecer una política para ellos a nivel del dominio principal. La mayoría de los propietarios de dominios deberían añadir esto.
- t= (indicador de modo de prueba): Utiliza t=y para indicar que tu política se encuentra en modo de prueba. Los receptores interpretan p=reject; t=y como p=quarantine (un nivel menos estricto), lo que permite implementaciones por fases seguras. Sustituye a la antigua etiqueta pct=.
- psd= (indicador de dominio con sufijo público): Indica si un dominio es un sufijo público (como .gov.uk o .bank). Solo es relevante para los operadores de sufijos públicos y las jerarquías de dominios complejas. La mayoría de los titulares de dominios pueden ignorar este campo.
Etiquetas obsoletas o eliminadas:
- pct= está en desuso. Los receptores lo han implementado de forma inconsistente. Utiliza t=y en su lugar para implementaciones por fases.
- Se han eliminado «rf=» y «ri=». Elimínalos si aparecen en tus registros actuales. De todos modos, los receptores los ignoran.
Para obtener información más detallada sobre los cambios introducidos en el RFC 9989, consulta nuestra guía sobre el RFC 9989 de DMARC.
Requisitos de cumplimiento actualmente en vigor
| Requisito | Estado | Fecha límite | Acción |
|---|---|---|---|
| Rechazo definitivo de Gmail | Activo | Feb 2024 | Se exige la publicación de DMARC; se acepta «p=none» como punto de partida, con la expectativa de avanzar hacia «p=quarantine» o «p=reject» para los remitentes masivos (más de 5.000 mensajes al día). |
| Rechazo definitivo de Yahoo | Activo | Feb 2024 | Se exige la publicación de DMARC; se acepta «p=none» como punto de partida, con la expectativa de avanzar hacia «p=quarantine» o «p=reject» para los remitentes masivos (más de 5.000 mensajes al día). |
| Aplicación de las normas en Microsoft Outlook | Activo | Mayo de 2025 | Se exige el cumplimiento de DMARC junto con SPF y DKIM a los remitentes masivos que envíen correos a Outlook.com, Hotmail.com y Live.com |
| PCI-DSS v4.0 | Activo | Marzo de 2025 | Controles contra el phishing obligatorios para todas las entidades que manejan datos de titulares de tarjetas. |
Infórmate sobre los requisitos locales y globales en nuestra guía completa sobre los requisitos de DMARC.
Errores comunes en los registros DMARC
1. No se ha encontrado ningún registro DMARC
Causa: No has publicado un registro DMARC en tu dominio, está mal configurado o el tiempo de propagación del DNS aún no ha finalizado.
Solución: Una vez que hayas comprobado que no existe ningún registro en tu DNS, inicia sesión en la consola de gestión del DNS para publicar un nuevo registro. Si ya existe un registro, edítalo para corregir los errores o las configuraciones incorrectas. Si aún no han transcurrido las 48 horas de tiempo de propagación, espera un rato antes de volver a comprobarlo.
2. Errores de sintaxis
Errores comunes:
- Faltan puntos y comas: cada etiqueta debe ir seguida de un punto y coma.
- Espacios de más: Evita los espacios después de los puntos y comas o a ambos lados de
- Versión incorrecta: Debe ser v=DMARC1, no v=DMARC2 ni version=1
- Nombres de etiquetas no válidos: errores ortográficos como «po=reject» en lugar de «p=reject»
Registros DMARC duplicados
Motivo: Solo debe haber un registro TXT de DMARC por dominio. Si hay varios registros, los destinatarios solo leerán el primero que encuentren. Esto puede provocar un comportamiento inesperado de la política.
Solución: Asegúrate de eliminar los registros duplicados que pertenezcan al mismo dominio o, si es necesario, fusiona los registros.
Utiliza el comando: nslookup -type=TXT _dmarc.tudominio.com o utiliza una herramienta de comprobación de DMARC. Si ves dos o más registros DMARC, elimina los duplicados inmediatamente.
Nombre o tipo de registro DNS incorrecto
Causa: El nombre o el tipo de tu registro DNS no es válido; por ejemplo, se ha configurado un registro MX en lugar de un registro TXT para DMARC.
Solución:
- Tipo de registro: TXT (no A, CNAME, MX, etc.)
- Nombre del registro: _dmarc (algunos proveedores de DNS añaden automáticamente tu dominio; otros requieren _dmarc.tudominio.com)
Errores comunes:
- Añadir un registro DMARC como registro A o CNAME
- Publicar en el dominio raíz (tudominio.com) en lugar de _dmarc.tudominio.com
- Errores ortográficos como _dmrc o dmarc (falta el guión bajo)
Consulta tu gestor de DNS para comprobar el nombre y el tipo exactos.
¿Necesitas más ayuda? Guía completa de resolución de problemas
Si tienes problemas relacionados con errores de alineación de SPF/DKIM, fallos de remitentes externos o mensajes legítimos que van a parar a la carpeta de spam, consulta la guía completa de resolución de problemas de DMARC.
Registros DMARC para dominios que no envían correo y dominios aparcados
Aunque tu dominio no envíe correos electrónicos, los atacantes pueden suplantar su identidad para enviar mensajes de phishing a tus clientes. Protege los dominios inactivos y aparcados con un registro DMARC restrictivo.
Registro recomendado para un dominio que no envía mensajes
v=DMARC1; p=rechazar; sp=rechazar; np=rechazar; adkim=s; aspf=s
Qué hace esto:
- p=rechazar; sp=rechazar; np=rechazar: Rechazar todos los correos electrónicos no autorizados
- adkim=s; aspf=s: Requiere una alineación estricta (sin coincidencia flexible)
- No rua=: No se supervisan los informes (el dominio no los envía)
Por qué se eligen como objetivo los dominios que no envían mensajes
Los atacantes pueden registrar dominios similares o comprometer los dominios inactivos de tu cartera. Un dominio aparcado sin registro DMARC parece un blanco fácil para la suplantación de identidad. Establecer «p=reject» de forma generalizada evita:
- Correos electrónicos de phishing enviados desde tus dominios «company.old» o «company.test»
- Daños a la reputación
- Abuso no detectado (si no se denunciara, nunca se sabría que ha ocurrido)
Próximos pasos tras la publicación de DMARC
La configuración «p=none» (modo de supervisión) no ofrece ninguna protección, sino que únicamente recopila datos. Para proteger tu dominio contra la suplantación de identidad y el phishing, debes ir pasando progresivamente a la configuración de aplicación.
Enfoque en tres fases:
- Supervisión (p = ninguna): Revisa los informes DMARC durante 1-2 semanas. Identifica a todos los remitentes legítimos y a los terceros que envían mensajes en tu nombre (herramientas SaaS, plataformas de marketing, sistemas de gestión de incidencias).
- Transición (p = cuarentena): Desvía el tráfico sospechoso a la carpeta de spam. Mantén esta fase durante 1 a 4 semanas mientras supervisas el volumen de informes. Si se está poniendo en cuarentena correo legítimo, significa que has detectado un remitente que necesita configurar SPF o DKIM.
- Aplicar (p = rechazar): Rechazar por completo los correos electrónicos no autorizados. Solo se debe pasar a esta opción tras confirmar que todos los remitentes legítimos están en regla.
Gestión de DMARC a gran escala para múltiples dominios
Si gestionas varios dominios, editar los registros DNS uno por uno resulta lento y propenso a errores. La solución Hosted DMARC de PowerDMARC automatiza la gestión de los registros en toda tu cartera.
Ventajas:
- Gestiona un número ilimitado de dominios desde un único panel de control
- Actualizaciones masivas de políticas (aplicar «aceptar» o «rechazar» en 50 dominios a la vez)
- La inteligencia sobre amenazas basada en la IA identifica los intentos de suplantación de identidad
- Una incorporación de primera clase y asistencia especializada
Infórmate sobre DMARC alojado.
Preguntas frecuentes
1. ¿Necesito DMARC si ya tengo SPF y DKIM?
Sí. SPF y DKIM son mecanismos de autenticación individuales, pero sin DMARC no existe una política que indique a los destinatarios qué deben hacer cuando fallan esas comprobaciones. DMARC también permite la generación de informes agregados, sin los cuales no se tiene visibilidad sobre quién envía correos electrónicos desde tu dominio.
2. ¿Qué ocurre si no tengo un registro DMARC?
Sin DMARC, los servidores receptores toman sus propias decisiones respecto al correo electrónico no autenticado, y tu dominio queda más expuesto a la suplantación de identidad y al phishing. Varios proveedores de servicios de correo electrónico (ESP) exigen el uso de DMARC a los remitentes masivos, y no cumplir con este requisito puede afectar significativamente a la capacidad de entrega.
3. ¿Se aplica DMARC automáticamente a los subdominios?
Los subdominios heredan la política DMARC del dominio principal, a menos que se anule. Utiliza la etiqueta sp= para establecer una política diferente para los subdominios existentes, y la etiqueta np= (nueva en el RFC 9989) para establecer la política de los subdominios que aún no existen. Establecer sp=reject manteniendo p=quarantine es una práctica habitual para garantizar una protección más estricta de los subdominios.
4. ¿Es obligatorio el uso de DMARC para cumplir con la norma PCI DSS v4.0?
La norma PCI DSS v4.0, que entró plenamente en vigor en 2025, exige controles contra el phishing a las organizaciones que procesan datos de tarjetas de pago. Aunque DMARC no es un requisito explícito para el cumplimiento de la norma, su implementación puede ayudarte a cumplir con los requisitos.
- Cómo configurar DMARC: guía completa de configuración paso a paso (2026) - 20 de junio de 2026
- Cómo interpretar los informes DMARC: una guía completa sobre RUA y RUF - 10 de junio de 2026
- ¿Qué es DMARC? Definición, cómo funciona y por qué es importante - 28 de abril de 2026
