// cómo solucionarlo
Los CNAME de autenticación de dominio de SendGrid no se verifican: cómo solucionarlo
¿SendGrid dice que tus CNAME em, s1._domainkey o s2._domainkey no son válidos? Corrige nombres duplicados, el proxy de Cloudflare, conflictos y propagación.
Qué significa
En Twilio SendGrid, Domain Authentication (Settings > Sender Authentication) te pide que publiques registros DNS y después hagas clic en Verify. Si SendGrid no los encuentra con el valor correcto, los muestra como no verificados y tu dominio sigue sin autenticar.
Con "Use automated security" activado (la opción por defecto), SendGrid te da tres registros CNAME y te sugiere un registro DMARC. Los nombres y destinos contienen números únicos para tu cuenta:
em1234.yourdomain.com CNAME u1234567.wl123.sendgrid.net s1._domainkey.yourdomain.com CNAME s1.domainkey.u1234567.wl123.sendgrid.net s2._domainkey.yourdomain.com CNAME s2.domainkey.u1234567.wl123.sendgrid.net _dmarc.yourdomain.com TXT "v=DMARC1; p=none;"
El registro em se usa para el Return-Path (dominio de rebote, lo que hace que SPF se alinee). Los dos registros _domainkey apuntan a claves DKIM que SendGrid rota por ti. Copia siempre tus propios valores desde la consola; los de arriba son ejemplos.
Por qué ocurre
- Nombre de dominio duplicado. Tu panel DNS añade
yourdomain.comautomáticamente, así queem1234.yourdomain.comse convierte enem1234.yourdomain.com.yourdomain.com. Es la causa más habitual; consulta registro DNS añadido con un nombre incorrecto. - Proxy de Cloudflare. Un CNAME con proxy (nube naranja) responde con direcciones IP de Cloudflare en lugar del destino del CNAME. Consulta los registros con proxy de Cloudflare rompen el email.
- Un registro en conflicto. Un CNAME no puede convivir con otro registro del mismo nombre. Un TXT o un MX antiguo en
em1234os1._domainkeylo bloquea. Consulta los conflictos de CNAME con registros MX y TXT. - Errata en el destino, o un problema con el punto final en los paneles que esperan un nombre completo.
- Registros añadidos en la zona DNS equivocada. El DNS de tu dominio lo sirve otro proveedor (revisa los registros NS), así que los registros añadidos en tu registrador nunca se ven.
- Todavía no son visibles. Algunos proveedores DNS tardan en publicar los registros nuevos; SendGrid menciona hasta 48 horas en algunos casos.
- Dominio autenticado equivocado: autenticaste
yourdomain.compero añadiste registros para un subdominio, o al revés.
Cómo comprobarlo
- Consulta cada registro desde un terminal. Una respuesta correcta devuelve el destino de SendGrid:
dig +short CNAME em1234.yourdomain.com dig +short CNAME s1._domainkey.yourdomain.com dig +short CNAME s2._domainkey.yourdomain.com dig +short NS yourdomain.com
Una respuesta vacía significa que el registro no está (o todavía no). Las direcciones IP indican un proxy. - Comprueba si el nombre está duplicado:
dig +short CNAME em1234.yourdomain.com.yourdomain.com. Si responde, el nombre se introdujo mal. - Usa el escáner de dominios de Delivmail para ver los registros SPF, DMARC y DKIM que los demás ven para tu dominio.
Cómo solucionarlo
- En tu panel DNS, abre cada registro e introduce en el campo del nombre solo la parte anterior a tu dominio:
em1234,s1._domainkey,s2._domainkey. - Pega el destino exactamente como lo muestra SendGrid. Elige el tipo de registro CNAME, no TXT.
- En Cloudflare, cambia cada registro a "DNS only".
- Elimina los registros antiguos con los mismos nombres, incluidos los antiguos TXT de DKIM para
s1/s2de una configuración anterior. - Asegúrate de editar la zona del proveedor DNS que aparece en tus registros NS.
- Si tu proveedor DNS no acepta guiones bajos en los nombres CNAME, desactiva la seguridad automática en SendGrid (entonces te da registros MX y TXT) o lleva tu DNS a un proveedor que admita los registros estándar.
- De vuelta en SendGrid, haz clic en Verify. Si un registro sigue fallando, SendGrid te indica cuál.
SPF y registros existentes
Con la seguridad automática no necesitas añadir SendGrid a tu registro SPF raíz: SPF se comprueba en el subdominio em, que sigue el SPF de SendGrid a través del CNAME. Mantén tu SPF raíz actual para tus otros servicios. Para saber cómo funciona DKIM con CNAME, consulta DKIM con registros CNAME (selectores delegados).
Comprueba que está solucionado
Cuando dig devuelva los destinos correctos, vuelve a hacer clic en Verify en SendGrid; todos los registros deberían ponerse en verde. Después envía una prueba a través de SendGrid a la dirección de la página de inicio de Delivmail: DKIM debería superarse con d=yourdomain.com, el Return-Path debería estar en em1234.yourdomain.com y DMARC debería superarse. Si los registros son correctos pero SendGrid sigue sin verificarlos pasado el plazo de propagación, contacta con el soporte de SendGrid adjuntando la salida de dig.
Comprueba que está solucionado
Un cambio de DNS puede tardar de unos minutos a unas horas. Después, envía un nuevo email de prueba o vuelve a escanear tu dominio.
Guías relacionadas
- Tu dominio no tiene registro SPFTu dominio no indica qué servidores pueden enviar emails en su nombre. Añade un registro TXT y los receptores podrán distinguir tus emails reales de los falsos.
- Error SPF: demasiadas consultas DNS (permerror)SPF permite como máximo 10 consultas DNS. Por encima, todo el registro se rompe y los receptores lo consideran no válido. Así puedes aligerarlo.
- Varios registros SPF en un mismo dominioUn dominio solo debe tener un registro SPF. Con dos o más, SPF falla en todos los emails. Únelos en una sola línea.
- SPF falla: el servidor de envío no está autorizadoTu dominio tiene un registro SPF, pero el servidor que envió tu email no está en él. Averigua qué servicio envió el email y añádelo.
- Tus emails no tienen firma DKIMDKIM añade una firma digital que demuestra que un email viene de verdad de tu dominio. Actívala en tu proveedor de correo y publica su clave en el DNS.