Por qué los usuarios de Google Workspace necesitan DMARC

Google Workspace (anteriormente G Suite) enruta el correo electrónico de su empresa a través de los servidores de Google bajo su dominio personalizado. Aunque Google gestiona la entrega de forma fiable, la plataforma no impide automáticamente que terceros suplanten su dominio: es decir, que envíen correo que parezca proceder de cualquiera@sudominio.com sin su autorización.

DMARC cierra esta brecha. Se apoya en SPF y DKIM para dar a los servidores de correo receptores una política clara: si un correo que afirma provenir de su dominio no supera las verificaciones de autenticación, trátelo como sospechoso y póngalo en cuarentena o recházalo. Sin DMARC, los ataques de phishing que suplantan su marca pueden llegar a sus clientes, socios o empleados sin ninguna barrera técnica que los detenga.

La urgencia ha aumentado tras los propios requisitos de remitentes de Google. Google exige ahora que los remitentes que envíen 5.000 o más mensajes diarios a cuentas de Gmail tengan un registro DMARC válido. Las organizaciones que no cumplan este requisito corren el riesgo de que su correo sea rechazado o marcado como spam por Gmail, que con más de 1.800 millones de usuarios activos representa un riesgo de entregabilidad significativo para cualquier empresa.

También existe un beneficio adicional atractivo más allá de la protección. BIMI, el estándar que muestra el logotipo de su marca junto a sus correos en las bandejas de entrada de Gmail, requiere una política DMARC de p=quarantine o p=reject. Configurar DMARC correctamente no es solo una medida de seguridad; es el requisito previo para uno de los beneficios de marca en el correo electrónico más visibles disponibles hoy en día.

Punto clave: Incluso si envía menos de 5.000 correos al día, DMARC protege su dominio para que no sea utilizado en ataques de phishing contra sus clientes. Los pasos de configuración son los mismos independientemente del volumen de envío.

Paso 1: Verifique su registro SPF para Google Workspace

SPF (Sender Policy Framework) especifica qué servidores de correo están autorizados para enviar correo electrónico en nombre de su dominio. Para Google Workspace, el registro SPF correcto es:

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

Este único mecanismo include cubre todos los rangos de IP de los servidores de correo saliente de Google. El calificador ~all es un soft fail: los mensajes de fuentes no autorizadas se marcan como sospechosos en lugar de ser rechazados directamente. Muchas organizaciones comienzan con ~all y más adelante endurecen a -all (hard fail) una vez que tienen la certeza de que todas las fuentes legítimas están cubiertas.

Combinar Google Workspace con otros servicios de envío

Si su dominio también envía a través de otros servicios (una plataforma de marketing, un proveedor de correo transaccional o una herramienta de helpdesk), esos servicios deben incluirse en el mismo registro SPF. Por ejemplo, si usa Google Workspace y también envía a través de SendGrid:

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

Recuerde: cada include: cuenta hacia el límite de 10 consultas DNS. Mantenga su registro SPF liviano y nunca publique más de un registro SPF TXT para el mismo nombre de dominio; los registros duplicados provocan fallos SPF inmediatos.

Después de publicar o actualizar su registro SPF, use el SPF Checker gratuito para confirmar que el registro se resuelve correctamente y cubre todos los rangos de IP que Google utiliza para el correo saliente.

Paso 2: Active DKIM en Google Workspace Admin

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada mensaje saliente. La firma se genera con una clave privada almacenada en los servidores de Google y es verificada por los servidores receptores mediante una clave pública correspondiente que usted publica en su DNS. Esto prueba que el mensaje fue enviado por una fuente autorizada y no ha sido alterado en tránsito.

Google Workspace no activa la firma DKIM para dominios personalizados de forma automática. Es necesario generar la clave y activar la firma desde la Consola de administración.

Cómo activar DKIM en Google Workspace

  1. Inicie sesión en la Consola de administración de Google en admin.google.com.
  2. Vaya a Aplicaciones → Google Workspace → Gmail → Autenticar correo electrónico.
  3. Seleccione el dominio para el que desea configurar DKIM (si tiene varios dominios, repita estos pasos para cada uno).
  4. Haga clic en Generar nuevo registro. Google creará un par de claves RSA de 2048 bits y mostrará el registro DNS TXT que debe publicar.
  5. El registro DNS tendrá el siguiente aspecto: 
    google._domainkey.sudominio.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
    El nombre de host es google._domainkey (o el nombre completo google._domainkey.sudominio.com según su proveedor de DNS).
  6. Copie el valor del registro TXT de la Consola de administración y publíquelo en su proveedor de DNS.
  7. Espere a que se propague el DNS; esto puede tardar hasta 48 horas, aunque la mayoría de los proveedores de DNS lo propagan en una hora o dos.
  8. Vuelva a Aplicaciones → Google Workspace → Gmail → Autenticar correo electrónico y haga clic en Iniciar autenticación para activar la firma DKIM.
