Configurar SPF, DKIM y DMARC en Google Workspace

Qué hace Google por ti y qué no

Google Workspace envía tus correos con tu dirección y con tu dominio en el sobre, así que el permiso SPF, una vez publicado, alinea solo. Esa es la parte fácil, y por eso la mayoría de los dominios con Workspace pasan DMARC desde el primer día, aunque no hayan hecho nada más.

La firma es otra historia. Hasta que no generas y activas la clave DKIM de tu dominio, Google firma tus correos con una clave de respaldo de un dominio suyo. Esa firma dice que el correo salió de Google, pero no que salió de tu dominio, y para DMARC no cuenta. Tus correos pasan entonces solo por el SPF. Funciona, hasta que alguien se reenvía uno de tus correos a otra cuenta: el reenvío rompe el SPF, no hay firma tuya que lo sostenga, y esa copia falla.

El DMARC no lo pone Google. Es tu registro, y es el que decide qué pasa con lo que no supera las comprobaciones. Si no sabes por dónde empezar con él, está en qué es DMARC y por qué p=none no te protege de nada.

Cómo se hace

1. El permiso SPF. En el panel de tu DNS, un registro de tipo TXT en el nombre raíz del dominio (@ en la mayoría de los paneles) con este valor, si Google es lo único que envía:

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

   Si usas más herramientas, van todas dentro del mismo registro, una detrás de otra. Un dominio solo puede tener un SPF: con dos, los buzones no se quedan con ninguno.

   Si ya trabajas con nosotros la seguridad y la configuración de tu dominio, este permiso no lo añades tú: Deliveruti lo publica por ti. Dile al asistente que empiezas a usar Google Workspace, y listo. Lo que sí sigue siendo tuyo es lo demás: los MX y la firma.

2. La firma DKIM. En la consola de administración (admin.google.com): Aplicaciones, Google Workspace, Gmail, y ahí «Autenticar correo electrónico». Eliges el dominio y pulsas «Generar registro nuevo». Por defecto la clave es de 2048 bits y el selector es google. La consola te enseña un nombre, google._domainkey, y un valor que empieza por v=DKIM1; k=rsa; p=. Ese TXT va en tu DNS, en ese nombre.

3. Activar la firma. Este es el paso que se olvida. Cuando el registro esté publicado (minutos normalmente, hasta 48 horas si tu DNS tarda), vuelves a la misma pantalla y pulsas «Iniciar autenticación». Hasta ese clic, Google no firma nada con tu dominio, aunque el registro lleve meses en tu DNS.

4. Comprobar. Envíate un correo a una cuenta de Gmail y abre «Mostrar original». En la línea de DKIM tiene que poner PASS con tu dominio, no con uno acabado en gappssmtp.com.

5. El DMARC. Un TXT en _dmarc con p=none y una dirección para los informes, para empezar. Subir la política es otro trabajo, con los informes delante.

Si Gmail lleva menos de tres días activo en el dominio, la consola puede no dejarte generar la clave todavía: es normal, Google lo avisa en su documentación.

Un inciso sobre los MX

Los MX no autentican nada: dicen qué servidores reciben el correo de tu dominio. Van aquí porque Google los ha cambiado con los años y es una duda habitual.

• Hoy Google pide un solo registro MX, smtp.google.com, con prioridad 1. Si das de alta Workspace ahora, es lo único que te enseña.
• Si lo diste de alta hace años tendrás cinco: aspmx.l.google.com y cuatro alt1 a alt4, con prioridades 1, 5 y 10. En cuentas más antiguas todavía, los nombres acaban en googlemail.com. Las formas antiguas siguen funcionando: no hace falta cambiarlas, y la nueva, sola, está bien así.
• Si tienes los cinco antiguos y añades el nuevo al lado, funciona, pero no aporta nada. Un solo registro es más fácil de mantener.
• Los MX no envían correo, así que no pintan nada en el SPF: un mx dentro del SPF gasta una consulta de las diez para autorizar servidores que solo reciben.

En los dominios que vigilamos conviven la forma nueva y la antigua, y las dos entregan igual.

Lo que vemos en los dominios que vigilamos

• La firma a medias es lo más común. En nuestra cartera no es raro encontrar cuentas de Workspace con años de uso que nunca pulsaron «Iniciar autenticación». El correo llega, porque el SPF alinea, y nadie se entera hasta que sube la protección y las copias reenviadas empiezan a fallar. Con la firma activa, esas copias pasan igual.
• La clave larga y los paneles que la cortan. La clave de 2048 bits tiene más de 255 caracteres, y algunos paneles la truncan sin avisar, sobre todo los de hosting (cPanel). El registro existe, pero la clave está rota y la consola de Google no la encuentra. La salida es partir el valor en dos cadenas entre comillas, si el panel lo permite, o generar una de 1024.
• Grupos, listas y reglas que reenvían. Un grupo de Google o una regla que reexpide un correo lo modifica, y la firma deja de validar en esa copia. En los informes se ve como un goteo de correos sin firma válida desde las propias direcciones de Google, siempre el mismo día de la semana. El SPF los sostiene, y no hay nada que arreglar.
• El dominio secundario. Si tu dominio es el segundo de una cuenta de Workspace cuyo dominio principal es otro, el sobre lleva el principal y el SPF no alinea con el tuyo. Ahí la firma es lo único que sostiene DMARC, y activarla deja de ser opcional.
• Los informes de Google llegan al día siguiente y solo de los días en que hubo correo. Un cambio hecho hoy se ve mañana, no en una hora.