Cómo configurar DMARC para Google Workspace (Gmail)

DMARC para Google Workspace (Gmail) indica a los servidores receptores qué deben hacer cuando los correos electrónicos procedentes de tu dominio no superan las comprobaciones de SPF o DKIM: si deben ponerlos en cuarentena, rechazarlos o simplemente notificarlo. Google Workspace se encarga del envío de correos salientes y de la generación de claves DKIM, pero no publica un registro DMARC por ti. Esa parte corresponde a un registro DNS que debes configurar tú mismo, y es lo único que se interpone entre tu dominio y los ataques de suplantación de identidad.

Desde la entrada en vigor de los requisitos de Google para remitentes masivos en 2024, DMARC ya no es opcional para los remitentes de gran volumen: cualquier dominio que envíe 5.000 mensajes o más al día a Gmail debe contar con un registro DMARC válido o se arriesga a que sus mensajes sean rechazados.

Si quieres saber cómo configurar DMARC específicamente para Gmail, el proceso es el mismo: Gmail utiliza la infraestructura de correo de Google, por lo que los pasos de configuración que se indican a continuación se aplican tanto si tienes un plan personal de Google Workspace como si envías mensajes a través de Gmail para empresas. Esta guía cubre todo lo que necesitas: los requisitos previos de SPF y DKIM, el registro exacto que debes publicar, un desglose de cada etiqueta y una guía paso a paso desde la supervisión (p=none) hasta la aplicación total (p=reject), incluyendo ejemplos de registros y los errores habituales que interrumpen el flujo de correo a lo largo del proceso.

¿Qué es DMARC y por qué lo necesita Google Workspace?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) es un estándar de autenticación de correo electrónico basado en el DNS que integra SPF y DKIM, indica a los servidores receptores cómo gestionar los mensajes que no superan esas comprobaciones y te envía informes sobre quién está utilizando tu dominio para enviar correo.

Esto es lo que la gente pasa por alto: Google Workspace protege el transporte. Cifra las conexiones con TLS, filtra el spam entrante y entrega tu correo saliente de forma fiable. Pero DMARC es un control a nivel de dominio que solo el propietario del dominio puede configurar. Google no publica un registro DMARC por ti, y ningún filtro antispam por parte de Google impide que un atacante suplantara tu dominio para enviar correos de phishing a otras personas. Esa brecha es precisamente la que subsana DMARC.

Además, dejó de ser opcional. Según los requisitos de Google para remitentes masivos que entraron en vigor en febrero de 2024 y siguen intensificándose, cualquier dominio que envíe 5.000 mensajes o más al día a direcciones de Gmail debe publicar un registro DMARC; de lo contrario, Google comenzará a rechazar el correo. Incluso por debajo de ese umbral, DMARC es ahora el requisito mínimo para garantizar una buena capacidad de entrega. 

Si quieres una explicación conceptual completa, consulta nuestra guía detallada sobre qué es DMARC. 

Requisitos previos: configura primero SPF y DKIM

DMARC no autentifica el correo por sí solo. Se superpone a SPF y DKIM y garantiza el cumplimiento de los resultados. Para que DMARC se supere, al menos uno de ellos debe superarse y estar alineado con tu dominio. Así que, antes de publicar un registro DMARC, asegúrate de tener estos dos elementos en marcha. A continuación se muestran las versiones resumidas; cada una incluye un enlace a la guía completa.

SPF para Google Workspace (configuración rápida)

El SPF es un único registro TXT en tu dominio raíz que enumera los servidores autorizados para enviar correo en tu nombre. En el caso de Google Workspace, el registro imprescindible es:

v=spf1 include:_spf.google.com ~all

v=spf1 abre el registro; include:_spf.google.com autoriza los servidores de correo de Google; y ~all rechaza temporalmente todo lo demás. Si envías mensajes a través de servicios adicionales, añade sus inclusiones al mismo registro (nunca crees un segundo registro SPF):

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

