Cómo configurar DMARC: guía completa de configuración paso a paso (2026)

Los proveedores de correo electrónico ya no consideran la configuración de DMARC como una medida de seguridad «opcional». Dado que Gmail, Yahoo y Microsoft están aplicando requisitos de autenticación más estrictos, las organizaciones que no hayan implementado DMARC corren el riesgo de que sus mensajes sean rechazados de forma permanente, de sufrir un aumento de los ataques de suplantación de identidad y de enfrentarse a problemas de cumplimiento normativo.

En esta guía, aprenderás a configurar DMARC desde cero, a validar tu configuración de SPF y DKIM, a publicar un registro DMARC conforme a la normativa y a pasar gradualmente del modo de supervisión a la aplicación completa. También abordaremos las últimas actualizaciones del RFC 9989, los errores de configuración más comunes y consejos prácticos para la resolución de problemas, con el fin de ayudarte a implementar DMARC con confianza.

Al finalizar esta guía de configuración de DMARC, dispondrás de una hoja de ruta clara para proteger tu dominio frente a los ataques de suplantación de identidad, al tiempo que garantizas que los correos electrónicos legítimos sigan llegando a la bandeja de entrada.

Cumplimiento normativo de 2026: ya se ha puesto en marcha la aplicación de la normativa

Gmail y Yahoo (noviembre de 2025): Ya está en vigor la aplicación permanente del rechazo 5xx para los remitentes masivos (más de 5.000 correos electrónicos al día). Los mensajes que no cumplan los requisitos se rechazan de forma permanente, no solo se filtran.

Microsoft Outlook (mayo de 2025): verificación de SPF, DKIM y DMARC activa. Los mensajes que no cumplan los requisitos podrán ser aplazados o rechazados.

PCI DSS v4.0 (marzo de 2025): controles contra el phishing obligatorios para todas las entidades que gestionan datos de tarjetas de pago.

• CISA BOD 18-01: Todas las agencias federales de EE. UU. deben implementar DMARC con la política «p=reject».
• Consulta los requisitos completos: Requisitos globales y regionales de DMARC

¿Qué es DMARC y cómo funciona?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) es un protocolo de autenticación de correo electrónico que permite a los propietarios de dominios indicar a los servidores de correo receptores qué hacer con los mensajes que no superan las comprobaciones de autenticación SPF y DKIM. En pocas palabras, evita que otros suplanten tu dominio e indica a los destinatarios cómo actuar ante los impostores.

DMARC se basa en dos protocolos ya existentes: SPF y DKIM. Juntos, los tres constituyen la base de la seguridad moderna del correo electrónico.

DMARC, SPF y DKIM: cómo funcionan conjuntamente

El SPF (Sender Policy Framework) autoriza a los servidores de correo que pueden enviar mensajes de correo electrónico desde tu dominio. Se trata de un registro DNS que indica: «Solo estas direcciones IP pueden enviar mensajes de correo que afirmen proceder de example.com».

DKIM (DomainKeys Identified Mail) aplica una firma criptográfica a tus correos electrónicos. Esto demuestra que el mensaje procede de ti y que no ha sido modificado durante el envío. La firma se verifica mediante una clave pública publicada en tu DNS.

DMARC los une. Dice lo siguiente: «Esta es mi política. Si un correo electrónico afirma proceder de mi dominio, debe superar la verificación de SPF o DKIM. Si no la supera, esto es lo que quiero que hagáis: nada (solo supervisar), poner en cuarentena (enviar a la carpeta de spam) o rechazar (bloquear por completo)».

Descubre más sobre DMARC, SPF y DKIM en nuestra guía completa.

¿Qué ocurre cuando un correo electrónico no supera la verificación DMARC?

Cuando un destinatario recibe un correo electrónico que afirma proceder de tu dominio, lo compara con tu política DMARC. El resultado depende de tu política:

• p=none (supervisión): El correo electrónico se envía independientemente del resultado. Se recibe un informe en el que se indica qué elementos se han superado y cuáles han fallado.
• p=cuarentena: Los correos electrónicos no válidos se envían a la carpeta de spam o correo no deseado. Los correos legítimos siguen llegando.
• p=rechazar: Los correos electrónicos con error se rechazan directamente. El remitente recibe un mensaje de devolución.

