El teu SPF passa, el teu DKIM passa, i DMARC falla igual

La factura de l'ERP deixa d'arribar a un client. Mires la capçalera i llegeixes spf=pass, llegeixes dkim=pass, i dos camps més enllà, dmarc=fail. Ningú no s'ha equivocat escrivint el DNS. Falla una altra cosa.

Aquesta combinació és, de llarg, la que més vegades ens hem trobat en entrar en un domini aliè, i gairebé sempre arriba embolicada en la mateixa frase: «però si el correu està ben configurat, ho vam comprovar». I és veritat que està ben configurat. L'SPF autoritza el servidor que envia. El DKIM signa el missatge i la signatura valida. Les dues comprovacions passen per separat i el missatge es rebutja igualment, perquè DMARC no pregunta si passen: pregunta si coincideixen amb el remitent que veu el destinatari.

Hi ha dos remitents, i tu només en veus un

Tot correu d'internet porta dues adreces de remitent, i la documentació de Microsoft les separa amb nom i cognoms. La primera és l'adreça MAIL FROM, «the email address used in the transmission of the message between SMTP email servers», també anomenada 5321.MailFrom o remitent de sobre. La segona és l'adreça From, la de la capçalera, «shown as the message sender in email clients», també 5322.From. La primera la fan servir els servidors. La segona és la que el teu client llegeix al seu Outlook.

L'SPF i el DKIM, tots sols, no exigeixen que aquestes dues adreces tinguin res a veure. Ho diu la mateixa pàgina: «SPF and DKIM don't require the domains in the following email addresses to "align" (match)». Aquí hi ha el forat per on entra la suplantació: un atacant pot muntar un domini, publicar un SPF impecable per a ell, signar amb DKIM impecablement, i posar al camp From el nom de la teva empresa. Les dues comprovacions passen. El remitent que es llegeix és el teu. De com s'explota aquesta confiança per telèfon ja en vam escriure parlant de qui verifica a la teva taula d'ajuda que ets qui dius; això és la versió per escrit.

DMARC tanca aquest forat afegint una pregunta més: el domini que acaba de passar SPF o DKIM és el mateix que el del From? Això s'anomena alineació, i la regla sencera cap en una línia de la documentació: «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» — on «passar» ja inclou estar alineat. Amb una de les dues alineada n'hi ha prou. Si no s'alinea cap, tant li fa que totes dues validessin.

Com es veu això en una capçalera

La mateixa documentació porta l'exemple, i és calcat al de la factura del principi. Aquesta és la capçalera d'un missatge on les dues comprovacions validen i tot i així es rebutja:

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

Els tres camps que cal mirar, en aquest ordre: header.from= és el domini que llegeix el destinatari; smtp.mailfrom= és el del sobre; header.d= és el que va signar. Aquí el primer diu contoso.com i els altres dos diuen adatum.com. Cap no alinea, i per això el resultat és dmarc=fail amb action=oreject — la «o» és d'origen, i vol dir que el rebuig el va demanar la política del domini remitent. Si hi veus action=pct.reject, el remitent va publicar p=reject amb un pct= menor de 100 i al teu missatge li va tocar ser a la mostra.

La taula que convé tenir impresa

Microsoft publica una taula d'alineació amb cinc files. Les etiquetes aspf i adkim del registre decideixen quant s'exigeix: relaxed (r, el valor per defecte) accepta subdominis del mateix domini organitzatiu; strict (s) exigeix coincidència exacta. Aquesta és la taula, amb el domini de la capçalera From a l'esquerra i el domini del MAIL FROM o de la signatura DKIM a la dreta:

La quarta fila és la que sorprèn més gent, perquè sembla de casa i no ho és, i no la salva ni el mode relaxat: un correu amb From @contoso.com signat amb el domini contoso.onmicrosoft.com no alinea. Són dos dominis organitzatius diferents, per molt que l'un sigui el tenant de l'altre. És el cas típic de qui va donar d'alta el domini propi i mai no va arribar a configurar la signatura DKIM amb ell, i és un altre recordatori que el domini onmicrosoft.com no és un lloc per quedar-s'hi a viure.

On es trenca de debò: a les teves aplicacions

El correu que escriuen les persones des de l'Outlook gairebé mai no és el problema: surt del tenant, amb el domini propi a les dues adreces, i alinea sol. El problema viu en tota la resta que envia correu posant el teu domini al From sense que ningú ho tingui apuntat enlloc. La llista real d'una pime, la que surt quan t'asseus a fer-la, acostuma a ser aquesta:

Per a cadascun, la documentació de Microsoft dona exactament dues sortides, i convé llegir-les abans de començar a tocar registres. Una: canviar el MAIL FROM del servei a un domini teu —la resolució literal que proposa per a l'escenari d'un servei extern que envia en nom teu és «Configure DKIM signing with your domain at the service, or change MAIL FROM to your domain/subdomain». Dues: que el servei signi amb DKIM fent servir el teu domini, és a dir amb d=elteudomini.com. Si el proveïdor no permet cap de les dues, queda la tercera via que la mateixa guia recomana i que gairebé ningú no aplica: fer servir un subdomini per a aquell servei —«for email services that aren't under your direct control (for example, bulk email services), use a subdomain»— i publicar-li el seu propi registre DMARC, perquè un problema de reputació seu no s'emporti per davant el correu de la teva gent.

