Infomaniak: SPF, DKIM y DMARC para el correo

ejemplo.es.  TXT  "v=spf1 include:spf.infomaniak.ch ~all"

DKIM: automático o manual

DKIM sigue la misma lógica que el resto. Cuando la zona está en Infomaniak, el asistente genera el par de claves y publica el registro DKIM por sí solo; la firma producida lleva d=ejemplo.es, el dominio mismo, y la alineación DKIM queda asegurada de entrada, incluso en modo estricto. Cuando la zona se gestiona en otro sitio, Infomaniak proporciona el valor DKIM que publicar manualmente en la otra interfaz DNS. La clave aprovisionada es de longitud robusta (2048 bits), esperada por los grandes proveedores; un valor por defecto sano que no hay razón para debilitar.

La rotación sigue este mismo reparto: automática y transparente cuando la zona está en Infomaniak, manual en caso contrario — con el principio de solapamiento habitual (publicar la nueva clave antes de retirar la antigua). Es la misma lógica que toda renovación de las claves de firma, con la gestión de más cuando todo está en un mismo sitio.

DMARC: el registro de partida

El registro DMARC es un TXT bajo el subdominio _dmarc:

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

El asistente a menudo propone uno en p=none con una dirección de informes. Ese es exactamente el buen comienzo: la política no impone nada, pero los informes agregados empiezan a fluir. Los ejemplos de registros DMARC comentados detallan las etiquetas que ajustar (sp, adkim, aspf) para lo que sigue. Bajo DMARCbis, la pertenencia de los subdominios se determina mediante el DNS Tree Walk, sin cambiar la forma de publicar el registro.

La alineación DMARC: el caso favorable

DMARC solo valida un mensaje si SPF o DKIM pasa y se alinea con el dominio del From. El correo de Infomaniak se sitúa en el caso favorable. Del lado DKIM, la firma lleva el dominio mismo — la alineación es directa. Del lado SPF, el sobre está en el dominio, puesto que es Infomaniak quien aloja el correo: SPF se alinea de forma natural. Dos mecanismos pasan alineados, y esa redundancia protege si uno de los dos cae por el camino.

Es esa doble cobertura la que autoriza a apuntar a una política estricta una vez que los informes lo confirman — un objetivo que el asistente prepara pero no cruza por sí solo.

DNS en Infomaniak o gestionado en otro sitio

Una comprobación previa condiciona todo lo demás: saber si la zona DNS está realmente en Infomaniak. Eso determina si el asistente puede publicar los registros él mismo, o si hay que trasladarlos a mano a otra interfaz. Un dominio registrado en Infomaniak pero cuyos servidores de nombres están delegados en otro sitio verá al asistente proponer valores que no podrá publicar — y si se olvida trasladarlos, la autenticación queda incompleta pese a una interfaz que parece haberlo «hecho todo».

La verificación es rápida: los servidores de nombres efectivos del dominio se leen en una consulta NS. Si apuntan a Infomaniak, el asistente es la autoridad; si no, es en la interfaz que gestiona realmente la zona donde hay que publicar SPF, DKIM y DMARC, retomando los valores que proporciona Infomaniak.

La soberanía suiza de los datos

El argumento de soberanía de Infomaniak merece un matiz útil. Suiza no está en la Unión Europea, pero se beneficia de una decisión de adecuación que reconoce su nivel de protección de datos como equivalente — los flujos de datos personales UE→Suiza están, pues, encuadrados sin mecanismo adicional. Para una organización deseosa de mantener su correo fuera de jurisdicciones extraeuropeas, un alojador suizo es una opción coherente, distinta tanto de un alojador intra-UE como de un actor sujeto a leyes de acceso extraterritoriales.

Esto no cambia nada de la mecánica de SPF, DKIM o DMARC — la alineación se razona igual en todas partes — pero pesa en la elección de un alojador, y es coherente con el resto del posicionamiento de Infomaniak. La localización de los datos de correo y de los registros asociados forma parte de las cuestiones que una organización regulada debe poder zanjar con claridad — y un alojador que responde a ello sin rodeos simplifica otro tanto la preparación de una auditoría.

Los errores de configuración habituales

Varias trampas reaparecen en el corpus de informes que el analizador DMARC gratuito procesa a diario.

Confiar a ciegas en el asistente sin verificar. El asistente coloca buenos registros, pero un servicio de terceros añadido después, o una zona delegada, escapa a su vista: los informes siguen siendo el árbitro.

Zona delegada: olvidar trasladar los valores. DKIM «configurado» del lado de Infomaniak pero nunca publicado en la zona efectiva: ninguna firma válida.

Publicar dos registros SPF. Añadir un ESP como segundo v=spf1 en lugar de un include fusionado invalida SPF por completo.

Creer DMARC «terminado» porque el asistente ha corrido. El asistente coloca el registro en p=none: el dominio está observado, todavía no protegido. La protección solo llega con el endurecimiento, decidido tras leer los informes — un paso que el asistente, prudentemente, no cruza por sí solo.

Endurecer la política demasiado pronto. A la inversa, pasar a p=reject antes de confirmar con los informes que todo el tráfico legítimo se alinea equivale a rechazar los propios mensajes.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es la interfaz de Infomaniak, sino lo que reportan los destinatarios. Una vez publicado un registro _dmarc con una dirección rua= — lo que el asistente propone a menudo de entrada —, los informes agregados llegan en unos días y detallan, fuente por fuente, qué se alinea y qué falla. La lectura de los informes DMARC agregados confirma que el tráfico de Infomaniak se atribuye correctamente al dominio, y sobre todo revela toda fuente distinta de Infomaniak — un ESP, una aplicación — que el asistente no ha cubierto.

Basta una cadencia sencilla: una primera lectura unos días después de la configuración, una vez que varios destinatarios han reportado, luego un vistazo semanal mientras la política siga en p=none. Es la confirmación de que todas las fuentes legítimas se alinean — Infomaniak y las demás — la que autoriza a endurecer. Una vez confirmada esa cobertura durante varios días, el paso a p=reject se hace sin riesgo. El analizador en línea recompone este estado a partir de los registros publicados y de los informes recibidos, y sitúa el dominio en el camino que lleva a p=reject.