Antes de configurar DMARC: requisitos previos e inventario de remitentes

Muchas organizaciones se apresuran a implementar DMARC y pasan rápidamente al valor «p=reject», solo para descubrir que se están bloqueando remitentes legítimos (sistemas de gestión de relaciones con los clientes, proveedores de servicios de correo electrónico, servicios de asistencia técnica y plataformas de automatización de marketing). En esta sección se explica paso a paso el proceso de auditoría para evitar ese costoso error.

Paso 1: Comprueba que el SPF esté publicado para tu dominio

Para que DMARC funcione, tu dominio debe tener un registro SPF válido en el DNS.

1. Utiliza nuestro verificador de SPF para comprobar que tu registro SPF existe.

2. Comprueba que exista exactamente un registro TXT de SPF para tu dominio. Si hay dos registros SPF, el SPF dejará de funcionar, ya que los destinatarios ignorarán ambos.

3. El registro debería tener un aspecto similar al siguiente: v=spf1 include:sendgrid.net include:mailchimp.com ~all

Si el registro SPF no está publicado o hay dos registros que entran en conflicto, soluciona este problema antes de continuar. Utiliza nuestra herramienta gratuita para crear tu registro SPF ahora mismo.

Paso 2: Comprueba el límite de consultas del SPF 10

SPF permite un máximo de 10 consultas DNS por evaluación de mensaje. Cada remitente externo que autorices (mediante «include:») consume entre 1 y 3 de estas consultas. Si se supera el límite, el SPF dará error para algunos remitentes.

1. Utiliza nuestro «SPF Checker» para consultar el número de consultas de tu registro SPF

2. Cuenta las consultas DNS necesarias. Si te acercas a 10 o las superas, aparecerá un error.

3. Si superas el límite, optimiza tu registro para agrupar las consultas sustituyendo las instrucciones «include:» por direcciones IP explícitas. Este es un obstáculo habitual para las grandes organizaciones que cuentan con muchos remitentes externos.

Paso 3: Comprueba que DKIM esté configurado para todos los remitentes

Google, Yahoo y Microsoft exigen el uso de DKIM a los remitentes masivos; no es opcional.

1. Para tu dominio principal: utiliza nuestro verificador DKIM gratuito para comprobar que tu registro DKIM está publicado.

2. Para cada remitente externo (Salesforce, HubSpot, Klaviyo, etc.): comprueba que hayan activado la firma DKIM y que hayan publicado su clave pública como registro DNS. Para ello, normalmente es necesario pedir al proveedor que «active el DKIM personalizado para tu dominio».

3. Cada remitente debe tener un selector DKIM único (por ejemplo, k1._domainkey.example.com, sendgrid._domainkey.example.com).

Si no tienes DKIM, configúralo ahora antes de pasar a la aplicación de DMARC. Utiliza nuestra herramienta gratuita para generar un registro DKIM para tu dominio.

Paso 4: Hacer un inventario de todos los remitentes de correo electrónico externos

Crea una lista de todos los servicios que envían correos electrónicos desde tu dominio:

• Proveedores de servicios de correo electrónico (SendGrid, Mailchimp, Klaviyo, etc.)
• CRM (Salesforce, HubSpot, Pipedrive, etc.)
• Sistemas de atención al cliente y soporte técnico (Zendesk, Freshdesk, etc.)
• Automatización del marketing (Marketo, Pardot, ActiveCampaign, etc.)
• Plataformas de correo electrónico transaccional (Auth0, Stripe, AWS SES, etc.)
• Servidores o aplicaciones internas que envían notificaciones
• Servicios de reenvío o gestores de listas de correo

Para cada remitente, comprueba lo siguiente:

1. Cumplen con la alineación SPF (incluida en tu registro SPF)
2. Superan la verificación DKIM (la firma DKIM está activada para tu dominio)
3. Están configurados para utilizar tu dominio en el encabezado «De:»

Utiliza nuestro analizador de informes DMARC para detectar remitentes no autorizados.

Paso 5: Comprueba si ya existe un registro DMARC

Utiliza nuestro verificador DMARC para comprobar si tu dominio ya tiene un registro DMARC.