No active antes de que el DNS se propague: Si hace clic en Iniciar autenticación antes de que el registro DNS se haya propagado, la verificación de Google fallará. Espere hasta que el registro sea visible en una herramienta de consulta DNS antes de activarlo.

Una vez que DKIM esté activo, use el DKIM Checker para verificar que el selector google._domainkey se resuelve correctamente y devuelve una clave pública válida para su dominio.

Paso 3: Cree y publique su registro DMARC

Con SPF y DKIM configurados, está listo para añadir la capa DMARC. DMARC es un registro DNS TXT que define la política para gestionar los fallos de autenticación y especifica a dónde enviar los informes agregados sobre el tráfico de correo de su dominio.

Comience con una política solo de monitorización. Esto genera informes sin afectar a la entrega del correo, dándole tiempo para identificar todas sus fuentes de envío legítimas antes de aplicar ninguna restricción:

v=DMARC1; p=none; rua=mailto:dmarc@sudominio.com

Publique esto como un registro TXT en su DNS con la siguiente configuración:

  • Nombre / Host: _dmarc (algunos proveedores de DNS requieren el nombre completo: _dmarc.sudominio.com)
  • Tipo: TXT
  • Valor: la cadena del registro DMARC anterior
  • TTL: 3600 (1 hora) es un valor de inicio habitual

La etiqueta rua indica a dónde se enviarán los informes agregados. Reemplace dmarc@sudominio.com con la dirección donde desea recibirlos; idealmente, una bandeja de entrada conectada a una herramienta de informes DMARC que pueda analizar el XML automáticamente.

Use el Generador de DMARC gratuito para construir su registro con la sintaxis correcta. Una vez publicado, verifique que se resuelve correctamente con el DMARC Checker.

Paso 4: Lea sus informes agregados DMARC

Una vez que su registro DMARC esté activo con una dirección rua, los servidores de correo receptores comenzarán a enviar informes agregados a esa dirección. El propio Google envía informes DMARC sobre el correo recibido en Gmail, generalmente en un plazo de 24 horas. Estos informes son la base de un camino seguro hacia la aplicación.

Qué contienen los informes agregados

Cada informe agregado es un archivo XML que cubre un período de 24 horas. Para cada dirección IP que haya enviado correo afirmando ser de su dominio, el informe muestra:

  • La dirección IP de origen y una búsqueda DNS inversa
  • El número de mensajes enviados desde esa fuente
  • Si SPF pasó o falló, y qué dominio fue evaluado
  • Si DKIM pasó o falló, y qué selector se utilizó
  • La disposición DMARC general aplicada (none, quarantine o reject)

Fuentes comunes en los informes de Google Workspace

Cuando empiece a recibir informes DMARC para un dominio de Google Workspace, normalmente verá tráfico de:

  • Los propios servidores de correo de Google: deberían superar SPF y DKIM una vez que ambos estén configurados correctamente.
  • Plataformas de marketing de terceros: herramientas como Mailchimp, HubSpot, Klaviyo o ActiveCampaign que envían correo usando el nombre de su dominio. Cada una necesita su propio include SPF e idealmente su propia clave DKIM.
  • Servicios de reenvío: el correo reenviado a través de servicios de terceros a menudo rompe la alineación SPF (porque la IP del servidor de reenvío no está en su registro SPF) y puede romper DKIM si el mensaje es modificado.
  • Proveedores de correo transaccional: servicios como SendGrid, Postmark o Amazon SES utilizados para notificaciones automáticas o recibos.

El objetivo de la fase de monitorización es dar cuenta de cada fuente que vea en los informes. Cualquier fuente legítima que esté fallando la autenticación debe corregirse antes de pasar a la aplicación.

Convierta los informes XML en paneles de control claros

Los informes agregados DMARC llegan como archivos XML comprimidos adjuntos a correos electrónicos, no están diseñados para ser leídos por humanos. DMARCFlow recopila, analiza y visualiza automáticamente cada informe para que pueda ver de un vistazo qué fuentes están pasando o fallando, seguir las tendencias a lo largo del tiempo e identificar exactamente qué hay que corregir antes de aplicar la política.

Empiece a analizar sus informes DMARC de forma gratuita

Sin tarjeta de crédito. Panel de informes completo desde el primer día.

Paso 5: Alcance la aplicación y desbloquee BIMI

