Mi verificación de SPF pasa. ¿Por qué DMARC igual falla?

Porque DMARC revisa la alineación, no solo el resultado del SPF. El SPF autentica al remitente del sobre, que muchos proveedores transaccionales ponen en su propio dominio. La verificación pasa para el proveedor y el dominio no coincide con tu encabezado From, así que el resultado no cuenta para DMARC a menos que el DKIM se alinee.

¿Basta con Easy DKIM en Amazon SES o necesito un dominio MAIL FROM personalizado?

Easy DKIM por sí solo puede pasar DMARC, porque SES firma con tu dominio y la alineación por DKIM alcanza. El dominio MAIL FROM personalizado agrega SPF alineado como segunda vía, que es lo que quieres cuando un reenvío rompe la firma DKIM. Necesita un registro MX y un TXT de SPF sobre un subdominio de la identidad que verificaste.

¿El correo transaccional va en un subdominio o en el dominio raíz?

En un subdominio en la mayoría de los casos. Separa la reputación del proveedor del correo que envía tu equipo, le da a ese proveedor su propio registro SPF con su propio presupuesto de diez consultas, y por la alineación relajada sigue cumpliendo DMARC para un From en el dominio raíz.

Alineación DMARC en SendGrid, Mailgun y Amazon SES

Una tienda en línea de diez personas con la que trabajaríamos normalmente tenía un reclamo que sonaba a nada. Las confirmaciones de pedido de la plataforma llegaban bien. Los restablecimientos de contraseña y los recibos de pago, enviados por el desarrollador a través de un proveedor transaccional, caían en la carpeta de spam de Gmail más o menos la mitad de las veces. Alguien ya había revisado el SPF, el SPF pasaba, y la conversación siguió hacia los asuntos y las imágenes.

Que el SPF pase no es la prueba. DMARC hace una segunda pregunta, y el correo transaccional es donde la respuesta suele salir mal. Además es invisible desde afuera: el registro se ve correcto, el panel del proveedor dice que el dominio está verificado, y el correo igual falla.

Por qué el correo transaccional falla DMARC aunque el SPF se vea bien

A DMARC no le importa que un mensaje haya pasado SPF. Le importa si el dominio que pasó es el dominio que ve quien lee. Eso es la alineación, y el RFC 7489 cabe en una frase: un mensaje pasa DMARC cuando el SPF pasa y su dominio se alinea con el encabezado From, o cuando el DKIM pasa y su dominio se alinea, o ambas. Basta con una de las dos.

Google dice lo mismo desde el lado del receptor. Sus lineamientos para remitentes exigen que quien envía más de 5,000 mensajes al día a cuentas de Gmail publique SPF, DKIM y un registro DMARC, y que el dominio del From se alinee con el dominio del SPF o con el del DKIM. Los dos mecanismos son obligatorios, una sola alineación alcanza, y el correo que falla puede ser rechazado con un error 5.7.26. Lineamientos consultados el 28 de septiembre de 2026.

Las plataformas de marketing suelen romper esto del lado del DKIM, que es lo que cubre la guía sobre alineación en Mailchimp, HubSpot y Klaviyo. Los proveedores transaccionales lo rompen en un lugar más específico: el sobre.

Remitente del sobre contra encabezado From

Todo mensaje lleva dos direcciones de remitente y la mayoría de la gente solo ve una.

El remitente del sobre, también llamado return path o MAIL FROM, es la dirección que el servidor entrega durante la conversación SMTP. Ahí llegan los rebotes. Nadie la lee. El SPF autentica esa.
El encabezado From es la dirección que va dentro del mensaje, la que ve quien lo recibe y la que querría falsificar alguien que hace phishing. DMARC protege esa.

Cuando las dos son tuyas, la alineación del SPF ocurre sola. Cuando un proveedor pone su propio dominio en el sobre y deja tu nombre en el From, el SPF pasa para el proveedor y no se alinea con nada. Al receptor le queda una sola oportunidad: el DKIM. Si el DKIM firma con el dominio del proveedor en la etiqueta d= en lugar del tuyo, DMARC falla, y el reporte que leas después mostrará un pass de SPF junto a un fail del mensaje.

La alineación tiene dos modos y el predeterminado es el permisivo. La alineación relajada, aspf=r y adkim=r, acepta cualquier subdominio del mismo dominio organizacional, así que mail.ejemplo.com se alinea con ejemplo.com. La estricta exige coincidencia exacta. Casi todas las soluciones de abajo funcionan porque el modo relajado es el predeterminado.