• Si ves «p=none»: tu dominio se encuentra en modo de supervisión. Esta guía te ayudará a pasar de forma segura al modo de aplicación.
• Si ves etiquetas obsoletas (pct=, rf=, ri=): estas ya no forman parte del estándar RFC 9989 y deben eliminarse la próxima vez que edites el registro.
• Si no se ha encontrado ningún registro: Empieza desde cero. Pasa a la siguiente sección.

Cómo configurar DMARC: paso a paso

Paso 1: Generar un registro DMARC

Utiliza nuestra herramienta «DMARC Generator» para crear tu registro inicial.

Campos obligatorios:

• Dominio: Tu dominio (p. ej., example.com)
• Política: Empezar con p=none (modo de supervisión, sin aplicación)
• Dirección de envío de informes: Correo electrónico en el que deseas recibir los informes resumidos (p. ej., [email protected])

Complementos recomendados:

• np=reject: Protege los subdominios inexistentes contra la suplantación de identidad (novedad en RFC 9989, coste cero)
• Dirección rua: Destino del informe agregado (fundamental para la supervisión)

Ejemplo de registro inicial:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Este registro indica a los servidores de correo: «Supervisad los correos electrónicos procedentes de mi dominio y enviadme informes diarios, pero no bloqueéis nada por el momento».

Paso 2: Familiarízate con tu registro DMARC antes de publicarlo

Un registro DMARC es una cadena de pares «etiqueta-valor» separados por punto y coma. Solo son obligatorios «v=» y «p=»; el resto es opcional, aunque se recomienda incluirlo. Antes de publicarlo, es importante que comprendas la función de cada etiqueta:

Etiquetas obligatorias

Etiqueta	Descripción y normas
v= (versión)	• Valor: Siempre v=DMARC1 • Debe ser la primera etiqueta del registro • Solo hay un valor válido
p = (política)	• Valores: none, quarantine, o reject • Indica a los destinatarios cómo gestionar los correos electrónicos que no superan las comprobaciones de DMARC • Consulte la tabla de pólizas que figura a continuación para conocer las diferencias

Etiquetas opcionales

np = (política de subdominios inexistente)

• Valores: ninguno, cuarentena o rechazo
• Aplica una política a los subdominios que no tienen un registro DMARC
• Protege contra la suplantación de subdominios aleatorios (por ejemplo, random123.example.com)
• Recomendación: Establecer np=reject para todos los dominios. No cuesta nada y elimina una vulnerabilidad relacionada con la suplantación de identidad.

rua= (dirección de referencia para los informes agregados)

• Formato: rua=mailto:[email protected]
• Se pueden incluir varias direcciones separadas por comas: rua=mailto:[email protected],mailto:[email protected]
• Los informes agregados son resúmenes en formato XML que envían diariamente los receptores
• Esto es fundamental para la supervisión. Sin ello, no tendrás visibilidad sobre el flujo de tu correo.

sp= (política de subdominio)

• Valores: ninguno, cuarentena o rechazo
• Aplica una política a los subdominios que tienen un registro DMARC
• Si no se especifica, se recurre a la política principal (p=)
• Úsalo cuando quieras aplicar una política más estricta en los subdominios (por ejemplo, mail.example.com)

fo= (opciones de notificación de fallos)

• Valores: 0 (por defecto), 1, d, s o combinaciones (0:1:d:s)
• Controla cuándo se envían los informes forenses (de fallos)
• fo=0: Generar informes solo si fallan todos los mecanismos de autenticación
• fo=1: Generar informes si falla algún mecanismo de autenticación (más detallado, útil para la fase de configuración)
• Se suele utilizar junto con la etiqueta «ruf=» (véase más abajo)
• Recomendación: Utiliza fo=1 durante la configuración inicial para detectar todos los fallos; cambia a fo=0 una vez que estés seguro de que la alineación es correcta.

adkim= (modo de alineación DKIM)

• Valores: r (flexible, por defecto) o s (estricto)
• Condición «Relaxed»: el dominio y el dominio firmado con DKIM comparten el mismo dominio de la organización (por ejemplo, mail.example.com y example.com coinciden).
• Estricto: los dominios deben coincidir exactamente
• Recomendación: Empieza con adkim=r (régimen flexible). Pasa al régimen estricto solo cuando tengas controladas todas las fuentes de firma.

