Por qué falla aunque el servicio «funcione»
DMARC no se conforma con que el correo pase SPF o DKIM: exige que pasen con tu dominio, el mismo que ve el destinatario en el remitente. Muchos servicios, si no los configuras, firman con su propio dominio (sendgrid.net, amazonses.com, mcsv.net…) y usan su propio dominio como remitente técnico. El correo pasa SPF y DKIM, pero no para tu dominio, y falla DMARC.
En los informes lo verás como una fuente en ámbar: un servicio conocido que no pasa DMARC.
La solución: autenticar tu dominio en el servicio
- Identifica el servicio. En la pestaña Fuentes de VigíaMail aparece su nombre si es conocido, o su IP y su servidor. Si no lo reconoces, pregunta a quien gestiona tu web, tu tienda o tu CRM.
- Busca en su panel la autenticación de dominio. Cada servicio la llama de una forma: «Authenticate your domain», «Domain authentication», «Verificar dominio», «Dominios de envío» o simplemente «DKIM». Suele estar en la configuración de la cuenta, en un apartado de dominios o remitentes.
- Publica los registros que te da. Normalmente son dos o tres CNAME (o TXT) con nombres como estos:
s1._domainkey.tudominio.esTipoCNAMEValor(el que te dé el servicio)- Pulsa «Verificar» en el servicio. A partir de ahí firma con tu dominio y su correo pasa DMARC.
- Comprueba. Envía una prueba a una cuenta de Gmail, abre Más → Mostrar original y busca
DKIM: PASScon tu dominio yDMARC: PASS. En los informes de los días siguientes, la fuente pasará a verde.
Con el DKIM alineado basta para pasar DMARC. Si además quieres el SPF alineado, configura en el servicio un remitente técnico propio (lo suelen llamar «Return-Path», «MAIL FROM» o «dominio de rebotes»), por ejemplo rebotes.tudominio.es; te dará también sus registros.
Los dos errores más habituales
1. Añadir el include al SPF y darlo por hecho
Muchos servicios te piden añadir su include: a tu SPF. Si el servicio usa su propio dominio como remitente técnico, ese include: no ayuda a pasar DMARC: el SPF se comprueba con su dominio, no con el tuyo. Además gasta consultas del límite de 10 y puede romper tu SPF (SPF permerror). Lo que arregla DMARC es el DKIM con tu dominio.
2. Publicar los registros en el dominio equivocado
Los registros van en el dominio que configuras en el servicio. Si envías como noticias@boletin.tudominio.es y autenticas boletin.tudominio.es, los registros van en ese subdominio, no en tudominio.es. Con la alineación relajada (la habitual), una firma de tudominio.es también vale para sus subdominios; con adkim=s en tu DMARC tiene que ser exactamente el mismo dominio.
Si el servicio no permite usar tu dominio
avisos@herramienta.com) en lugar de la tuya; que envíen a través de tu propio correo (por SMTP con tu Microsoft 365 o Google Workspace); o cambiar a un servicio que sí lo permita. Bajar tu política DMARC para «salvar» ese servicio deja tu dominio sin protección.Consejo de Microsoft que compartimos: para envíos masivos (newsletters, marketing), usa un subdominio como boletin.tudominio.es. Así, si algo va mal con esos envíos, no afecta a la reputación del correo de tu equipo.
Comprueba el resultado
Cuando hayas publicado los registros, analiza tu dominio: te diremos si SPF, DKIM y DMARC están bien y, si algo falla, qué registro tocar.