De aquí en adelante, todo se reduce a dos movimientos: que el dominio del sobre sea tuyo, o que el d= del DKIM sea tuyo.

SendGrid: la autenticación de dominio resuelve las dos, si la terminas

Con una API key basta para enviar por SendGrid. No basta para pasar DMARC. El paso que importa es la autenticación de dominio, antes llamada sender authentication, y consiste en registros CNAME que publicas en tu propio dominio en lugar de registros TXT que pegas a mano.

Con Automated Security activado, SendGrid genera tres CNAME: dos para DKIM y uno que crea un subdominio de marca usado para el return path. Los registros de DKIM usan los selectores s1 y s2, así que publicas algo con esta forma, tomando los valores de destino de tu propio panel porque llevan identificadores de tu cuenta:

s1._domainkey.ejemplo.com.   CNAME   s1.domainkey.uNNNNNN.wlNNN.sendgrid.net.
s2._domainkey.ejemplo.com.   CNAME   s2.domainkey.uNNNNNN.wlNNN.sendgrid.net.
emNNNN.ejemplo.com.          CNAME   uNNNNNN.wlNNN.sendgrid.net.

Dos selectores de DKIM en vez de uno es la forma en que SendGrid rota las llaves sin que tú intervengas. Una vez verificado, SendGrid firma tu correo con tu dominio en d=, así que el DKIM se alinea, y el subdominio de marca deja el return path dentro de tu dominio organizacional, con lo que el SPF también se alinea en modo relajado. Eso es un mensaje que pasa DMARC por los dos mecanismos, que es donde quieres tener un recibo.

Dos cosas salen mal en este paso, una y otra vez. La primera es un proveedor de DNS que no acepta guiones bajos en el nombre de un CNAME, algo común en paneles de hosting compartido antiguos. La respuesta de SendGrid es desactivar Automated Security en la configuración avanzada y publicar registros MX y TXT a mano, a cambio de encargarte tú de la rotación de llaves. La segunda es un proveedor que pone los registros detrás de su proxy por defecto, siendo Cloudflare el ejemplo habitual: un CNAME de autenticación proxeado resuelve al proxy y no a SendGrid, así que la verificación falla o deja de funcionar más adelante. Todos los registros de ese conjunto tienen que quedar en modo solo DNS.

Mailgun: el subdominio de envío hace casi todo el trabajo

Mailgun pide verificar un dominio antes de enviar, y la verificación existe por dos razones: comprobar que el nombre es tuyo y autorizar a los servidores de Mailgun a enviar como él. Su configuración documentada son dos registros TXT, uno de SPF y uno de DKIM, y su recomendación es usar un subdominio como mg.ejemplo.com en lugar del dominio raíz, lo que mantiene la reputación de envío de Mailgun separada del correo que tu equipo escribe a mano.

mg.ejemplo.com.                 TXT   "v=spf1 include:mailgun.org ~all"
mx._domainkey.mg.ejemplo.com.   TXT   "k=rsa; p=MIGfMA0GCSq..."

Ese subdominio es la razón por la que Mailgun suele ser el más sencillo de los tres. El correo sale con el remitente del sobre en tu dominio de envío y firmado con d=mg.ejemplo.com, y en alineación relajada los dos coinciden con un From en ejemplo.com. Publica el registro SPF en el subdominio, no en la raíz; un segundo registro SPF en la raíz no es una solución, es un error permanente, porque un dominio puede publicar exactamente uno.

Amazon SES: Easy DKIM sí alinea, el MAIL FROM por defecto no

SES es el que agarra desprevenida a gente cuidadosa, porque la configuración por defecto pasa SPF y falla DMARC al mismo tiempo.

Cuando envías por SES sin configurar un dominio MAIL FROM, el remitente del sobre es un subdominio de amazonses.com. Ese dominio publica un registro SPF válido que cubre la infraestructura de SES, así que la verificación de SPF pasa sin problema. Solo que pasa para Amazon. El dominio del sobre y tu dominio del From no coinciden, así que la alineación del SPF falla y DMARC solo puede satisfacerse por DKIM.

Easy DKIM sí lo satisface. SES publica registros CNAME que le permiten firmar con tu dominio, así que una identidad verificada con Easy DKIM activado se alinea por DKIM y pasa DMARC. Muchos remitentes pequeños se quedan ahí y les funciona. Es un punto único de falla, eso sí: un registro DKIM roto, un mensaje modificado por un reenvío, y no hay alineación de SPF debajo para atajarlo.