aspf= (modo de alineación SPF)

• Valores: r (flexible, por defecto) o s (estricto)
• Relajado: El dominio y el dominio de la ruta de retorno (Return-Path) del SPF comparten el mismo dominio organizativo.
• Estricto: los dominios deben coincidir exactamente
• Recomendación: Empieza con «aspf=r». Pasa al modo «strict» solo cuando tengas controladas todas las fuentes de envío.

t = (modo de prueba)

• Valores: y (modo de prueba activado) u omitido (modo de prueba desactivado)
• Cuando se establece en t=y, indica a los receptores que apliquen tu política un nivel más abajo.
• p = cuarentena; t = se comporta como si p = ninguno para los receptores
• p = rechazar; t = sí se comporta como p = cuarentena para los destinatarios
• Esta es la alternativa a la etiqueta «pct=», que ha quedado obsoleta.
• Utilizar al pasar a una política más estricta: publicar con t=y, supervisar los informes y, a continuación, eliminar t=y para hacer cumplir la política.

ruf= (dirección del informe forense)

• Formato: ruf=mailto:[email protected]
• Envía copias en tiempo real de los mensajes que no superan la autenticación
• Nota importante: Google, Microsoft y Yahoo ya no envían informes forenses (según la RFC 9989). Se puede incluir esta etiqueta sin problema, pero no generará informes de los principales receptores.
• Inclúyelo solo si dispones de un sistema automatizado para procesar informes forenses

Etiquetas obsoletas y eliminadas (RFC 9989)

Estas etiquetas formaban parte de la RFC 7489, pero ya no forman parte del estándar. No las añadas a los nuevos registros. Si aparecen en registros existentes, elimínalas la próxima vez que edites el DNS.

pct=

• Se utilizaba para aplicar una política a un porcentaje de los mensajes fallidos
• Los resultados obtenidos variaron de un receptor a otro
• Sustitución: Utiliza t=y para una implantación por fases en su lugar
• Si sigue apareciendo en registros antiguos, los receptores que cumplan con la norma RFC 9989 lo ignorarán.

rf=

• ¿Era la etiqueta del formato del informe de error (que solo ha utilizado un valor: afrf)?
• Se ha eliminado porque los informes actuales utilizan un mecanismo diferente

ri=

• ¿Era la etiqueta de intervalo del informe?
• Se ha eliminado porque los intervalos de notificación ahora están estandarizados

Paso 2: Inicia sesión en tu proveedor de DNS

Inicia sesión en tu consola de gestión de DNS (GoDaddy, Cloudflare, Namecheap, cPanel, Route 53, etc.).

Paso 3: Añadir el registro DMARC a través del proveedor de DNS

Busca la opción para añadir un nuevo registro TXT, copia y pega el valor de la herramienta y haz clic en el icono «Guardar».

El proceso es el mismo para todos los proveedores: añade un nuevo registro TXT, establece el nombre como _dmarc, pega tu registro como valor y guarda los cambios. En la tabla siguiente se indican las rutas de navegación específicas de cada proveedor y los problemas más habituales de cada uno.

Paso 5: Espera a que se produzca la propagación del DNS

Los cambios en el DNS pueden tardar hasta 48 horas en propagarse a nivel mundial, aunque la mayoría de los proveedores de DNS los propagan en un plazo de 1 a 2 horas. Para supervisar la propagación en tiempo real, puedes utilizar nuestra herramienta de comprobación de propagación de DNS. Solo tienes que introducir tu dominio y buscar el registro TXT _dmarc.

Paso 6: Comprueba que tu configuración de DMARC esté activa

Una vez que se haya completado la propagación del DNS, comprueba tu registro con nuestra herramienta DMARC Checker.

1. Introduce tu nombre de dominio
2. Haz clic en «Buscar»
3. Deberías ver tu registro con todas las etiquetas analizadas.
4. Si la herramienta de comprobación muestra el mensaje «Se ha encontrado un registro DMARC» con tu política, ya está activo.

Si detectas errores o no se encuentra el registro al cabo de 48 horas, comprueba si hay errores de sintaxis o de configuración en tu entrada DNS.

Configuración de DMARC según el RFC 9989: qué ha cambiado en 2026

