Configurar SPF y DKIM en Gandi

@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"

v=spf1 include:_mailcust.gandi.net include:spf.mailjet.com ~all

DKIM en GandiMail: una activación, tres selectores

SPF autentica el servidor emisor; DKIM firma el mensaje en sí, y la firma sobrevive a los reenvíos. En GandiMail, la activación parte de la sección de correo de la administración del dominio — un botón dedicado lo desencadena todo; la ruta exacta por la interfaz cambia con cada rediseño, y la documentación de Gandi sigue siendo la única referencia al día en ese punto. Lo que produce la activación, en cambio, es estable: tres registros CNAME.

gm1._domainkey 10800 IN CNAME gm1.gandimail.net.
gm2._domainkey 10800 IN CNAME gm2.gandimail.net.
gm3._domainkey 10800 IN CNAME gm3.gandimail.net.

Si la zona está en LiveDNS, esas tres líneas se añaden automáticamente. Si el DNS está delegado en otra parte, hay que crearlas a mano en el proveedor de la zona — mismos nombres, mismos destinos. La elegancia del montaje reside en el CNAME: la clave pública permanece alojada en Gandi, que puede renovarla sin que la zona del dominio cambie jamás. Los tres selectores gm1, gm2 y gm3 existen precisamente para esa rotación: mientras una clave firma, la siguiente se prepara. Es una ventaja operativa real frente al TXT congelado, pegado una vez y olvidado durante años — la rotación de claves DKIM es una higiene que pocos equipos mantienen cuando sigue siendo manual.

Editar la zona LiveDNS: interfaz, modo texto, API

LiveDNS ofrece tres puertas de entrada, y cada una tiene una trampa. La interfaz web presenta la zona registro a registro: tipo, nombre, TTL, valor. Un TXT se añade en unos clics, las comillas están gestionadas, y las cadenas que superan los 255 caracteres — una clave DKIM de 2048 bits, típicamente — se trocean automáticamente. El modo texto muestra la zona entera como un fichero de zona: práctico para pegar varios registros de golpe, pero aplica las reglas de sintaxis de los ficheros de zona, punto final incluido (el anecdotario de más abajo vuelve sobre ello). La API REST de LiveDNS (v5), por último, abre la automatización: autenticación por token de acceso personal, escritura de un registro con una simple petición HTTP — la vía natural para gestionar SPF y DKIM como infraestructura como código, con los conectores de Terraform o Ansible que se apoyan en ella.

Un ajuste transversal merece atención: el TTL, de 10800 segundos (tres horas) por defecto. Antes de una operación sobre SPF o DKIM, bajarlo a 300 segundos acorta el plazo de corrección si se cuela un error; después vuelve a subirse. En cuanto a los dominios registrados en Gandi pero cuya zona está delegada a Cloudflare, el mismo ejercicio del lado de Cloudflare — con sus propias trampas, el proxy naranja a la cabeza — se trata en la guía dedicada a Cloudflare.

Dominio en Gandi, correo en otra parte: solo cambian los valores

Es probablemente el caso más extendido: el dominio y la zona viven en Gandi, los buzones en Microsoft 365 o Google Workspace. Nada cambia en el método — solo cambian los registros.

Del lado de Microsoft 365, el SPF pasa a ser v=spf1 include:spf.protection.outlook.com -all, y DKIM toma la forma de dos CNAME, selector1._domainkey y selector2._domainkey, apuntando al tenant en onmicrosoft.com; la firma se activa en el portal Defender. Del lado de Google Workspace: SPF v=spf1 include:_spf.google.com ~all, y DKIM como un TXT google._domainkey cuya clave — 2048 bits recomendados — se genera en la consola de administración antes de pegarse en LiveDNS, que se encarga del troceado de la cadena larga.

Dos reflejos completan el cuadro. Primero, retirar include:_mailcust.gandi.net si ya no sale ningún mensaje por GandiMail: un include muerto consume una resolución DNS de las diez permitidas y amplía la superficie autorizada sin contrapartida. Segundo, sustituir los MX de la plantilla de Gandi por los del proveedor real — unos MX que apuntan a spool.mail.gandi.net mientras los buzones están en Microsoft extravían el correo entrante y enturbian el diagnóstico.