Para obtener información detallada sobre el «flattening», las consultas y los casos extremos, consulta nuestro guía sobre registros SPF para Google Workspace .

DKIM para Google Workspace (configuración rápida)

DKIM añade una firma criptográfica a tu correo saliente. Google Workspace genera la clave por ti; tú la publicas en el DNS:

1. En la Consola de administración, ve a Aplicaciones → Google Workspace → Gmail → Autenticar correo electrónico.
2. Selecciona tu dominio y haz clic en «Generar nuevo registro» (se recomienda 2048 bits).
3. Copia el registro TXT que genera Google. Será un nombre de host del tipo google._domainkey y un valor largo que comienza por v=DKIM1; k=rsa; p=….
4. Publica ese registro TXT en tu proveedor de DNS.
5. Vuelve a la consola de administración y haz clic en «Iniciar autenticación».

El registro tiene este aspecto:

Host/Name:  google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

Para ver la guía completa, consulta cómo configurar DKIM para tu dominio.

Note: Google Workspace handles DKIM signing (you generate the key in the Admin Console) and SPF is a DNS record you publish yourself, but Google does not create or publish a DMARC record for your domain. That part is entirely on you, and it's what the rest of this guide covers.

Cómo configurar un registro DMARC para Google Workspace

Una vez que SPF y DKIM estén activos, ya estarás listo para DMARC. A continuación te explicamos el proceso completo, paso a paso.

Paso 1: Crea tu registro DMARC

Un registro DMARC es una entrada TXT única compuesta por etiquetas. Un registro básico sencillo tiene este aspecto:

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

Puedes crearlo de forma visual con nuestro generador de DMARC, que se encarga de armar la sintaxis por ti. A continuación te explicamos qué hace cada etiqueta:

• v: se utiliza para definir la versión del protocolo, que siempre es DMARC1. Se trata de una etiqueta obligatoria
• p: se utiliza para definir el modo de la política DMARC, y también es una etiqueta obligatoria. 
• rua: se utiliza para indicar la dirección de informe global. Se trata de una etiqueta opcional, pero su uso es muy recomendable para supervisar los resultados de la autenticación. 

Note: The one tag people misread is p. p=none, which is the starting point, not the end state, as it only monitors and reports, it doesn't protect anything yet. The goal is to reach p=reject without breaking mail flow.

Paso 2: Publicar el registro en el DNS

DMARC se configura en tu DNS, ya sea en tu registrador de dominios o en tu proveedor de DNS, y no en la Consola de administración de Google. DMARC es un registro DNS, no una configuración de Google Workspace. En tu panel de DNS, añade:

No te preocupes. La propagación del DNS puede tardar hasta 48 horas, aunque normalmente es mucho más rápida, a menudo en menos de una hora.

Paso 3: Verifica tu registro DMARC

Una vez publicado, comprueba que se resuelve correctamente con nuestro verificador de registros DMARC. Si la comprobación se realiza con éxito, se mostrará tu registro y se confirmará que la sintaxis es válida. Por ejemplo, mostrará la política detectada como p=none, una dirección de notificación RUA válida y que no hay errores de sintaxis. Si el verificador no encuentra el registro, espera un poco más a que se propague el DNS o comprueba de nuevo el campo «host/nombre».

Paso 4: Supervisar los informes antes de aplicar las medidas

Con la opción «p=none live» activada, Google y otros servidores receptores comienzan a enviar informes agregados (RUA) a la dirección que figura en tu etiqueta RUA. Estos informes muestran todas las fuentes que envían correo en nombre de tu dominio e indican si cada una de ellas supera o no la verificación de SPF y DKIM.

Lo que debes buscar: fuentes legítimas que estén fallando. Es posible que una plataforma de marketing, un CRM, una herramienta de atención al cliente o un servicio de facturación que utilices realmente no estén correctamente configurados porque su SPF o DKIM aún no estén configurados en tu dominio. Soluciona esos problemas antes de aplicar las medidas; de lo contrario, al pasar a cuarentena o rechazo, empezarás a bloquear tu propio correo. 