En mayo de 2026, el IETF publicó el RFC 9989, que sustituye al RFC 7489 como estándar oficial de DMARC. Tus registros v=DMARC1 actuales siguen siendo totalmente válidos, por lo que no es necesaria una migración urgente. Sin embargo, hay tres cambios que afectan a cualquiera que configure DMARC en la actualidad.

Qué implica el RFC 9989 para tu configuración de DMARC

1. «pct=» ya no se utiliza

La etiqueta «pct=» se utilizaba para aplicar una política a un porcentaje de los mensajes rechazados. Daba lugar a resultados inconsistentes entre los distintos receptores y ya no forma parte del estándar.

Acción: Elimina «pct=» de cualquier registro nuevo. Si los registros antiguos lo contienen, elimínalo la próxima vez que edites el DNS. Los destinatarios lo ignorarán, pero genera confusión.

2. np= es nuevo

La etiqueta «np=» (política de subdominios inexistentes) permite proteger los subdominios que no existen. Los atacantes pueden suplantar subdominios aleatorios (por ejemplo, random123.example.com) para eludir las comprobaciones de DMARC. Establecer «np=reject» subsana esta vulnerabilidad sin ningún coste.

Acción: Es opcional, pero puedes optar por añadirla a todos los registros nuevos.

3. «t=y» es la nueva forma de introducir cambios en las políticas

La etiqueta «t=y» indica a los receptores que apliquen tu política un nivel por debajo del declarado. Esto te permite probar una política más estricta antes de comprometerte a aplicarla.

• p = cuarentena; t = se comporta como si p = ninguna (los receptores no ponen en cuarentena; entregan y notifican)
• p = rechazar; t = y se comporta como p = cuarentena (los receptores ponen en cuarentena en lugar de rechazar)

Acción: Al pasar de p=ninguno a p=cuarentena o p=rechazo, utiliza primero t=y. Supervisa los informes durante 1-2 semanas. Una vez que estés seguro, elimina t=y para que se aplique la medida.

Cómo utilizar «t=y» para una implantación por fases

Este es el proceso exacto:

1. Situación actual:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

2. Cuando estés listo para probar la cuarentena, publica:

v=DMARC1; p=cuarentena; t=s; np=rechazar; sp=cuarentena; rua=mailto:[email protected]

Los destinatarios lo tratan como si p = ninguno: entregan todo y lo notifican. Se realiza un seguimiento durante 1 o 2 semanas.

3. Comprueba que ningún correo legítimo se haya visto afectado y, a continuación, elimina «t=y» para aplicar el cambio:

v=DMARC1; p=cuarentena; np=rechazo; sp=cuarentena; rua=mailto:[email protected]

4. Ahora, los correos que no se entregan van a parar a la carpeta de spam, mientras que los correos legítimos no se ven afectados.

5. Cuando estés listo para probar la política de rechazo, publica:

v=DMARC1; p=rechazar; t=s; np=rechazar; sp=rechazar; rua=mailto:[email protected]

6. Los destinatarios deben considerar esto como una cuarentena. Debes permanecer en observación durante 1 o 2 semanas.

7. Ejecución final: Eliminar t=y:

v=DMARC1; p=rechazar; np=rechazar; sp=rechazar; rua=mailto:[email protected]

8. El rechazo total ya está activo.

Si algo falla en cualquier paso: elimina t=y, retrocede un nivel de política, corrige el emisor defectuoso y, a continuación, vuelve a avanzar.

Cómo mejorar tu política DMARC de forma segura

La mayoría de los errores de DMARC se producen porque las organizaciones pasan directamente a «p=reject» sin verificar primero su flujo de correo. El correo legítimo queda bloqueado, los usuarios se quejan y el propietario del dominio da marcha atrás presa del pánico. En esta sección se explica el enfoque adecuado: una implantación en tres fases que utiliza informes agregados para generar confianza antes de cada paso.

Nota: El RFC 9989 establece explícitamente que los destinatarios deben tratar «p=reject» como «p=quarantine» en el caso de los flujos de correo indirectos (reenvío, listas de correo). Para los dominios cuyos usuarios participan en listas de correo, «p=quarantine» es la política de aplicación permanente más segura. Para los dominios puramente transaccionales o dedicados exclusivamente al marketing, que no cuentan con buzones de correo de usuarios, lo adecuado es «p=reject».

