Tu SPF pasa, tu DKIM pasa, y DMARC falla igual

La factura del ERP deja de llegar a un cliente. Miras la cabecera y lees spf=pass, lees dkim=pass, y dos campos más allá, dmarc=fail. Nadie se ha equivocado al escribir el DNS. Falla otra cosa.

Esa combinación es, con diferencia, la que más veces nos hemos encontrado al entrar en un dominio ajeno, y casi siempre llega envuelta en la misma frase: «pero si el correo está bien configurado, lo comprobamos». Y es verdad que está bien configurado. SPF autoriza al servidor que envía. DKIM firma el mensaje y la firma valida. Las dos comprobaciones pasan por separado y el mensaje se rechaza igual, porque DMARC no pregunta si pasan: pregunta si coinciden con el remitente que ve el destinatario.

Hay dos remitentes, y tú solo ves uno

Todo correo de internet lleva dos direcciones de remitente, y la documentación de Microsoft las separa con nombre y apellidos. La primera es la dirección MAIL FROM, «the email address used in the transmission of the message between SMTP email servers», también llamada 5321.MailFrom o remitente de sobre. La segunda es la dirección From, la del encabezado, «shown as the message sender in email clients», también 5322.From. La primera la usan los servidores. La segunda es la que tu cliente lee en su Outlook.

SPF y DKIM, por sí solos, no exigen que esas dos direcciones tengan nada que ver. Lo dice la propia página: «SPF and DKIM don't require the domains in the following email addresses to "align" (match)». Ahí está el hueco por el que entra la suplantación: un atacante puede montar un dominio, publicar un SPF impecable para él, firmar con DKIM impecablemente, y poner en el campo From el nombre de tu empresa. Las dos comprobaciones pasan. El remitente que se lee es el tuyo. De cómo se explota esa confianza por teléfono ya escribimos al hablar de quién verifica en tu mesa de ayuda que eres quien dices; esto es la versión por escrito.

DMARC cierra ese hueco añadiendo una pregunta más: ¿el dominio que acaba de pasar SPF o DKIM es el mismo que el del From? A eso se le llama alineación, y la regla completa cabe en una línea de la documentación: «A message passes DMARC if one or both of the described SPF or DKIM checks pass. A message fails DMARC if both of the described SPF and DKIM checks fail» — donde «pasar» ya incluye estar alineado. Con una de las dos alineada basta. Si no se alinea ninguna, da igual que las dos validaran.

Cómo se ve esto en una cabecera

La propia documentación trae el ejemplo, y es calcado al de la factura del principio. Esta es la cabecera de un mensaje en el que las dos comprobaciones validan y aun así se rechaza:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Los tres campos que hay que mirar, en este orden: header.from= es el dominio que lee el destinatario; smtp.mailfrom= es el del sobre; header.d= es el que firmó. Aquí el primero dice contoso.com y los otros dos dicen adatum.com. Ninguno alinea, y por eso el resultado es dmarc=fail con action=oreject — la «o» es de origen, y significa que el rechazo lo pidió la política del dominio remitente. Si ves action=pct.reject, el remitente publicó p=reject con un pct= menor de 100 y a tu mensaje le tocó estar en la muestra.

La tabla que conviene tener impresa

Microsoft publica una tabla de alineación con cinco filas. Las etiquetas aspf y adkim del registro deciden cuánto se exige: relaxed (r, el valor por defecto) acepta subdominios del mismo dominio organizativo; strict (s) exige coincidencia exacta. Esta es la tabla, con el dominio de la cabecera From a la izquierda y el dominio del MAIL FROM o de la firma DKIM a la derecha:

La cuarta fila es la que sorprende a más gente, porque parece de casa y no lo es, y no la salva ni el modo relajado: un correo cuyo From es @contoso.com firmado con el dominio contoso.onmicrosoft.com no alinea. Son dos dominios organizativos distintos, por mucho que uno sea el tenant del otro. Es el caso típico de quien dio de alta el dominio propio y nunca llegó a configurar la firma DKIM con él, y es otro recordatorio de que el dominio onmicrosoft.com no es un sitio donde quedarse a vivir.

Dónde se rompe de verdad: en tus aplicaciones

El correo que escriben las personas desde Outlook casi nunca es el problema: sale del tenant, con el dominio propio en las dos direcciones, y alinea solo. El problema vive en todo lo demás que manda correo poniendo tu dominio en el From sin que nadie lo tenga apuntado en ninguna parte. La lista real de una pyme, la que sale cuando te sientas a hacerla, suele ser esta:

Para cada uno, la documentación de Microsoft da exactamente dos salidas, y conviene leerlas antes de empezar a tocar registros. Una: cambiar el MAIL FROM del servicio a un dominio tuyo —la resolución literal que propone para el escenario de un servicio externo que envía en tu nombre es «Configure DKIM signing with your domain at the service, or change MAIL FROM to your domain/subdomain». Dos: que el servicio firme con DKIM usando tu dominio, es decir con d=tudominio.com. Si el proveedor no permite ninguna de las dos, queda la tercera vía que la propia guía recomienda y que casi nadie aplica: usar un subdominio para ese servicio —«for email services that aren't under your direct control (for example, bulk email services), use a subdomain»— y publicarle su propio registro DMARC, para que un problema de reputación suyo no se lleve por delante el correo de tu gente.