Dado que el código XML sin procesar de DMARC es difícil de leer, puedes utilizar nuestro guía «Cómo leer los informes DMARC» para interpretarlos. Se recomienda planificar un periodo de seguimiento de entre 2 y 4 semanas como mínimo, para poder abarcar todo el ciclo de envío.

Paso 5: Pasar a la fase de ejecución (p = cuarentena, luego p = rechazo)

Una vez que tus informes indiquen que todos los remitentes legítimos superan el filtro, endurece la política por etapas:

1. p=ninguna → p=cuarentena: los correos fallidos van a parar a la carpeta de spam en lugar de a la bandeja de entrada. Vuelve a revisar los informes.
2. p=cuarentena → p=rechazo: el correo que no cumple los requisitos se bloquea directamente. Aquí es donde entra en juego la verdadera protección contra la suplantación de identidad.

Para una implementación aún más segura, utiliza el etiqueta t (t=y) para probar tu política antes de aplicar la aplicación máxima. Obtén más información sobre cómo elegir y ajustar tu nivel de aplicación en nuestra guía sobre políticas DMARC .

Ejemplos de registros DMARC de Google Workspace

Tres plantillas listas para copiar que se adaptan a la fase en la que te encuentras. Sustituye las direcciones de correo electrónico por las tuyas.

Supervisión básica (Primeros pasos)

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

Cuarentena con notificación

v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r;

Aplicación íntegra

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s;

Note: the strict alignment here (adkim=s, aspf=s) requires the domain in the DKIM signature or SPF to match your sending domain exactly, with no subdomains. Relaxed (r) allows subdomains to align. Example mail from mail.yourdomain.com still aligns with yourdomain.com. Use relaxed while you're stabilizing, and only switch to strict once you're certain every legitimate sender uses your exact domain.

Errores habituales con DMARC en Google Workspace

Publicar DMARC sin tener implementados SPF ni DKIM

DMARC no tiene nada que aplicar si ni SPF ni DKIM superan las comprobaciones y están alineados. Si se implementa DMARC primero, sobre todo con los niveles de cuarentena o rechazo, tu propio correo podría empezar a fallar. Asegúrate siempre de que SPF y DKIM funcionen correctamente y, a continuación, añade DMARC como capa adicional.

Permanecer en p=none de forma indefinida

«p=none» solo supervisa; no bloquea nada. Muchos dominios lo publican, ven llegar los informes y nunca avanzan. Los suplantadores no se ven afectados hasta que se llega a «p=reject». Considera «none» como una fase de supervisión temporal, no como un objetivo final.

Faltan remitentes de terceros en SPF/DKIM

Las herramientas de marketing, los sistemas CRM, los sistemas de gestión de incidencias y los servicios de facturación envían mensajes «en tu nombre». Si no están autorizados en tu lista de inclusiones del SPF o no firman con un DKIM alineado, no superarán la verificación DMARC y su correo se bloqueará una vez que apliques la política. Utiliza tus informes de supervisión para detectar todos los casos antes de endurecer la política.

Uso de un nombre de host DNS incorrecto

El error sintáctico más frecuente consiste en introducir «_dmarc» en el campo «value» del registro en lugar de en el campo «host/name», o en omitir por completo el guión bajo inicial. El campo «host/name» debe ser «_dmarc» (que se resuelve como «_dmarc.tudominio.com»); el valor es la cadena «v=DMARC1; …».

Tener varios registros DMARC en un mismo dominio

Un dominio solo puede tener un único registro DMARC. Si hay dos o más registros TXT de tipo «_dmarc», los destinatarios ignorarán por completo el DMARC, lo que desactivará tu protección. Si vas a actualizar el registro, edita el existente en lugar de añadir uno segundo.

Cómo PowerDMARC simplifica el uso de DMARC para Google Workspace

