IONOS: SPF, DKIM y DMARC para el correo y la zona DNS

ejemplo.es.  TXT  "v=spf1 include:_spf-eu.ionos.com ~all"

DMARC: el TXT _dmarc

El registro DMARC es un TXT publicado bajo el subdominio _dmarc:

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

Se empieza siempre en p=none: la política no impone nada, pero la dirección rua= desencadena los informes agregados que servirán para verificarlo todo antes de endurecer. En la interfaz DNS de IONOS, el campo de nombre espera el subdominio relativo _dmarc — la plataforma completa el dominio. Los ejemplos de registros DMARC comentados detallan las etiquetas que conviene conservar. Bajo DMARCbis, la pertenencia de los subdominios se determina mediante el DNS Tree Walk, sin cambiar la forma de publicar el registro en IONOS.

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 IONOS se sitúa en el caso favorable, como un alojamiento de correo clásico. Del lado DKIM, la firma lleva el dominio mismo — la alineación es directa. Del lado SPF, el sobre de los mensajes está también en el dominio, puesto que es IONOS quien aloja el correo de ese dominio: SPF se alinea entonces de forma natural.

Dos mecanismos pasan alineados, y esa redundancia protege: si una redirección rompe SPF, DKIM sobrevive, y a la inversa. Es la base que autoriza a apuntar con serenidad a una política estricta — una vez confirmada la cobertura por los informes. La residencia de datos juega aquí como complemento: todo el tratamiento del correo y de los registros asociados permanece dentro de la Unión Europea, un punto que cuenta para las organizaciones sujetas a exigencias de localización, aunque no cambie nada de la mecánica de alineación.

DNS en IONOS o delegado en otro sitio

Como con cualquier alojador, una comprobación previa evita el error más frustrante: asegurarse de que la zona DNS del dominio la gestiona realmente IONOS. Un dominio puede estar registrado en IONOS pero tener sus servidores de nombres delegados a otro proveedor; en ese caso, la interfaz DNS de IONOS muestra una zona que ya no es la autoritativa, y los registros que se añaden ahí no se sirven nunca.

Esta comprobación cuenta tanto más en IONOS cuanto que la publicación automática de DKIM depende de ella: solo publica el registro por sí sola si la zona está en IONOS. Zona delegada en otro sitio ⇒ DKIM activado en el área de correo pero un registro que publicar a mano en la otra interfaz. Olvidar este paso deja un DKIM «activado» del lado de IONOS pero ausente del DNS efectivo — un desajuste que explica muchas firmas ausentes en los informes.

Buzón IONOS o Microsoft 365 revendido

IONOS no vende un solo servicio de correo. Junto a sus buzones propios, revende Microsoft 365 — y el include SPF no es el mismo. Un buzón IONOS clásico pasa por _spf-eu.ionos.com; un Microsoft 365 suscrito vía IONOS emite por la infraestructura de Microsoft, y su include es include:spf.protection.outlook.com. Confundir los dos es una variante de la trampa de la herencia: el dominio lleva un include que no corresponde al servicio realmente emisor, y SPF falla.

El reflejo es el mismo que para cualquier alojador que revende varios productos: identificar cuál está efectivamente activo — el buzón propio o el Microsoft 365 revendido — antes de fijar el include. Un dominio migrado de uno a otro sin revisar su SPF arrastra un include obsoleto, fuente de fallos sin causa aparente. Este caso es tanto más frecuente cuanto que IONOS destaca ambas ofertas en el mismo recorrido de compra.

La rotación de la clave DKIM

Cuando la zona está en IONOS, la activación automática de DKIM simplifica también la rotación: IONOS gestiona la renovación de la clave por su lado, sin intervención manual sobre la zona. Esta gestión es una ventaja — la rotación, a menudo descuidada cuando exige una edición manual, se vuelve un no-acontecimiento, y una clave antigua no se eterniza.

Cuando la zona está delegada en otro sitio, en cambio, la rotación vuelve a ser manual: cada nueva clave publicada por IONOS debe trasladarse a la interfaz DNS externa, siguiendo el principio de solapamiento — publicar la nueva antes de retirar la antigua, para no abrir una ventana sin firma válida. Es la misma lógica que toda sustitución periódica del material de firma, simplemente a mano en lugar de automáticamente.

Los errores de configuración habituales

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

Conservar los include heredados de 1&1. _spf.perfora.net / _spf.kundenserver.de apilados con el include actual recargan el registro y lo acercan al permerror.

Activar DKIM sin publicar la clave (zona delegada). DKIM marcado en el área de correo, pero al estar la zona en otro sitio, el registro nunca se puso: ninguna firma válida.

Publicar dos registros SPF. Dos v=spf1 invalidan SPF por completo; hay que fusionar los include en uno solo.

Confundir buzón IONOS y Microsoft 365 revendido. Publicar _spf-eu.ionos.com para un dominio que en realidad emite vía el M365 revendido (o al revés): el include no cubre los servidores reales, y SPF falla.

Endurecer la política demasiado pronto. 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 — tanto más penalizante cuando el correo de IONOS lleva la correspondencia de negocio diaria.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es el área de IONOS, sino lo que reportan los destinatarios. Una vez publicado un registro _dmarc con una dirección rua=, 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 IONOS se atribuye correctamente al dominio: DKIM alineado, SPF alineado, y ninguna fuente que falle en ambos.

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. Se verifica en particular que el include SPF elegido cubre todas las fuentes de IONOS y que ninguna herencia de 1&1 falsea el cuadro. 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.