La solución es un dominio MAIL FROM personalizado, que siempre es un subdominio de la identidad que verificaste. AWS documenta dos registros sobre él: un MX para que la retroalimentación de rebotes llegue a SES, y un TXT que publica el SPF.

mail.ejemplo.com.   MX    10 feedback-smtp.us-east-1.amazonses.com.
mail.ejemplo.com.   TXT   "v=spf1 include:amazonses.com ~all"

Usa en el valor del MX la región desde la que realmente envías. Como el dominio MAIL FROM personalizado es un subdominio y no una coincidencia exacta, esto solo se alinea con la política de SPF relajada, que es la predeterminada; un registro DMARC con aspf=s tira abajo todo el arreglo. Configúralo en cada región y en cada cuenta desde la que envías, no solo en producción, o la primera factura enviada desde una cuenta de pruebas será la que falle.

Un dominio, tres remitentes, diez consultas

La mayoría de los dominios que auditamos no envían por un solo proveedor. Hay un Google Workspace para el personal, una plataforma de tienda para el correo de pedidos, un proveedor transaccional para los recibos y algo que nadie recuerda haber activado para el boletín mensual. Cada uno quiere un include: en el registro SPF, y el SPF permite diez consultas DNS por evaluación según el RFC 7208, sección 4.6.4. Si te pasas, el resultado es PermError, y la mayoría de los receptores lo tratan como si no hubiera SPF.

Los subdominios son la salida. Un proveedor transaccional en mail.ejemplo.com y una plataforma de marketing en news.ejemplo.com llevan cada uno su propio registro SPF con su propio presupuesto de consultas, mientras la raíz conserva solo los remitentes que de verdad la usan, y por la alineación relajada todos siguen cumpliendo DMARC para un From en ejemplo.com. Si ya estás en el límite, la guía sobre cómo bajar de 10 consultas DNS en SPF trae el método para contarlas.

Qué política corresponde a cada subdominio está en el artículo sobre subdominios en DMARC y la etiqueta sp.

Qué revisamos antes y después del cambio

Este es el orden en que trabajamos sobre el dominio de un cliente, y es aburrido a propósito.

Primero el inventario, después el DNS. Leemos dos semanas de reportes agregados de DMARC y listamos cada fuente que envía como el dominio. Cambiar registros antes de saber quién envía es la forma de que dejen de llegar las facturas.
Confirmamos que la política siga en p=none mientras dura el trabajo, con una dirección rua que alguien lea. Nada de lo de abajo es seguro de hacer bajo aplicación estricta.
Arreglamos un proveedor a la vez y enviamos un mensaje real después de cada uno, a un buzón en una plataforma distinta de la que usas todos los días.
Leemos las cabeceras de ese mensaje en lugar de confiar en un panel. La línea Authentication-Results nombra el dominio del SPF y el valor d= del DKIM, que es el único lugar donde la alineación se ve.
Esperamos un ciclo más de reportes antes de tocar la política y después subimos, cuarentena antes que reject, con la lista de remitentes externos revisada y no supuesta.

La falla que más vemos es el paso tres saltado: tres proveedores arreglados en una tarde, uno de ellos mal, y ninguna manera de saber cuál sin empezar de nuevo.

Cómo ayuda Guanacos Tech

Somos una consultoría independiente con ingenieros certificados por Google, y trabajamos con empresas pequeñas y medianas de Norteamérica y Latinoamérica, en inglés y español. El correo transaccional es una forma normal de que este trabajo empiece: recibos que se pierden, un desarrollador que es dueño de la API key y nadie que sea dueño de la zona DNS. Construimos el inventario de remitentes con tus propios reportes, arreglamos cada proveedor para que se alinee por los dos mecanismos donde el proveedor lo permita, mantenemos el registro SPF dentro de su presupuesto de consultas y después subimos la política hasta aplicación estricta con un calendario en vez de una esperanza.

Si prefieres mirar tú primero, el analizador de reportes DMARC y el diagnóstico de correo son gratis y no piden cuenta. Si prefieres delegarlo, aquí está nuestra consultoría de entregabilidad de correo y cómo trabajamos. Lleva a la llamada un recibo rebotado con sus cabeceras completas y normalmente podemos nombrar la causa en pantalla.

Documentación de proveedores de SendGrid, Mailgun y Amazon SES consultada el 28 de septiembre de 2026.

Recibos que pasan SPF y aun así fallan DMARC: alineación en SendGrid, Mailgun y Amazon SES