El informe que te dice quién manda en tu nombre

Esa lista la publica el propio protocolo, si se la pides. Un registro con rua=mailto: pide a los destinatarios un informe agregado en XML, normalmente diario, con, literalmente, «the IP addresses of servers or services that send mail using your domain» y si pasan o fallan. Es el censo de remitentes que nadie tiene escrito.

Leerlo tiene truco, y es el mismo truco de todo el post. En el XML hay dos bloques que parecen lo mismo y no lo son: <auth_results> dice si SPF y DKIM validaron en crudo, y <policy_evaluated> dice si alinearon. La guía de Microsoft lo señala como la lectura más importante del informe: «The most important insight from aggregate reports is identifying the gap between authentication pass and alignment pass». Un bloque con <spf><result>pass</result></spf> en el primero y <spf>fail</spf> en el segundo es exactamente el ERP del principio, con su IP al lado para que sepas de cuál hablamos.

Dos trampas operativas de las que casi nadie avisa, y que están escritas en la misma página. La primera: Microsoft 365 no envía informes forenses (ruf=) aunque pongas una dirección válida, así que si esperas esos correos para depurar, no van a llegar de ahí. La segunda, más gorda: Microsoft 365 solo envía informes agregados «as long as the MX record for the Microsoft 365 domain points directly to Microsoft 365». Si tienes una pasarela de seguridad o un filtro delante, o un escenario híbrido con entrega on-premises, esos informes no se envían. Es decir, justo las instalaciones más complejas, las que más necesitan el censo, son las que se quedan sin él si no lo saben.

El orden importa, y hay prisa pero no tanta

La tentación, cuando alguien descubre esto, es publicar p=reject el mismo viernes. Microsoft propone lo contrario, y con una frase que vale la pena leer dos veces: «Blocking legitimate email in any significant volume is unacceptable to users, but it's almost inevitable that you're going to get some false positives». El plan que publica es: empezar en p=none con informes y mirar; subir a p=quarantine, usando pct= en escalones de 10, 25, 50, 75 y 100 para ir afectando a más correo; y solo entonces p=reject. Y empezando por el subdominio de menos volumen, dejando el dominio principal para el final.

Una advertencia más, porque tiene efecto sobre ti y no sobre quien te escribe: el correo saliente de tus dominios en Microsoft 365 que falle DMARC en el destino se enruta por el grupo de entrega de alto riesgo si tu política es p=reject o p=quarantine, y la documentación lo remata sin suavizarlo: «There's no override for this behavior». Endurecer la política sin haber arreglado antes a tus propios remitentes no solo rechaza correo: te mete tu propio tráfico por el carril lento.

Y un remate que cuesta cero y casi nadie hace: los dominios que tienes registrados y no usas para correo también necesitan su registro. La receta de Microsoft para un dominio aparcado es de una línea, v=DMARC1; p=reject;, sin pct= ni direcciones de informe, porque de ahí no debería salir correo legítimo nunca. Y añade el caso que se olvida siempre: eso incluye tu propio dominio *.onmicrosoft.com si no lo usas para enviar.

Los límites de lo que acabamos de decir

Todo lo citado entre comillas sale de la documentación de Microsoft para Microsoft 365 en su revisión del 3 de julio de 2026 y puede cambiar; DMARC como protocolo está descrito en el RFC 7489, y otros proveedores de correo pueden comportarse distinto ante la misma política. No hemos puesto cifras de cuánto mejora la entregabilidad al pasar a p=reject porque no tenemos una fuente que podamos defender, y los números que circulan por ahí vienen casi siempre de quien vende el panel de informes. Lo que sí sabemos es dónde está el fallo, y está en la alineación.

Y el conflicto de interés por delante: everyWAN cobra por hacer este inventario y por dejarlo escrito. La parte comprobable es la que va entre comillas y enlazada; publicar el registro con rua= y pasar un mes mirando los informes lo puede hacer cualquiera sin nosotros, y es justo lo que recomendamos que hagas antes de pedir presupuesto a nadie, nosotros incluidos.

Fuentes (verificadas el 4 de octubre de 2026): la definición de las direcciones 5321.MailFrom y 5322.From, la frase «SPF and DKIM don't require the domains […] to "align" (match)», la regla de aprobación y fallo de DMARC, la tabla de alineación relajada y estricta con sus cinco filas, los escenarios comunes de fallo con su resolución, la recomendación de usar un subdominio para servicios que no controlas, el contenido del informe agregado y la frase sobre la diferencia entre «authentication pass» y «alignment pass», el hecho de que Microsoft 365 no envía informes forenses y de que solo envía agregados si el registro MX apunta directamente a Microsoft 365, el plan gradual p=none → p=quarantine → p=reject con los escalones de pct=, la advertencia sobre el grupo de entrega de alto riesgo para el correo saliente y el registro recomendado para dominios aparcados — «Set up DMARC to validate email in Microsoft 365», Microsoft Learn, revisión del 3 de julio de 2026. La especificación del protocolo — RFC 7489. Fotografía de portada: «Konica Minolta Bizhub C454e photocopier», de Baron Maddock, Wikimedia Commons, licencia CC BY 4.0.