SendGrid: configurar el dominio autenticado (SPF/DKIM)

em1234.ejemplo.es.         CNAME  u1234567.wl123.sendgrid.net.
s1._domainkey.ejemplo.es.  CNAME  s1.domainkey.u1234567.wl123.sendgrid.net.
s2._domainkey.ejemplo.es.  CNAME  s2.domainkey.u1234567.wl123.sendgrid.net.

La alineación DMARC: el escenario favorable

DMARC solo da por válido un mensaje si SPF o DKIM pasa y se alinea con el dominio del From. Es exactamente ahí donde la autenticación de dominio de SendGrid destaca.

En el lado DKIM, la firma lleva d=ejemplo.es —el dominio mismo, no un dominio de la plataforma—. La alineación queda garantizada, incluso en modo estricto. En el lado SPF, el sobre de los mensajes pasa a ser bounce@em1234.ejemplo.es: un subdominio del dominio organizativo. En modo relajado —el valor por defecto de DMARC—, ese subdominio se alinea con ejemplo.es; bajo DMARCbis, el dominio organizativo se determina mediante el DNS Tree Walk, con idéntico resultado. Los dos mecanismos pasan, pues, alineados, y esa redundancia tiene valor operativo: si un reenvío rompe SPF al cambiar la IP emisora, DKIM sobrevive; si una pasarela altera el cuerpo del mensaje e invalida la firma, SPF permanece.

La comparación con otros ESP ilustra lo que este montaje tiene de favorable. En Mailchimp, la alineación descansa solo en DKIM: el sobre se queda en los dominios de la plataforma, SPF pasa pero no se alinea nunca —un funcionamiento conforme y suficiente, pero sin red—. La configuración SPF y DKIM en Mailjet sigue un modelo intermedio, con registros que copiar en la zona en lugar de una delegación completa. SendGrid, al delegar a la vez los selectores DKIM y el subdominio de sobre, obtiene la doble alineación sin que un solo valor se transcriba a mano: el montaje más robusto que un ESP puede ofrecer hoy.

El link branding: coherencia de dominio hasta en los enlaces

La misma mecánica de CNAME se aplica a una segunda función, distinta pero complementaria: el «link branding». Por defecto, el seguimiento de clics de SendGrid reescribe cada enlace de un mensaje hacia un dominio de la plataforma. Con el link branding, la reescritura apunta a un subdominio del dominio remitente —url1234.ejemplo.es, o el prefijo que se elija—, delegado también por CNAME.

DMARC no evalúa los enlaces: esta pieza no cambia nada en la alineación. Lo que cambia es la coherencia percibida del mensaje. Un correo firmado ejemplo.es cuyos enlaces apuntan todos a un dominio de tracking ajeno emite una señal discordante, tanto para los filtros antispam como para los destinatarios atentos que pasan el cursor por un enlace antes de hacer clic. La coherencia de dominio —From, sobre, enlaces, todo bajo la misma bandera— alimenta la reputación global; los enlaces de seguimiento fuera de dominio figuran entre los factores examinados en por qué los correos acaban en spam. Ya que se colocan CNAME en la zona, completar el conjunto cuesta poco: la configuración sigue el mismo asistente y la misma lógica de validación.

Los errores frecuentes que hacen fracasar la validación

La configuración cabe en tres registros, pero un puñado de trampas se repite constantemente.

• Los CNAME con proxy detrás de un CDN. Es el error número uno en las zonas gestionadas en Cloudflare: el proxy (el icono de la nube naranja) intercepta la resolución y sustituye el destino del CNAME por sus propias direcciones. La validación de SendGrid falla —o peor, pasa y luego se rompe en silencio—. Los tres registros deben quedar en «DNS only», sin proxy: son registros de correo, no tráfico web que acelerar.
• El subdominio em ya ocupado. Un vestigio de una integración pasada, una segunda cuenta SendGrid, un comodín existente en la zona: si el nombre propuesto colisiona, la validación no pasa limpiamente. La respuesta correcta es elegir otro prefijo mediante la opción de Return-Path personalizado (em2, m1…), nunca machacar un registro existente del que quizá dependa otro flujo.
• La duplicación del dominio. Muchas interfaces DNS añaden automáticamente el dominio al final del nombre introducido: pegar em1234.ejemplo.es en el campo «nombre» produce em1234.ejemplo.es.ejemplo.es. Una consulta dig sobre el nombre exacto esperado despeja la duda en diez segundos.
• La validación probada demasiado pronto, o nunca relanzada. La propagación DNS tarda de minutos a horas según los TTL. Un fallo inmediato no prueba nada; hay que repetir la verificación una vez completada la propagación, porque la plataforma solo firma en nombre del dominio después de validar.
• Los CNAME borrados a posteriori. La validación no es un examen que se aprueba una vez: los registros sirven a cada mensaje, en cada verificación DKIM y SPF de los destinatarios. Una «limpieza» de zona que los retire rompe la autenticación de la noche a la mañana.

Verificar el resultado en los informes RUA

El distintivo «verified» de la interfaz de SendGrid confirma que los CNAME responden —no que el correo real salga alineado—. La prueba se lee en los informes agregados DMARC, unos días después de la activación.

En los informes RUA, las líneas atribuidas a las direcciones de envío de SendGrid deben presentar dos resultados: DKIM pass con d=ejemplo.es (selector s1 o s2) y la alineación conseguida; SPF pass con em1234.ejemplo.es como dominio de sobre, alineado en modo relajado. Las desviaciones se diagnostican rápido: un DKIM que pasa con d=sendgrid.net delata un flujo que no usa el dominio autenticado —un subusuario sin vincular, una segunda cuenta olvidada, una integración que apunta a otra parte—; un SPF que pasa sin alinearse, con un dominio de sobre de la plataforma, revela el mismo síntoma. Esas líneas volverían a ser rechazos bajo p=reject.

Cuando los dos mecanismos se mantienen en verde durante varias semanas de informes, y en el conjunto de los flujos SendGrid (transaccional y marketing, todos los subusuarios incluidos), el endurecimiento de la política puede seguir su curso —modo de prueba t=y de DMARCbis, luego p=quarantine, luego p=reject— sin riesgo para este canal.

En resumen

La autenticación de dominio de SendGrid se apoya en tres CNAME: un subdominio de sobre (em1234) y dos selectores DKIM (s1._domainkey, s2._domainkey), que delegan en la plataforma la publicación de las claves y del registro SPF. La «automated security» hace invisible la rotación de claves; la doble alineación —DKIM sobre el dominio, SPF sobre un subdominio delegado— lo convierte en uno de los montajes más sólidos del mercado de los ESP. Las trampas clásicas son de naturaleza DNS: proxy de CDN que desactivar en esos registros, colisión en el subdominio em, duplicación del dominio, validación que repetir tras la propagación. Y el veredicto final no se lee ni en la interfaz ni en una prueba aislada, sino en los informes agregados.

Para fijar el punto de partida, un análisis DMARC gratuito del dominio revela en segundos si el flujo SendGrid ya firma con el nombre correcto y si el sobre se alinea. Y para seguir el efecto de los tres CNAME a lo largo del tiempo, la creación de una cuenta da acceso a los informes RUA descodificados, fuente por fuente: la contraprueba que convierte una casilla verde en certeza.