Los errores frecuentes, del SPF duplicado al punto final

Los informes DMARC y los foros de ayuda cuentan siempre las mismas historias. Pequeño anecdotario:

• El SPF duplicado. La zona prerrellenada ya contiene un v=spf1; el asistente de configuración de un ESP recomienda añadir el suyo; los dos coexisten, y el resultado es un permerror. La fusión en un único registro es la única salida.
• El viejo tipo SPF. Zonas heredadas de la infraestructura DNS «clásica» de Gandi pueden contener todavía un registro de tipo SPF (tipo 99), obsoleto desde hace tiempo según la RFC 7208: solo cuenta el TXT, y el duplicado de tipo siembra confusión y debe eliminarse.
• El punto final. En modo texto, gm1.gandimail.net sin punto terminal se convierte en gm1.gandimail.net.ejemplo.es. — un CNAME que no resuelve nada. El formulario web completa el nombre implícitamente, el modo texto no: la regla depende del editor utilizado, de ahí las sorpresas al copiar una línea de un contexto a otro.
• La impaciencia. Con un TTL por defecto de tres horas, el valor antiguo sigue siendo servido por los resolutores hasta que expira la caché. Probar treinta segundos después del cambio y concluir que ha fallado es un clásico de la propagación DNS.
• El subdominio olvidado. SPF no se hereda: un subdominio emisor (newsletter.ejemplo.es) necesita un registro propio.

La etapa siguiente tiene un anecdotario propio: la sintaxis DMARC, con sus puntos y comas y sus etiquetas trampa, catalogada en los errores de sintaxis de un registro DMARC.

Verificar, y después conectar DMARC

La verificación no se adivina, se mide. En línea de comandos, dos consultas cubren lo esencial:

dig TXT ejemplo.es +short
dig CNAME gm1._domainkey.ejemplo.es +short

La primera debe devolver un único v=spf1…, la segunda el destino gm1.gandimail.net.. La prueba de fuego completa el control: un mensaje enviado a un buzón de Gmail, y luego la lectura de la cabecera Authentication-Results — spf=pass y dkim=pass con uno de los selectores gm1 a gm3 son la firma de una configuración sana.

Con SPF y DKIM colocados, queda por conectar el piso que los explota: DMARC, mediante un TXT en _dmarc.ejemplo.es, empezando por v=DMARC1; p=none; rua=mailto:… para observar sin bloquear nada. En lugar de improvisar la sintaxis, el arranque más seguro es partir de ejemplos comentados de registros DMARC y adaptarlos. Los informes agregados revelan entonces lo que el inventario pasó por alto — el servidor viejo que sigue enviando, la herramienta conectada por una filial — y guían la subida hacia p=quarantine y luego p=reject, el punto en el que suplantar el dominio deja de ser rentable.

En resumen

Gandi entrega una zona prerrellenada que da diez minutos de ventaja, no una autenticación completa. El SPF de la casa, include:_mailcust.gandi.net, cubre GandiMail y nada más: se endurece (~all, luego -all) y se fusiona — nunca se duplica — cuando se suma un ESP. DKIM se activa con un botón y descansa sobre tres CNAME gm1 a gm3 que dejan la rotación de claves en manos de Gandi. La zona se edita por formulario, modo texto o API, con el punto final y el TTL de tres horas como trampas recurrentes. Y cuando los buzones viven en Microsoft 365 o Google Workspace, el método permanece: solo cambian los valores, a condición de purgar los vestigios de GandiMail. Para las rutas exactas de la interfaz, susceptibles de moverse con cada rediseño, la documentación de Gandi es la que manda.

El control final no cuesta nada: un pase del dominio por el análisis DMARC gratuito muestra de un vistazo el estado real de SPF, DKIM y DMARC tal y como los ven los servidores receptores. Y para rematar la jugada — seguir los informes, detectar la fuente olvidada, llevar la política hasta p=reject —, la creación de una cuenta abre la vigilancia continua, justo donde termina la edición de zona.