Autenticar Mailjet: SPF, DKIM y alineación DMARC

ejemplo.es.  IN TXT  "v=spf1 include:spf.mailjet.com ~all"

mailjet._domainkey.ejemplo.es.  IN TXT  "k=rsa; p=MIGfMA0GCSqGSIb3DQEB…"

La alineación: la firma DKIM sostiene la conformidad

DMARC no se conforma con un SPF o un DKIM que simplemente «pasa»: exige que al menos uno de los dos mecanismos valide un dominio alineado con el del campo From: — el que el destinatario ve en el buzón. Es el concepto central del estándar, y es lo que separa a unos ESP de otros.

En Mailjet, la firma DKIM se aplica con el dominio del cliente: un mensaje enviado con From: contacto@ejemplo.es lleva una firma d=ejemplo.es. Dominio firmante y dominio visible son idénticos — la alineación DKIM queda garantizada, tanto en modo estricto como en modo relajado. Resultado: DMARC pasa, sea cual sea la política publicada, p=none hoy o p=reject mañana.

Es la propiedad que conviene retener de todo este artículo: en Mailjet, la conformidad DMARC descansa sobre DKIM. Mientras la clave mailjet._domainkey esté en zona y la firma activada, el flujo es conforme. El include SPF sirve a la reputación y a la entregabilidad, pero no es lo que hace pasar DMARC — la sección siguiente explica por qué.

Para situar esta pieza en el conjunto del dispositivo — política, direcciones de informe, etiquetas —, el hub de ejemplos de registros comentados, política por política sirve de referencia: el registro _dmarc se declina allí desde la simple vigilancia hasta el rechazo.

Sobre y Return-Path: donde se detiene la alineación SPF

Queda por entender por qué SPF, por su parte, no se alineará — y por qué no es grave.

SPF no evalúa el From: visible, sino la dirección de sobre: el MAIL FROM de la sesión SMTP, expuesto a posteriori en la cabecera Return-Path. Como la mayoría de los ESP, Mailjet coloca en ese sobre un dominio técnico propio (de la forma bnc3.mailjet.com): es lo que le permite recuperar los rebotes y tratar las bajas en nombre del cliente. Consecuencia mecánica: el servidor destinatario verifica SPF contra el dominio de rebote de Mailjet. La prueba tiene éxito — las IP de envío figuran efectivamente en el SPF de ese dominio —, pero el dominio así validado no guarda relación alguna con ejemplo.es: SPF pasa sin alinearse, y no aporta nada al veredicto DMARC.

En los informes agregados, este comportamiento produce una lectura desconcertante: spf=pass en una línea, alineación SPF en fallo en la siguiente y, sin embargo, una evaluación DMARC positiva gracias a DKIM. Esa gimnasia se disecciona en el artículo dedicado a esos veredictos en apariencia contradictorios, que enseña a leer esas líneas sin alarmarse.

Algunas ofertas van más lejos: según el plan contratado, Mailjet permite personalizar el Return-Path mediante un CNAME — bounce.ejemplo.es apuntando a la infraestructura de rebote del ESP. El sobre pasa a ser un subdominio del dominio visible, y la alineación SPF en modo relajado se vuelve alcanzable. Es un refinamiento útil para la reputación, no un requisito: un DKIM alineado basta para DMARC, y perseguir la doble alineación solo tiene sentido una vez terminado el resto del proyecto.

Un subdominio dedicado al envío: la buena práctica

Nada obliga a que las campañas salgan del propio dominio organizativo. La práctica recomendada — en Mailjet como en cualquier otro sitio — consiste en delegar el emailing a un subdominio dedicado: news.ejemplo.es para el marketing, reservando ejemplo.es para la correspondencia humana y, por ejemplo, factura.ejemplo.es para el transaccional.

Los beneficios son concretos. Primero, el aislamiento de la reputación: un incidente de campaña — una oleada de quejas, una lista mal depurada — degrada la reputación del subdominio emisor, no la del dominio principal del que dependen los intercambios cotidianos. Segundo, la legibilidad de los informes: cada subdominio cuenta un flujo, y una fuente inesperada se detecta allí de un vistazo. Tercero, la flexibilidad de política: DMARC sabe tratar los subdominios de forma específica (etiqueta sp=, completada por np= para los subdominios inexistentes), y DMARCbis — el estándar vigente — descubre la política aplicable subiendo por el árbol DNS, el Tree Walk, subdominio a subdominio.

En concreto, el procedimiento es el mismo, un nivel más abajo: validar news.ejemplo.es en Mailjet, publicar el include SPF y la clave DKIM en ese subdominio (mailjet._domainkey.news.ejemplo.es) y dejar que la alineación relajada — el modo por defecto — tienda el puente hacia el dominio organizativo: un From: carta@news.ejemplo.es firmado d=news.ejemplo.es sigue alineado con ejemplo.es.

