Autenticar Brevo: SPF, DKIM y alineación DMARC

mail._domainkey.ejemplo.es.   TXT   "k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…"
ejemplo.es.                   TXT   "brevo-code:7f3a92c1d5e84b06"

dig TXT mail._domainkey.ejemplo.es +short

La alineación DKIM: lo que realmente hace pasar DMARC

La palabra que cuenta en toda esta operación no es ni «firma» ni «clave»: es alineación. Un mensaje firmado por un dominio técnico de la plataforma pasa DKIM en el sentido criptográfico —la firma es válida, nadie ha alterado el contenido—. Pero DMARC añade una exigencia de identidad: el dominio d= de la firma debe corresponder al dominio del From: visible. d=ejemplo.es con un From: en ejemplo.es: alineado, DMARC pasa. d= en un dominio compartido: DKIM «pass», DMARC «fail».

En modo relaxed —el valor por defecto, y la buena elección para un ESP—, la correspondencia se juega a nivel del dominio organizativo: un From: en news.ejemplo.es firmado d=ejemplo.es sigue alineado. DMARCbis, la versión vigente del estándar, determina ahora ese dominio organizativo mediante un recorrido del árbol DNS (el Tree Walk) en lugar de la antigua Public Suffix List —un cambio de mecánica interna que no modifica en nada el gesto de configuración—. El modo strict, por el contrario, exige la identidad exacta de los dos dominios; queda reservado a las organizaciones donde el control fino prima sobre la flexibilidad.

Todo el valor de la autenticación de dominio de Brevo reside en ese desplazamiento: la firma compartida se convierte en una firma en nombre de la organización. La mecánica, por lo demás, no tiene nada de específico de Brevo: la configuración equivalente en Mailjet sigue el mismo esquema, y la alineación en Mailchimp plantea exactamente la misma pregunta con otras pantallas y un CNAME más. El principio se mantiene constante de un ESP a otro: el dominio que firma debe ser el que se muestra.

SPF y el sobre: por qué la alineación no vendrá de ahí

El reflejo más extendido consiste en añadir un include de la plataforma al SPF del dominio y dar el trabajo por terminado. Es un doble error de lectura. SPF no se evalúa sobre el From: visible: se evalúa sobre el MAIL FROM del sobre SMTP —el Return-Path, esa dirección técnica que recoge los rebotes—. Y en Brevo, como en la mayoría de los ESP, esa dirección de sobre permanece en un dominio operado por la plataforma: es justamente lo que le permite tratar los rebotes y la higiene de listas a gran escala. SPF pasa, sí, de verdad… pero en nombre del dominio de sobre de Brevo, no en nombre de ejemplo.es. El resultado: un «pass» sin alineación y, por tanto, ninguna contribución a DMARC.

Modificar el SPF de ejemplo.es no cambia nada de esto —los servidores destinatarios consultan el registro del dominio del sobre, nunca el del dominio del From:—. Un include superfluo solo consume el presupuesto de las diez consultas DNS que concede SPF, sin aportar nada a cambio. Esta disociación entre el SPF en bruto y el veredicto DMARC es una de las confusiones más frecuentes al leer informes; está desmenuzada en por qué DMARC falla aunque SPF pase.

La conclusión práctica es nítida: con un ESP, es DKIM quien lleva la alineación, en solitario —y basta, puesto que DMARC solo pide uno de los dos mecanismos alineado—. Algunos ESP ofrecen como opción un dominio de sobre personalizado que añade encima la alineación SPF; es un refinamiento bienvenido, no un requisito previo.

Gmail, Yahoo, Microsoft: un requisito, ya no una opción

Desde febrero de 2024, Gmail y Yahoo imponen una base a los remitentes de volumen —del orden de 5 000 mensajes al día hacia sus buzones—: SPF y DKIM en su sitio, un registro DMARC publicado (como mínimo p=none), un From: efectivamente alineado, la baja en un clic y una tasa de quejas mantenida por debajo de aproximadamente el 0,3 %. Microsoft siguió el mismo camino en 2025 con exigencias comparables para sus buzones de gran público. Una newsletter de Brevo medianamente activa cruza esos umbrales enseguida.

En concreto, una cuenta de Brevo sin autenticación de dominio marca la casilla «DKIM» en el sentido técnico, pero falla en el criterio de alineación —justo el que esas exigencias apuntan—. Las consecuencias llegan por etapas: primero una clasificación en spam más frecuente, después rechazos puros y duros en las campañas de mayor volumen. Lo que era una buena práctica se ha convertido en el precio de entrada a la bandeja de entrada; la autenticación de dominio ya no es un ajuste de experto, es el billete básico.

La prueba en los informes RUA

Una vez autenticado el dominio, la validación no se lee ni en la interfaz de Brevo ni sobre la fe de un único mensaje de prueba: se lee en los informes agregados DMARC (RUA), enviados cada día por los propios destinatarios. Esos informes recogen, IP por IP, lo que Gmail, Microsoft o Yahoo han observado realmente. Tras la activación, las IP de envío de Brevo deben aparecer ahí con un DKIM «pass» cuyo dominio de firma sea ejemplo.es:

<row>
  <policy_evaluated><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
</row>
<auth_results>
  <dkim><domain>ejemplo.es</domain><selector>mail</selector><result>pass</result></dkim>
</auth_results>

La línea spf de la evaluación suele quedarse en «fail» en el sentido DMARC —es el sobre de la plataforma, no alineado— y es perfectamente normal: el dkim alineado basta para sostener el veredicto global. Los verdaderos puntos de vigilancia están en otra parte: envíos que siguieran firmados por el dominio compartido (una subcuenta olvidada, un flujo transaccional configurado aparte, un departamento que conectó otra herramienta por su cuenta), o una fuente desconocida que emitiera en nombre del dominio sin relación alguna con Brevo. Es exactamente el tipo de deriva que revela una lectura continua de los informes —y que unos archivos XML abiertos a mano no revelarán durante mucho tiempo: la vigilancia con herramientas existe para eso.

En resumen

Una cuenta de Brevo sin autenticar funciona, pero toca techo: firma compartida, reputación diluida, DMARC en fallo permanente. La autenticación de dominio —la clave DKIM bajo mail._domainkey y el código de verificación, con valores suministrados por la plataforma— desplaza la firma al dominio de la organización; es la alineación de ese d= con el From: lo que hace pasar DMARC. SPF, evaluado sobre el sobre de la plataforma, no aporta por lo general esa alineación: DKIM la lleva en solitario, y con eso basta. Las exigencias de Gmail, Yahoo y Microsoft han convertido todo esto en una condición de entrada para el envío en volumen, y los informes RUA aportan la prueba, IP por IP.

Para situar el punto de partida, un paso del dominio por el análisis DMARC gratuito muestra en unos segundos si los envíos firman con el nombre correcto y qué vale la política publicada. La apertura de una cuenta permite después seguir los informes RUA semana tras semana y hacer subir la política hacia p=reject una vez demostrada la alineación —con el tráfico de Brevo autenticado encabezando la marcha.