Fase 1: Seguimiento (p = ninguna)

Duración: entre 2 y 4 semanas como mínimo. Más tiempo en el caso de entornos de envío complejos (más de 10 remitentes externos).

Así es como se ve tu historial:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Qué hacer:

1. Publicar el registro anterior

2. Espera a que los receptores envíen los informes agregados (normalmente comienzan a hacerlo en un plazo de 24 a 48 horas)

3. Utiliza nuestro analizador de informes DMARC para revisar los informes diarios

4. Busca:

• Todas las fuentes emisoras conocidas que aparecen en los informes
• Índices de superación de SPF y DKIM por remitente
• Cualquier remitente desconocido que no reconozcas
• Estado de la alineación (¿tus remitentes superan o no la alineación?)

Cuándo avanzar:

• Todos los remitentes legítimos superan las comprobaciones de SPF o DKIM
• No se incluyen fuentes desconocidas en los informes
• Has recopilado datos de forma constante durante al menos dos semanas
• Ya has solucionado los problemas de los remitentes que fallaban

Si eres nuevo en el tema de los informes DMARC, consulta nuestra guía sobre cómo interpretar los informes DMARC para obtener una explicación sencilla paso a paso.

Fase 2: Cuarentena (p = cuarentena)

Duración: 1-2 semanas en modo de prueba (t=y), y a continuación de forma continua.

Paso A: Prueba con t=y (simulación)

Publicar:

v=DMARC1; p=cuarentena; t=s; np=rechazo; sp=cuarentena; rua=mailto:[email protected]

Cuando t = y, los receptores aplican la política un nivel más abajo: la cuarentena se comporta como si no existiera. Los mensajes fallidos se siguen entregando; simplemente recibes informes que indican qué mensajes se habrían puesto en cuarentena.

Realiza un seguimiento durante 1 o 2 semanas. Revisa los informes y mantén un control de tu bandeja de entrada. Presta atención a lo siguiente:

• Sigue llegando correo legítimo
• Informes de errores en los que se indica qué remitentes se verían afectados
• Índices habituales de denuncias por spam

Paso B: Aplicar (eliminar t=y)

Cuando estés seguro, elimina t=y:

v=DMARC1; p=cuarentena; np=rechazo; sp=cuarentena; rua=mailto:[email protected]

Ahora los correos que no se pueden entregar van a parar a la carpeta de spam. Los correos legítimos siguen llegando con normalidad.

Seguimiento continuo:

• Revisar los informes agregados semanalmente
• Revisa la carpeta de spam en busca de correos legítimos
• Si los remitentes legítimos empiezan a fallar: vuelve inmediatamente a p=none, soluciona el problema de alineación y, a continuación, vuelve a avanzar.

Nota sobre los requisitos de BIMI: Si deseas utilizar BIMI (Brand Indicators for Message Identification) para mostrar tu logotipo en Gmail, debes tener configurado «p=quarantine» o «p=reject». La opción «p=none» no cumple los requisitos. Esto hace que sea aún más urgente avanzar en la política. A continuación te explicamos cómo habilitar BIMI para tu dominio.

Fase 3: Rechazo (p = rechazo)

Duración: 1-2 semanas con t=y, y a partir de ahí de forma continua.

Paso A: Prueba con t=y (simulación)

Publicar:

v=DMARC1; p=rechazar; t=s; np=rechazar; sp=rechazar; rua=mailto:[email protected]

Con t=y, los receptores tratan los mensajes rechazados como si estuvieran en cuarentena. Los mensajes fallidos van a la carpeta de spam, no se rechazan directamente. Vigílalo durante 1-2 semanas.

Paso B: Aplicar (eliminar t=y)

v=DMARC1; p=rechazar; np=rechazar; sp=rechazar; rua=mailto:[email protected]

Ahora, los correos con error se rechazan directamente. El remitente recibe un mensaje de devolución.

Recomendaciones de política:

• Si tu dominio cuenta con buzones de correo de usuarios que figuran en listas de distribución (NAR, MLS, listas de asociaciones, etc.), utiliza «p=quarantine» como política de aplicación.
• Si tu dominio es exclusivamente transaccional (SaaS, pagos, fintech, correos electrónicos de marketing sin buzones de correo de usuarios): utiliza p=reject.