El razonamiento vale para todos los enrutadores, cada uno con sus particularidades de sobre y de selectores: las guías dedicadas a la autenticación en Brevo y a la configuración del lado de SendGrid siguen el mismo esquema, y comparar los tres resulta instructivo.

Los errores vistos sobre el terreno

Las zonas DNS auditadas tras un «DKIM no pasa» cuentan casi siempre una de estas cuatro historias.

• El SPF duplicado. El asistente del proveedor de alojamiento o un copiar-pegar demasiado rápido crea un segundo registro v=spf1 junto al existente, en lugar de fusionar los mecanismos en uno solo. Dos registros SPF sobre el mismo nombre producen un permerror: los destinatarios ignoran ambos, y un mecanismo pensado para ayudar se convierte en fallo sistemático para todos los flujos del dominio, no solo para Mailjet. La corrección cabe en una línea: un único v=spf1, con todos los include dentro.
• El registro colocado en el nivel equivocado. Gran clásico de las interfaces DNS que añaden automáticamente el nombre de la zona: la clave acaba publicada en mailjet._domainkey.ejemplo.es.ejemplo.es — el dominio duplicado — porque el nombre completo suministrado por Mailjet se pegó en un campo que esperaba un nombre relativo. Variante frecuente: el include SPF añadido en ejemplo.es cuando el dominio validado, el usado en el From:, es news.ejemplo.es — o al revés, la clave DKIM puesta en la raíz mientras los envíos salen del subdominio. En todos los casos, la verificación de Mailjet sigue en rojo o, peor, se pone en verde sobre un perímetro que no es el de los envíos reales.
• La clave truncada. Un valor p= amputado al pegarlo — campo demasiado corto, comillas perdidas, un salto de línea intruso — produce una firma imposible de verificar. Un dig TXT mailjet._domainkey.ejemplo.es permite comparar carácter a carácter el valor publicado con el suministrado por la plataforma.
• La firma nunca activada. El registro está correctamente en zona, pero la verificación final del lado de Mailjet nunca se relanzó: los mensajes salen sin firma del dominio propio. El DNS es correcto, el flujo no — el caso más frustrante, porque es invisible desde la zona.

Ninguno de estos errores es grave; todos cuestan días de entregabilidad degradada cuando nadie mira las señales correctas. De ahí la etapa final.

La verificación en los informes

La configuración no se declara terminada cuando la interfaz se pone en verde: se verifica en los informes agregados. Con un registro DMARC que publique una dirección de recogida:

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

cada gran destinatario — Gmail, Microsoft, Yahoo — envía un balance diario de los mensajes recibidos en nombre del dominio, IP por IP, veredicto por veredicto.

En esos informes, un flujo Mailjet bien configurado se reconoce por tres señales: las IP de envío de la plataforma aparecen como fuente identificada; DKIM muestra pass con un dominio firmante igual al dominio del From: — la alineación; SPF muestra pass sobre el dominio de rebote de Mailjet, sin alineación, que es el comportamiento esperado y no una anomalía. Si DKIM falla, o si la firma lleva un dominio de Mailjet en lugar del dominio propio, uno de los errores de la sección anterior es muy probablemente la causa.

Esa lectura es también la barandilla del endurecimiento: pasar de p=none a p=quarantine y después a p=reject supone varias semanas de informes en los que el flujo Mailjet — y todos los demás emisores legítimos — permanecen alineados sin excepción. DMARCbis proporciona además un modo de prueba explícito (t=y) para señalar una política en rodaje, allí donde la antigua etiqueta pct ha desaparecido del estándar.

En resumen

Autenticar Mailjet sigue un recorrido corto y bien señalizado: validación del dominio — o, mejor, del subdominio de envío dedicado —, un include spf.mailjet.com fusionado en el registro SPF existente, una clave DKIM publicada bajo mailjet._domainkey, una firma activada y después controlada. La conformidad DMARC descansa sobre DKIM, firmado con el dominio propio; SPF pasa sin alinearse por culpa del Return-Path técnico del ESP, y es un comportamiento normal, corregible en su caso con un Return-Path personalizado. Los fallos encontrados sobre el terreno rara vez vienen del estándar: vienen de un SPF duplicado, de un registro colocado en el nivel equivocado, de una clave truncada o nunca activada — diagnósticos todos que se leen negro sobre blanco en los informes agregados.

Para saber en qué punto está un dominio, antes o después de este proyecto, un análisis DMARC gratuito levanta en unos segundos el estado de la cuestión: registros publicados, include presentes, política en vigor. Y para seguir los informes en el tiempo, hasta p=reject, la apertura de una cuenta da acceso a la vigilancia continua del dominio — flujo Mailjet incluido.