Zoho Mail: SPF, DKIM y alineación DMARC

ejemplo.es.  TXT  "v=spf1 include:zoho.eu ~all"

zmail._domainkey.ejemplo.es.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq…"

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. Zoho Mail se sitúa aquí en el caso favorable, como un alojamiento de correo clásico.

Del lado DKIM, la firma lleva el propio dominio — la alineación es directa. Del lado SPF, el sobre de los mensajes salientes está también en el dominio de la organización, puesto que es Zoho quien aloja el correo de ese dominio: SPF se alinea entonces de forma natural, sin subdominio de sobre que declarar como en algunos ESP. Dos mecanismos pasan alineados, y esa redundancia protege: si una redirección rompe SPF por el camino, DKIM sobrevive. Los ejemplos de registros DMARC comentados muestran cómo fijar la consigna _dmarc una vez SPF y DKIM en su sitio — primero en p=none mientras se observa, luego endureciendo.

La trampa del centro de datos

La casi totalidad de las configuraciones de Zoho que fallan se reducen a un desajuste de región. La cuenta está alojada en un centro de datos dado — elegido al darse de alta, a veces sin prestarle atención —, pero el include SPF, la consola DKIM y los registros MX deben corresponder todos a esa misma región. Un dominio cuya cuenta vive en el centro europeo pero cuyo SPF apunta a include:zohomail.com verá sus mensajes fallar en SPF de forma desconcertante: la documentación parece seguida, y sin embargo la autenticación no pasa.

El reflejo de diagnóstico consiste en verificar, en la consola, la región de alojamiento efectiva, y luego alinear todos los registros con ella. Los MX de Zoho siguen la misma lógica regional que el include SPF; un MX correcto pero un include de otra región es un caso clásico, precisamente porque ambos se configuran en momentos distintos. La migración de una cuenta de un centro de datos a otro — operación que Zoho ofrece — obliga además a revisar el include SPF de paso, un punto que el cambio no siempre recuerda. Es una verificación de unos minutos que ahorra horas de tanteo.

Alias de dominio y subdominios

Zoho Mail permite vincular varios dominios y alias a una misma organización. Cada dominio que emite correo constituye un perímetro de autenticación distinto: necesita su propio registro SPF y su propia clave DKIM, publicados en SU zona. Un alias que reutiliza la infraestructura de un dominio principal sin publicar sus propios registros enviará bajo una identidad no autenticada — y DMARC fallará para ese alias concreto, aunque el dominio principal sea impecable.

La regla vale también para los subdominios. Un subdominio que emite — facturación, soporte, notificaciones — hereda sí la política DMARC del padre a través del tree-walk de DMARCbis, pero no su registro SPF ni su clave DKIM: esos siguen debiendo publicarse allí donde el correo sale realmente. Confundir la herencia de política con la herencia de configuración es un error frecuente que deja un subdominio activo sin autenticación alineada, bajo una política heredada que sí lo hará rechazar.

Los errores de configuración habituales

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

Publicar la clave DKIM sin activarla. El TXT está en su sitio, pero la firma no se aplica nunca por no haber marcado la activación en la consola. Síntoma: SPF pasa, DKIM está ausente de los informes.

Apilar dos registros SPF. Añadir un segundo registro v=spf1 en lugar de fusionar los include en uno solo provoca un permerror que invalida SPF por completo — no solo el añadido.

Copiar un include de la región equivocada. El caso Zoho por excelencia, descrito más arriba.

Endurecer la política demasiado pronto. Pasar a p=reject antes de confirmar, con los informes en la mano, que todo el tráfico legítimo se alinea — correo humano y notificaciones aplicativas — equivale a arriesgarse al rechazo de los propios mensajes.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es la consola de Zoho, 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 Zoho se atribuye correctamente al dominio: DKIM alineado, SPF alineado, y ninguna fuente de Zoho que falle en ambos mecanismos.

Basta una cadencia sencilla: una primera lectura unos días después de publicar el registro _dmarc, una vez que varios destinatarios han reportado, luego un vistazo semanal mientras la política siga en p=none. El tráfico de Zoho aparece bajo un conjunto de direcciones estable, propio de la región de la cuenta: una línea de base alineada se reconoce pronto, y toda fuente de Zoho nueva o no alineada resalta de inmediato — señal, las más de las veces, de un servicio que emite desde otra región o de un selector DKIM nunca activado.

Esa verificación, mantenida durante varios días, es la que autoriza a endurecer la política sin riesgo. Mientras los informes muestren tráfico legítimo sin alinear — un servicio olvidado, una región mal configurada —, el paso a p=reject sigue siendo prematuro. Una vez confirmada la alineación sobre el conjunto de los flujos, el paso a una política estricta se hace con serenidad. 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.