La alineación DMARC suele pasarse por alto. Un equipo publica SPF, DKIM y DMARC, pero Gmail sigue clasificando algunos mensajes como spam o rechazándolos. Si necesitas repasar el conjunto, consulta nuestra guía de correo empresarial y vuelve aquí para investigar la autenticación y la alineación.
Superar la autenticación no basta: el dominio que pasa SPF o DKIM debe estar alineado con el de From visible. Si ningún mecanismo ofrece un resultado válido y alineado, DMARC falla; eso no demuestra por sí solo una suplantación. Estos problemas aparecen con plataformas de envío, CRM, soporte, reenvíos y configuraciones DNS incompletas.
Veremos cómo funciona la alineación, por qué corregir solo SPF puede no bastar y qué cabeceras revisar. También explicaremos cuándo DKIM puede conservar un resultado satisfactorio de DMARC durante el reenvío, sin garantizar que cualquier ruta mantenga la firma.
Qué es la alineación DMARC
La alineación compara el dominio autenticado por SPF o DKIM con el dominio visible de From. DMARC pasa si SPF pasa y está alineado, o si DKIM pasa y está alineado. Basta con un resultado válido y alineado; falla cuando ninguno de los dos lo aporta.
La regla procede de RFC 7489. DMARC se apoya en SPF y DKIM, no autentica el correo de forma independiente. Comprueba si el dominio autenticado está alineado con el que ve el destinatario.
La comparación es la siguiente:
| Comprobación | Qué verifica el receptor | Qué debe alinearse para DMARC |
|---|---|---|
| SPF | Autorización de la IP para el dominio del remitente del sobre, MAIL FROM / Return-Path | El dominio autenticado del Return-Path debe alinearse con From |
| DKIM | La firma DKIM y su dominio d= | El dominio d= debe alinearse con From |
| DMARC | Resultado de autenticación alineada y política solicitada | Al menos uno de los mecanismos anteriores debe pasar y estar alineado |
En resumen: un SPF o DKIM válido con un dominio no alineado no basta por sí solo. Para DMARC, al menos uno debe pasar y estar alineado con From.
DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)Por qué SPF pasa pero no aporta alineación DMARC
La alineación mediante SPF falla cuando el Return-Path pertenece a un dominio del proveedor no alineado con el tuyo. La IP puede estar autorizada y SPF pasar, pero un dominio de rebotes de SendGrid, Mailchimp, HubSpot o Shopify puede no estar alineado. DMARC todavía puede pasar si DKIM aporta un resultado válido y alineado.
Es un caso habitual. Las plataformas de envío gestionan rebotes, listas de exclusión y eventos, y algunas usan por defecto un Return-Path propio.
From visible: billing@example.com
Return-Path: bounces+123@sendgrid.net
El mensaje puede pasar SPF porque SendGrid autoriza la IP para sendgrid.net. Ese resultado no aporta alineación DMARC: sendgrid.net no está alineado con example.com.
Para alinear SPF, configura el dominio de rebotes o Return-Path personalizado del proveedor. No confundas esa función con la personalización de enlaces o un dominio de seguimiento: estos no cambian necesariamente el remitente del sobre.
bounces.example.com. CNAME u1234.wl.sendgrid.net.El CNAME es ilustrativo. El proveedor debe activar la función y usar realmente bounces.example.com en el remitente del sobre; compruébalo en mensajes reales. En modo relajado, ese dominio está alineado con example.com.
El reenvío introduce otra dificultad. Una universidad, un distribuidor o un buzón personal puede reenviar desde su propia IP, que SPF evalúa frente al dominio del sobre usado en ese salto. Por eso las guías sobre reenviar correo del dominio a Gmail y reenvío con alias tratan fallos SPF. SPF es útil, pero no garantiza superar DMARC tras un reenvío.
Por qué conviene verificar la alineación DKIM
DKIM puede resistir algunos reenvíos mejor que SPF. Para que aporte un resultado satisfactorio de DMARC, la firma debe seguir siendo válida y alineada, y deben conservarse los datos firmados tras la canonicalización. No basta afirmar que el mensaje no cambió de forma importante.
Por eso es recomendable configurar DKIM alineado, especialmente con intermediarios. No es un requisito universal del protocolo cuando SPF ya pasa alineado. Una herramienta que firma con su propio dominio puede pasar DKIM sin aportar alineación para tu dominio.
From visible: newsletter@example.com
Firma DKIM: d=mailchimpapp.net
DKIM puede pasar, pero ese dominio firmante no está alineado. DMARC fallará si SPF tampoco pasa con alineación.
Configura la autenticación de dominio en cada plataforma. Puede requerir publicar los registros DKIM indicados por el proveedor y activar su uso, no solo esperar después de publicarlos.
s1._domainkey.example.com. CNAME s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com. CNAME s2.domainkey.u1234.vendor.net.Una vez configurada y verificada la firma, la plataforma puede usar d=example.com o un subdominio alineado en modo relajado, como d=mail.example.com. DKIM podrá aportar alineación aunque SPF falle por reenvío, siempre que la firma siga siendo válida.
Las directrices de Google citadas requieren para remitentes masivos que SPF o DKIM pase alineado con From y recomiendan configurar ambos adecuadamente. Revisa los requisitos actuales y su ámbito; una autenticación incorrecta puede contribuir a restricciones, pero la alineación no garantiza la bandeja de entrada.
Alineación relajada y estricta
En modo relajado se compara el dominio organizativo; en modo estricto se exige coincidencia exacta del dominio completo. El modo relajado es el predeterminado, pero la elección debe responder a los remitentes y riesgos reales, no a una regla universal.
Las etiquetas aspf para SPF y adkim para DKIM controlan el modo en DMARC.
| Modo | Qué se considera alineado | Efecto operativo |
|---|---|---|
| Relajado | mail.example.com está alineado con example.com | Permite subdominios con el mismo dominio organizativo, no cualquier relación entre dominios |
| Estricto | Solo coincide el dominio exacto | Puede excluir flujos legítimos si autentican otro subdominio |
Ejemplo:
_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"La alineación estricta puede complicar la operación. Si una aplicación firma con mail.example.com y From usa example.com, DKIM deja de aportar alineación estricta; DMARC todavía puede pasar si SPF pasa alineado.
Activa el modo estricto solo por una necesidad concreta y tras revisar todos los flujos. Si mantienes el modo relajado, verifica igualmente que cada remitente autorizado aporta un resultado válido y alineado.
Cómo investigar la alineación DMARC
Revisa las cabeceras recibidas: Authentication-Results, el dominio d= de la firma DKIM, smtp.mailfrom para SPF y el resultado dmarc asociado a header.from. Confía solo en Authentication-Results generado por el receptor que evalúa el mensaje, no en cabeceras añadidas por un remitente.
Si un mensaje parece legítimo pero falla DMARC, esas cabeceras y la firma pueden ayudar a identificar los dominios usados. Contrástalas con la configuración y los registros del servicio.
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net header.s=s1;
spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
dmarc=fail header.from=example.comInterpreta los datos en este orden:
- Revisa
header.from, el dominio visible que DMARC evalúa. - Revisa el dominio SPF en
smtp.mailfrom. Si pertenece al proveedor y no está alineado, SPF no aporta alineación DMARC. - El valor
header.ino sustituye al dominiod=de la firma, que es el usado para alineación DKIM y puede diferir de la identidad i. Comprueba la firma real; un dominio del proveedor no alineado no aporta alineación. - Si ningún resultado satisfactorio está alineado con From, DMARC falla aunque SPF y DKIM indiquen resultados válidos para otros dominios.
También puedes consultar el DNS:
dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.comSi el problema aparece en reenvíos, un fallo SPF puede ser esperable, pero no debe ignorarse automáticamente. Comprueba si DKIM pasa con alineación y conserva los datos firmados tras la canonicalización; un DKIM válido sin alineación no rescata DMARC.
Al configurar un dominio, la guía de configuración de TrekMail y cómo crear correo con tu dominio ayudan a organizar SPF, DKIM y DMARC. Mantén un SPF válido por dominio real del sobre y respeta su límite de mecanismos y modificadores que requieren DNS, también anidados. Elimina registros del proveedor anterior solo después de verificar que ya no se necesitan; no borres todos los MX o selectores indiscriminadamente.
Patrones frecuentes de fallos de alineación
Los proveedores externos, los reenvíos, los subdominios y los registros DNS duplicados o antiguos son puntos habituales de investigación. Identificar un patrón orienta el diagnóstico, pero no demuestra por sí solo la causa.
Revisa estos casos:
- Marketing usa su propio dominio de rebotes: SPF pasa sin alineación; DMARC puede pasar si DKIM aporta un resultado válido y alineado.
- El proveedor firma con su dominio: DKIM pasa sin alineación; SPF válido y alineado todavía puede permitir superar DMARC.
- Un reenvío hace fallar SPF: DKIM debe seguir válido y alineado para aportar el resultado restante.
- El modo estricto impide alinear un subdominio autorizado; revisa si otro mecanismo sí aporta alineación.
- Hay DNS antiguos: confirma qué registros y servicios siguen usándose antes de cambiarlos; un registro obsoleto no prueba que la plataforma siga enviando o firmando.
El error 4.7.32 de Gmail, cuando indica que From no está alineado con SPF o DKIM, señala un problema concreto de alineación. También pueden coexistir problemas de reputación o envío. Consulta las directrices de envío de Google y su ámbito actual.
Corregir la alineación con TrekMail
TrekMail puede reunir gestión de buzones, comprobaciones DNS y opciones de envío según el plan. Centralizar puede facilitar la coordinación entre cinco paneles, pero siguen siendo necesarias las configuraciones correctas y pruebas de cada remitente.
Estas son opciones prácticas.
Gestión dispersa y gestión centralizada
| Gestión dispersa | Gestión con TrekMail |
|---|---|
| Alojar buzones, enviar y registrar DNS en herramientas separadas | Gestionar dominios, buzones, opciones SMTP y controles DNS en la interfaz disponible |
| Depender de instrucciones distintas de cada proveedor | Usar el asistente y contrastar los registros con el servicio real y consultas externas |
| Investigar manualmente reenvíos e incidencias de spam | Verificar DKIM alineado y los reenvíos dentro de un proceso operativo organizado |
Con SMTP gestionado en los planes de pago que lo incluyen, publica los DNS indicados y comprueba la autenticación alineada en mensajes reales. Con SMTP propio en Nano o en los planes compatibles, configura el proveedor real, sea SES, SendGrid, Mailgun u otro. El objetivo es un resultado válido y alineado, no solo una marca positiva en el panel.
Referencias útiles:
La guía Mis correos llegan a spam aborda SPF fallido y DKIM válido en reenvíos, que solo superan DMARC si DKIM también está alineado. La documentación de configuración IMAP & SMTP describe los puntos de conexión para probar el acceso de clientes, una comprobación distinta de la alineación del envío.
La oferta descrita presenta Starter desde $3.50 al mes y una prueba gratuita de 14 días en planes de pago que requiere tarjeta de crédito para iniciarla. Nano se ofrece sin coste con SMTP propio, hasta 10 dominios y 5 GB de almacenamiento compartido bajo sus condiciones. Consulta precios, límites y prestaciones actuales en la página de precios de TrekMail. La copia IMAP no sustituye el cambio de MX ni migra todas las aplicaciones, y comparar modelos de precios no garantiza ahorro.
Lista final para la alineación DMARC
Una implantación controlada busca que cada remitente autorizado pase SPF o DKIM con alineación, o ambos cuando sea posible. Eso ayuda a evaluar las restricciones, pero no elimina todos los riesgos de reenvío ni garantiza la entrega.
- Enumera todos los remitentes: alojamiento de buzones, CRM, facturación, soporte, tienda, formularios y marketing.
- Confirma el dominio visible de From de cada servicio.
- Comprueba SPF y la alineación del dominio real del Return-Path, no solo su presencia.
- Configura y verifica DKIM del proveedor con alineación a tu dominio, especialmente para rutas con reenvío.
- Mantén
aspf=ryadkim=rsalvo que una necesidad probada justifique el modo estricto. - Envía pruebas a Gmail y revisa Authentication-Results generado por el receptor y el dominio real de la firma DKIM.
- Considera mantener
p=nonemientras validas los flujos; no solicita restricciones DMARC, pero los filtros locales siguen aplicándose. - Aplica restricciones tras contrastar los informes parciales con inventarios, registros y pruebas de flujos críticos poco frecuentes, y evaluar los fallos restantes y las excepciones locales.
La alineación es una condición de autenticación DMARC, no un clasificador infalible entre correo legítimo y suplantado ni una garantía de contenido seguro. Para coordinar varios dominios, puedes evaluar TrekMail según sus planes y tu operación, sin asumir ahorro frente a la facturación por usuario.
