Configurar SPF y DKIM en OVHcloud

SPF según la oferta — y la trampa del registro por defecto

SPF responde a una pregunta sencilla: ¿qué direcciones IP tienen derecho a enviar correo en nombre del dominio? La respuesta cabe en un único registro TXT colocado en la raíz. Para MX Plan, el valor documentado cabe en una línea:

ejemplo.es.  IN TXT  "v=spf1 include:mx.ovh.com ~all"

El mecanismo include:mx.ovh.com autoriza la infraestructura de envío mutualizada de OVHcloud, por la que transitan los mensajes de los buzones MX Plan y de los scripts del alojamiento web. Para Email Pro y Exchange, la infraestructura de envío no es la misma y el valor a incluir difiere: figura en la guía de OVHcloud propia de cada oferta, y de ahí es de donde hay que tomarlo, en lugar de copiar el de MX Plan. El principio estable, en cambio, no cambia nunca: un solo TXT v=spf1, que fusiona todas las fuentes legítimas — la oferta de OVHcloud, pero también la plataforma de marketing (Brevo, Mailchimp…), la herramienta de facturación, el CRM. Cada include consume una parte del presupuesto de diez resoluciones DNS que impone el estándar; apilar sin contar lleva directo al permerror.

Y llega la trampa de la casa. Al crear una zona con los registros por defecto, OVHcloud deposita ya un TXT SPF que autoriza su propia infraestructura. Este valor por defecto bienintencionado tiene dos efectos perversos. Primero, sobrevive a las migraciones: un dominio cuyo correo vive ahora en Microsoft 365 o Google Workspace conserva una autorización abierta hacia la infraestructura mutualizada de OVHcloud — y desde el punto de vista de SPF, cualquier máquina de esa infraestructura compartida se convierte en remitente legítimo del dominio. Segundo, alimenta el reflejo de «añadir» un nuevo registro SPF en lugar de modificar el existente: dos TXT v=spf1 pasan entonces a coexistir, y el estándar no perdona — el resultado es un error permanente, no una fusión. La misma cuestión del registro por defecto colocado por el registrador se repite en otros actores del mercado; la configuración equivalente en Gandi muestra una mecánica distinta con un remedio idéntico: una sola línea, mantenida al día.

Queda la elección del calificador final. ~all (softfail) marca las fuentes no listadas como sospechosas sin exigir su rechazo; -all (fail) pide el rechazo sin matices. Durante la fase de inventario, ~all es la elección prudente; una vez DMARC en marcha, es de todos modos la política DMARC la que decide la suerte de los mensajes no alineados, y endurecer SPF pasa a ser un refinamiento más que una necesidad.

DKIM: selectores CNAME y activación desde el panel de cliente o la API

DKIM añade al mensaje una firma criptográfica, que el destinatario verifica gracias a una clave pública publicada en el DNS bajo un nombre de la forma <selector>._domainkey.ejemplo.es. En OVHcloud no hay clave que copiar y pegar: la activación crea dos selectores en forma de registros CNAME, que apuntan a destinos gestionados por OVHcloud (nombres alojados bajo dkim.mail.ovh.net). La ventaja de este montaje es real: la clave pública permanece en OVHcloud, que puede rotarla con regularidad sin intervención alguna sobre la zona — los dos selectores se alternan, uno firma mientras el otro espera la siguiente rotación.

La activación depende de la oferta. Para Exchange y Email Pro, se pilota desde el panel de cliente, en la configuración del dominio asociado al servicio, o mediante la API. Para MX Plan, OVHcloud ha automatizado en gran medida la activación en las ofertas recientes, y la API permite lanzarla o comprobarla en los dominios más antiguos. Como las etiquetas exactas de los botones evolucionan con regularidad, el procedimiento al día es el de la documentación de OVHcloud — los mecanismos descritos aquí (dos selectores, CNAME, rotación gestionada) son la parte estable.