Solución de problemas en la configuración de DMARC: problemas habituales y soluciones

Problema 1: «No se ha encontrado ningún registro DMARC» al realizar la comprobación

Por qué ocurre esto: la propagación del DNS aún no se ha completado, o bien has introducido el nombre de host de forma incorrecta.

Cómo solucionarlo:

1. Espera entre 24 y 72 horas después de la publicación
2. Comprueba bien que el nombre de host sea exactamente _dmarc (y no _dmarc.tudominio.com, como ocurre en algunas herramientas; consulta con tu proveedor específico).
3. Utiliza nuestra herramienta de comprobación de la propagación del DNS para verificar el estado de la propagación
4. Prueba de nuevo nuestro verificador DMARC

Problema n.º 2: SPF y DKIM no están alineados

Por qué ocurre: El dominio que figura en el encabezado «De:» no coincide con el dominio autenticado por SPF o DKIM.

Ejemplo de fallo:

• En el encabezado de «De:» figura [email protected]
• El dominio autenticado por SPF es mail.otherdomain.com
• El dominio de firma DKIM es newsletter.anotherdomain.com
• Resultado: No hay coincidencia. DMARC falla.

Cómo solucionarlo:

1. Empieza con una alineación relajada (adkim=r; aspf=r) en tu registro. Esto permite coincidencias de subdominios.

2. Utiliza nuestro verificador DKIM para comprobar el dominio de firma de cada remitente

3. Utiliza nuestro verificador de SPF para comprobar que cada remitente figure en la lista de SPF

4. Para cada remitente con problemas, pide al proveedor que configure el dominio. Por ejemplo:

• «Por favor, activa la firma DKIM para el dominio example.com (no es un subdominio)».
• «Por favor, utiliza example.com como dominio en el campo Return-Path/envelope-from».

5. Una vez que todos los remitentes superen la comprobación con la alineación «relaxed», puedes pasar a la «strict» (adkim=s; aspf=s) si lo deseas.

Problema n.º 3: Fallo en la autenticación de un remitente externo

Por qué ocurre esto: una plataforma de correo electrónico (ESP), de gestión de relaciones con los clientes (CRM) o de marketing está enviando correos electrónicos desde tu dominio, pero no está configurada en tu registro SPF y/o no tiene habilitado DKIM.

Cómo solucionarlo:

En caso de fallos del SPF:

1. Obtén la entrada SPF del remitente de su documentación (por ejemplo, include:sendgrid.net)

2. Añádelo a tu registro SPF: v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. Prueba con nuestro verificador de SPF

En caso de errores de DKIM:

1. Pide al proveedor que active el DKIM personalizado para tu dominio

2. Publica la clave pública DKIM que te faciliten (normalmente con el formato: selector._domainkey.tudominio.com)

3. Compruébalo con nuestro verificador DKIM

Problema 4: Varios registros SPF o un número de consultas SPF superior al límite de 10

1. Más de un registro SPF: tener dos registros TXT de SPF en el mismo dominio invalida por completo el SPF, y los destinatarios ignorarán ambos.

Cómo solucionarlo: Combina tus registros SPF en uno solo, ya que solo puedes tener un único registro TXT SPF por dominio.

Por ejemplo:

• Entrada antigua 1: v=spf1 include:sendgrid.net ~all
• Registro antiguo 2: v=spf1 include:mailchimp.com ~all
• Nuevo registro fusionado: v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. Más de 10 consultas DNS: cada una de ellas puede requerir entre 1 y 3 consultas DNS. Si se superan las 10, la validación SPF fallará para algunos remitentes.

Cómo solucionarlo: Utiliza nuestro SPF alojado para optimizar dinámicamente tu registro. De este modo, se sustituyen las instrucciones «include:» por direcciones IP explícitas, lo que reduce el número de consultas.

Por ejemplo:

• Antes (más de 10 consultas): v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• Tras la optimización: v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

Problema n.º 5: El correo legítimo va a parar a la carpeta de spam tras pasar por cuarentena

Por qué ocurre: Has pasado a la fase p=cuarentena antes de comprobar que todos los remitentes legítimos superan la autenticación.