La fase de monitorización no es el destino; es la preparación para la aplicación. Una vez que sus informes DMARC muestren de forma constante que todas las fuentes de envío legítimas superan la autenticación, estará listo para mover su política a p=quarantine y, eventualmente, a p=reject.

Pasar de p=none a p=quarantine

Actualice su registro DMARC a:

v=DMARC1; p=quarantine; rua=mailto:dmarc@sudominio.com

Con p=quarantine, los mensajes que no superan DMARC se entregan en la carpeta de spam o correo no deseado en lugar de en la bandeja de entrada. Este es un paso de protección significativo: los correos suplantados ya no pueden llegar a la bandeja de entrada principal de sus destinatarios. Al mismo tiempo, le ofrece una red de seguridad: si se pasó por alto algún remitente legítimo durante la monitorización, su correo se filtra en lugar de ser rechazado directamente.

Permanezca varias semanas en p=quarantine mientras continúa monitorizando los informes. Esté atento a cualquier fuente legítima que empiece a aparecer como fallos; esta es su oportunidad para corregirlos antes de pasar al rechazo total.

Pasar de p=quarantine a p=reject

Una vez que los informes muestren una tasa de aprobación estable y alta, y haya confirmado que todas las fuentes de envío legítimas están autenticadas:

v=DMARC1; p=reject; rua=mailto:dmarc@sudominio.com

Con p=reject, el correo que no supera DMARC es rechazado por el servidor receptor antes de su entrega. Esta es la protección más sólida disponible: los mensajes suplantados que afirman provenir de su dominio simplemente nunca llegan a sus destinatarios.

BIMI desbloqueado: Una vez que alcance p=quarantine o p=reject, su dominio cumple los requisitos para BIMI. BIMI muestra el logotipo de su marca junto a sus correos en Gmail, Yahoo Mail y Apple Mail. Use el BIMI Checker para verificar su configuración cuando esté listo para configurarlo.

Usar pct para aumentar gradualmente

Si desea avanzar con cautela, use la etiqueta pct para aplicar su política a un porcentaje de los mensajes que fallan. Por ejemplo, para aplicar quarantine al 20 % de los mensajes que fallan inicialmente:

v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarc@sudominio.com

Aumente el porcentaje de forma incremental a lo largo de varias semanas mientras vigila sus informes en busca de fallos inesperados. Este enfoque escalonado es especialmente útil para organizaciones con entornos de envío complejos.

Cuidado con el correo reenviado en p=reject: El reenvío automático de correo electrónico es la fuente más común de fallos DMARC inesperados durante la aplicación. Cuando un mensaje es reenviado, el registro SPF del remitente original normalmente no cubre la IP del servidor de reenvío. Si tiene usuarios que reenvían correo a cuentas personales, investigue esto antes de pasar a p=reject.

Lista de verificación DMARC para Google Workspace

Use esta lista de verificación para confirmar que cada paso de su configuración DMARC en Google Workspace está completo:

  1. Registro SPF publicado: contiene include:_spf.google.com sin registros TXT duplicados en el mismo nombre de dominio
  2. Remitentes adicionales incluidos en SPF: todas las plataformas de marketing, servicios transaccionales y otras herramientas de envío tienen sus mecanismos SPF añadidos
  3. SPF verificado: confirmado como aprobado mediante el SPF Checker
  4. Clave DKIM generada en la Consola de administración de Google: clave de 2048 bits creada en Aplicaciones → Google Workspace → Gmail → Autenticar correo electrónico
  5. Registro DNS DKIM publicado: registro TXT en google._domainkey.sudominio.com activo en DNS
  6. Firma DKIM activada: se ha hecho clic en Iniciar autenticación en la Consola de administración tras la propagación del DNS
  7. DKIM verificado: confirmado mediante el DKIM Checker
  8. Registro DMARC publicado: registro TXT en _dmarc.sudominio.com con p=none y una dirección rua válida
  9. DMARC verificado: confirmado mediante el DMARC Checker
  10. Informes agregados fluyendo: informes llegando a su dirección designada o panel de control DMARC
  11. Todas las fuentes de envío identificadas y autenticadas: ninguna fuente legítima apareciendo como fallo DMARC
  12. Política movida a aplicación: p=quarantine o p=reject una vez que los informes confirmen tasas de aprobación limpias

Google Workspace facilita la activación de SPF y DKIM; el mayor esfuerzo se concentra en la fase de monitorización DMARC, donde se identifican y corrigen todas las fuentes de envío antes de pasar a la aplicación. Dedique el tiempo necesario a esa fase, use los informes agregados como guía y alcanzará una postura DMARC completamente aplicada que proteja su dominio, cumpla los requisitos de remitentes de Google y califique a su marca para la visualización del logotipo BIMI en Gmail.