Un caso particular merece atención: cuando la zona DNS no está alojada en OVHcloud, los dos CNAME no pueden colocarse automáticamente. Los valores a crear se muestran entonces en el panel de cliente o pueden recuperarse por la API, y hay que copiarlos —carácter a carácter— en el proveedor de DNS real. Un selector mal escrito produce una firma imposible de verificar, es decir, un fallo DKIM silencioso.

Los errores vistos en la práctica

Tres familias de errores vuelven una y otra vez en los informes DMARC de dominios alojados en OVHcloud.

• Dos TXT v=spf1. El más frecuente, nacido del SPF por defecto. Un receptor que encuentra dos registros SPF sobre el mismo nombre devuelve un error permanente: el mensaje ya no puede pasar SPF, por buena que sea cada una de las dos líneas. El remedio cabe en una operación: fusionar y borrar el duplicado — el modo textual de la zona hace el diagnóstico inmediato.
• El olvido posmigración. Correo migrado de MX Plan a Microsoft 365, o de Exchange a otra plataforma: el SPF conserva el viejo include, ya inútil (e incluso arriesgado, sobre una infraestructura compartida), mientras DKIM sigue firmando con los selectores de la antigua oferta — o ya no firma en absoluto, porque los CNAME se borraron junto con el servicio. Los informes DMARC destapan estos fantasmas en cuestión de días: una fuente que ayer enviaba y ya no envía, una firma que falla desde una fecha precisa.
• El TTL que falsea las pruebas. Una corrección publicada solo se observa cuando expiran las cachés, hasta una hora con el TTL por defecto. Probar treinta segundos después del cambio, concluir que falla y «corregir» de nuevo conduce a zonas incoherentes. La disciplina útil: bajar el TTL antes de una migración planificada y, después del cambio, esperar un ciclo completo antes de emitir veredicto.

Verificar antes de endurecer

La verificación se hace a tres niveles. Primero, el DNS en bruto: una consulta TXT sobre la raíz del dominio debe devolver un único v=spf1; una consulta sobre los nombres selector1._domainkey y selector2._domainkey debe seguir los CNAME hasta las claves alojadas por OVHcloud. El método detallado, con herramientas y trampas incluidas, se despliega en la comprobación de un registro SPF.

Después, la prueba a escala real: un mensaje enviado a un buzón de Gmail o de Outlook.com, seguido de la lectura de la cabecera Authentication-Results del mensaje recibido. Las menciones esperadas: spf=pass, dkim=pass con un selector de OVHcloud, y dominios alineados. Por último, la observación en el tiempo: publicar un registro DMARC en modo vigilancia muestra lo que los receptores del mundo entero constatan de verdad, semana tras semana:

_dmarc.ejemplo.es.  IN TXT  "v=DMARC1; p=none; rua=mailto:informes-dmarc@ejemplo.es"

Los ejemplos de registros DMARC proporcionan la plantilla adecuada a cada situación — dominio activo, dominio de marca defensivo, subdominios. Esa fase de observación es la que transforma una configuración «que parece correcta» en una configuración probada.

En resumen

En OVHcloud, SPF y DKIM se configuran rápido en cuanto quedan fijados tres puntos de referencia: la oferta de correo realmente contratada (MX Plan, Email Pro o Exchange — cada una con su infraestructura, su valor SPF y su procedimiento DKIM), la zona DNS como único lugar de verdad (con el modo textual como herramienta de auditoría) y la trampa del SPF por defecto, responsable de la mayoría de los v=spf1 duplicados que se ven en circulación. DKIM se activa desde el panel de cliente o la API, en forma de dos selectores CNAME cuya rotación gestiona OVHcloud; los errores clásicos —duplicado SPF, olvido posmigración, TTL mal anticipado— se detectan todos con una lectura atenta de la zona y de los informes.

El punto de partida más corto sigue siendo un análisis DMARC gratuito del dominio: en unos segundos muestra el estado real de SPF, DKIM y DMARC tal como los ve un receptor, duplicados incluidos. Con el diagnóstico en la mano, crear una cuenta permite recopilar los informes, vigilar en el tiempo los dos selectores de OVHcloud y llevar la política hacia p=reject sobre pruebas, no sobre suposiciones.