L'informe que et diu qui envia en nom teu

Aquesta llista no s'ha d'endevinar: la publica el mateix protocol. Un registre amb rua=mailto: demana als destinataris un informe agregat en XML, normalment diari, amb, literalment, «the IP addresses of servers or services that send mail using your domain» i si passen o fallen. És el cens de remitents que ningú no té escrit.

Llegir-lo té truc, i és el mateix truc de tot el post. A l'XML hi ha dos blocs que semblen el mateix i no ho són: <auth_results> diu si l'SPF i el DKIM van validar en cru, i <policy_evaluated> diu si van alinear. La guia de Microsoft ho assenyala com la lectura més important de l'informe: «The most important insight from aggregate reports is identifying the gap between authentication pass and alignment pass». Un bloc amb <spf><result>pass</result></spf> al primer i <spf>fail</spf> al segon és exactament l'ERP del principi, amb la seva IP al costat perquè sàpigues de quin parlem.

Dues trampes operatives de les quals gairebé ningú no avisa, i que estan escrites a la mateixa pàgina. La primera: Microsoft 365 no envia informes forenses (ruf=) encara que hi posis una adreça vàlida, així que si esperes aquests correus per depurar, no arribaran d'allà. La segona, més grossa: Microsoft 365 només envia informes agregats «as long as the MX record for the Microsoft 365 domain points directly to Microsoft 365». Si tens una passarel·la de seguretat o un filtre al davant, o un escenari híbrid amb lliurament on-premises, aquests informes no s'envien. És a dir, justament les instal·lacions més complexes, les que més necessiten el cens, són les que es queden sense si no ho saben.

L'ordre importa, i hi ha pressa però no tanta

La temptació, quan algú descobreix això, és publicar p=reject el mateix divendres. Microsoft proposa el contrari, i amb una frase que val la pena llegir dues vegades: «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 pla que publica és: començar a p=none amb informes i mirar; pujar a p=quarantine, fent servir pct= en escalons de 10, 25, 50, 75 i 100 per anar afectant més correu; i només llavors p=reject. I començant pel subdomini de menys volum, deixant el domini principal per al final.

Un advertiment més, perquè té efecte sobre tu i no sobre qui t'escriu: el correu sortint dels teus dominis a Microsoft 365 que falli DMARC al destí s'encamina pel grup de lliurament d'alt risc si la teva política és p=reject o p=quarantine, i la documentació ho remata sense suavitzar-ho: «There's no override for this behavior». Endurir la política sense haver arreglat abans els teus propis remitents no només rebutja correu: et fica el teu propi trànsit pel carril lent.

I un remat que costa zero i gairebé ningú no fa: els dominis que tens registrats i no fas servir per a correu també necessiten el seu registre. La recepta de Microsoft per a un domini aparcat és d'una línia, v=DMARC1; p=reject;, sense pct= ni adreces d'informe, perquè d'allà no n'hauria de sortir correu legítim mai. I hi afegeix el cas que sempre s'oblida: això inclou el teu propi domini *.onmicrosoft.com si no el fas servir per enviar.

Els límits del que acabem de dir

Tot el que hem citat entre cometes surt de la documentació de Microsoft per a Microsoft 365 en la seva revisió del 3 de juliol del 2026 i pot canviar; DMARC com a protocol està descrit a l'RFC 7489, i altres proveïdors de correu poden comportar-se diferent davant la mateixa política. No hi hem posat xifres de quant millora la lliurabilitat en passar a p=reject perquè no tenim una font que puguem defensar, i els números que corren per aquí venen gairebé sempre de qui ven el panell d'informes. Això no va d'això: va d'alineació.

I el conflicte d'interès al davant: everyWAN cobra per fer aquest inventari i per deixar-lo escrit. La part comprovable és la que va entre cometes i enllaçada; publicar el registre amb rua= i passar un mes mirant els informes ho pot fer qualsevol sense nosaltres, i és justament el que recomanem que facis abans de demanar pressupost a ningú, nosaltres inclosos.

Fonts (verificades el 4 d'octubre del 2026): la definició de les adreces 5321.MailFrom i 5322.From, la frase «SPF and DKIM don't require the domains […] to "align" (match)», la regla d'aprovació i fallada de DMARC, la taula d'alineació relaxada i estricta amb les seves cinc files, els escenaris comuns de fallada amb la seva resolució, la recomanació de fer servir un subdomini per a serveis que no controles, el contingut de l'informe agregat i la frase sobre la diferència entre «authentication pass» i «alignment pass», el fet que Microsoft 365 no envia informes forenses i que només envia agregats si el registre MX apunta directament a Microsoft 365, el pla gradual p=none → p=quarantine → p=reject amb els escalons de pct=, l'advertiment sobre el grup de lliurament d'alt risc per al correu sortint i el registre recomanat per a dominis aparcats — «Set up DMARC to validate email in Microsoft 365», Microsoft Learn, revisió del 3 de juliol del 2026. L'especificació del protocol — RFC 7489. Fotografia de portada: «Konica Minolta Bizhub C454e photocopier», de Baron Maddock, Wikimedia Commons, llicència CC BY 4.0.