El DMARC manual funciona, pero la parte que requiere un seguimiento continuo —como leer informes XML sin procesar, identificar a los remitentes que no cumplen los requisitos y pasar de forma segura de «ninguno» a «rechazar»— es donde la mayoría de los dominios se atascan.

PowerDMARC convierte esos informes XML en paneles de control fáciles de entender, te ofrece un servicio DMARC alojado para que puedas actualizar tu política sin tener que modificar el DNS cada vez, te guía a lo largo del proceso de aplicación automatizada y envía alertas en tiempo real en cuanto una nueva fuente empieza a enviar mensajes en nombre de tu dominio, para que alcances la protección total «p=reject» más rápidamente y sin afectar al correo legítimo.

Preguntas frecuentes

1. ¿Incorpora Google Workspace la tecnología DMARC?

No. Google Workspace se encarga de la seguridad del transporte, el filtrado de correo no deseado y la generación de claves DKIM, pero no crea ni publica un registro DMARC por ti. DMARC es un registro DNS que el propietario del dominio debe publicar por separado.

2. ¿Cómo puedo añadir un registro DMARC a Google Workspace?

No hay que añadirlo en la Consola de administración, sino que hay que publicarlo como un registro TXT en tu proveedor de DNS con el nombre de host _dmarc y un valor del tipo v=DMARC1; p=none; rua=mailto:[email protected].

3. ¿Cuál es el registro DMARC correcto para Google Workspace?

Empieza con v=DMARC1; p=none; rua=mailto:[email protected] para la supervisión, luego pasa a p=quarantine y, por último, a p=reject una vez que tus remitentes legítimos superen la comprobación.

4. ¿Necesito tener SPF y DKIM antes de configurar DMARC?

Sí. DMARC hace cumplir los resultados de SPF y DKIM, por lo que al menos uno de ellos debe estar configurado y alineado para que DMARC pueda superar la comprobación. Se recomienda configurar ambos antes de implementar DMARC. 

5. ¿Qué significa «p=none» en un registro DMARC?

p=none corresponde al modo de supervisión. Los receptores informan de los mensajes que fallan, pero no toman ninguna medida al respecto. Es el punto de partida más seguro, pero no ofrece protección hasta que se pasa al modo de cuarentena o de rechazo.

6. ¿Cuánto tiempo tarda un registro DMARC en empezar a funcionar?

El registro puede propagarse en tan solo unos minutos, aunque los cambios en el DNS pueden tardar hasta 48 horas. Los informes agregados suelen empezar a llegar en uno o dos días.

7. ¿Por qué mis correos electrónicos de Google Workspace siguen sin cumplir con los requisitos de DMARC?

Normalmente, esto ocurre porque un remitente legítimo (a menudo un servicio de terceros) no está autorizado en tu registro SPF o no firma con DKIM alineado. Puedes consultar tus informes agregados para identificar la fuente que provoca el error y corregir su alineación.

8. ¿Es obligatorio el uso de DMARC para cumplir con las directrices de Google para remitentes masivos?

Sí. Según los requisitos de Google para remitentes masivos, los dominios que envíen 5.000 mensajes o más al día a Gmail deben tener un registro DMARC válido; de lo contrario, su correo podría ser rechazado. Puedes consultar nuestra guía de cumplimiento de Google y Yahoo para obtener más detalles.

• Acerca de
• Últimas publicaciones

Ahona Rudra

Experto en seguridad de dominios y correo electrónico en PowerDMARC

Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.

Últimas publicaciones de Ahona Rudra (ver todas)

• ¿Qué es el ARF? Formato de notificación de abusos e informes de fallos de DMARC (RFC 5965) - 24 de julio de 2026
• La mayoría de las entidades financieras cuentan con DMARC. Casi ninguna está protegida. - 22 de julio de 2026
• ¿Qué es la «fatiga de MFA» (push bombing)? - 21 de julio de 2026