Cómo solucionarlo:

1. Volver inmediatamente a p=none
2. Revisa tus informes agregados para identificar qué remitente está fallando
3. Corregir su autenticación (alineación de SPF o DKIM)
4. Volver a pasar a p=cuarentena, pero realizar la prueba con t=y y realizar un seguimiento durante 1-2 semanas antes de aplicar la medida.

N.º 6: Errores de sintaxis en los registros DMARC

Por qué ocurre: un error tipográfico en el registro, la falta de puntos y comas o etiquetas no admitidas

Cómo solucionarlo:

1. Compruébalo con nuestro verificador DMARC, ya que te mostrará los errores de sintaxis.
2. Utiliza nuestro generador de DMARC para volver a crear el registro en lugar de editarlo manualmente
3. Copia el registro generado y pégalo en tu proveedor de DNS

Palabras finales

Configurar DMARC correctamente ya no es opcional. La aplicación de la política de rechazo permanente de Gmail, los requisitos de Yahoo y Microsoft, las recomendaciones de la norma PCI DSS v4.0 y la directiva BOD 18-01 de la CISA hacen que DMARC sea una necesidad para cumplir con la normativa.

La forma más segura y fiable de proceder es avanzar poco a poco, verificar constantemente y aplicar las medidas de forma responsable. Pero si quieres una gestión de DMARC más rápida y sencilla, con procesamiento automatizado de informes, supervisión del cumplimiento y asistencia continua, plantéate utilizar una plataforma DMARC alojada como PowerDMARC, que se encarga de la configuración, el escalado y la aplicación de las medidas para que puedas centrarte en la seguridad. Empieza hoy mismo tu prueba gratuita o reserva una demostración para proteger tu dominio ahora mismo.

Preguntas frecuentes

¿Cuánto tiempo lleva configurar DMARC?

La configuración inicial de los registros DNS se realiza en cuestión de minutos. La propagación del DNS puede tardar hasta 72 horas (normalmente entre 1 y 2 horas). La aplicación completa de la política (alcanzar el estado «p=reject» con fiabilidad) suele tardar entre 4 y 8 semanas, dependiendo del número de fuentes emisoras y de la rapidez con la que se resuelvan los problemas de alineación.

¿Afecta la configuración de DMARC a la capacidad de entrega del correo electrónico?

Cuando p=none, el impacto en la capacidad de entrega es nulo, ya que el modo de supervisión no aplica ninguna restricción. Cuando p=quarantine o p=reject, solo se ve afectado el correo no autenticado y que no cumple con los requisitos. El correo debidamente autenticado no se ve afectado y, a menudo, mejora su capacidad de entrega. DMARC puede mejorar la llegada a la bandeja de entrada a largo plazo al establecer la reputación del dominio ante los proveedores de correo electrónico.

¿Cómo configuro DMARC para varios dominios?

Al configurar DMARC para varios dominios, recuerda que cada dominio necesita su propio registro TXT de DMARC en _dmarc.[dominio].

Por ejemplo:

• Dominio 1: Registro TXT de _dmarc.example.com
• Dominio 2: registro TXT de _dmarc.example.org

Para las organizaciones que gestionan numerosos dominios, una plataforma DMARC alojada permite gestionar todos los registros desde un único panel de control, lo que facilita la ampliación del servicio.

¿Qué es la alineación DMARC?

La «alineación» significa que el dominio del encabezado «From:» debe coincidir con el dominio autenticado por SPF o DKIM. La alineación flexible (la configuración predeterminada, adkim=r; aspf=r) permite coincidencias de dominios de la misma organización, mientras que la alineación estricta (adkim=s; aspf=s) exige coincidencias exactas.

• Acerca de
• Últimas publicaciones

Maitham Al Lawati

Experto en ciberseguridad, director general de PowerDMARC

Maitham es un emprendedor tecnológico, experto en ciberseguridad, CEO y fundador de PowerDMARC con más de 15 años de experiencia en el sector. Maitham posee un MBA Global por la Universidad de Manchester y varias certificaciones profesionales, entre ellas CISSP, CISM, CRISC e ISC2 CCSP.

Últimos comentarios de Maitham Al Lawati (ver todos)

• 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