SPF, DKIM i DMARC explicats: per què importa l'alineació

SPF diu quins servidors poden enviar en nom del teu domini. DKIM signa criptogràficament el missatge perquè la destinació comprovi que ningú no l'ha tocat. DMARC no comprova cap de les dues coses: comprova que almenys una passi i que a més estigui alineada amb el domini que l'usuari veu al remitent. Aquesta última paraula, alineada, és la que explica per què un domini pot tenir SPF i DKIM en verd en qualsevol comprovador i fallar DMARC al cent per cent dels seus enviaments.

Tots tres són registres TXT al DNS del teu domini. Són públics: qualsevol els pot llegir, tu inclòs, amb una ordre en un terminal. Aquesta guia explica què fa cadascun, on es trenquen a la pràctica i com es comprova l'alineació mirant un correu real.

SPF: qui pot enviar per tu

Un registre SPF és una llista de servidors autoritzats. La destinació mira de quina IP li arriba el missatge i comprova si és a la llista. Un SPF sa s'assembla a això:

; correu corporatiu (Google Workspace)
empresa.es.            TXT "v=spf1 include:_spf.google.com -all"

; transaccional (Amazon SES)
mail.empresa.es.       TXT "v=spf1 include:amazonses.com -all"

; campanyes (SMTP2GO)
news.empresa.es.       TXT "v=spf1 include:spf.smtp2go.com -all"

SPF té dos límits que enfonsen més dominis que cap altra cosa. El primer és el de deu consultes DNS: el RFC 7208 obliga a limitar a deu els termes que resolen noms durant l'avaluació. Compten include, a, mx, ptr, exists i el modificador redirect. No compten ip4, ip6, all ni exp. Cada eina de màrqueting que hi afegeixes sol portar el seu include, i el dia que es passa de deu el resultat és permerror, que la majoria de receptors tracten com a fallada de SPF. És la causa número u de "de sobte va deixar d'arribar".

El segon és el de les consultes buides. El mateix RFC diu que les implementacions haurien de limitar a dues les void lookups, és a dir, les consultes que no tornen res o donen NXDOMAIN. Dos include apuntant a serveis que ja no existeixen n'hi ha prou per tombar el SPF sencer. Per això una auditoria comença podant: en un domini amb cinc anys de vida és normal trobar-hi tres o quatre include fòssils. A més, el registre hauria de cabre en 512 octets, amb cada cadena TXT per sota dels 255 bytes.

Sobre el final del registre: ~all (softfail) és el correcte mentre desplegues i mentre hi hagi reenviaments sense ARC. L'objectiu és -all (hardfail), però només aporta seguretat real si DMARC és en enforcement, perquè amb DMARC en reject és DMARC qui decideix. Recomanació de producte: -all als subdominis d'enviament controlat, ~all al domini corporatiu on la gent reenvia correu al seu Gmail.

DKIM: la signatura que viatja amb el missatge

DKIM signa unes capçaleres concretes i el cos amb una clau privada que només té el teu servidor de sortida. La clau pública es publica al DNS sota un selector, i la destinació la busca allà per verificar-la. A diferència de SPF, la signatura sobreviu als reenviaments mentre ningú no modifiqui el missatge.

sel2026a._domainkey.empresa.es. IN TXT ( "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                          "...IDAQAB" )

Longitud de clau

El RFC 8301 obliga a un mínim de 1024 bits i en recomana 2048. Google exigeix el mínim i recomana el mateix; Yahoo també fixa 1024 com a mínim. La decisió assenyada avui és 2048 sempre.

Algorisme

El RFC 8301 és taxatiu: cal signar amb rsa-sha256, i rsa-sha1 no s'ha de fer servir ni per signar ni per verificar. Un selector amb sha1 actiu és una troballa, no pas un detall.

Nom del selector

M3AAWG recomana que el selector digui a quin flux pertany, quan entra en servei i de quants bits és, i desaconsella amb força reutilitzar noms. Una convenció que funciona: camp-202608-2048, txn-202608-2048.

Quines capçaleres signar (el tag h=)

Com a mínim From, To, Subject, Date, Message-ID, MIME-Version, Content-Type i Reply-To. I obligatòriament List-Unsubscribe i List-Unsubscribe-Post si envies comercial: ho exigeix el RFC 8058, i si no estan cobertes per la signatura, Gmail no mostra el botó natiu de baixa.

Canonicalització

relaxed/relaxed. L'opció simple/simple es trenca tan bon punt alguna cosa pel camí reescriu una capçalera, que és el normal.

La rotació de claus té una referència clara: el document de bones pràctiques de M3AAWG, que en la seva actualització del 2019 va passar la recomanació de trimestral a semestral i proposa l'abril i l'octubre com a mesos raonables. El procediment importa tant com el calendari: es tenen sempre dos parells publicats, un signant i un altre esperant; per rotar es publica el següent, s'espera la propagació i només llavors es canvia el servidor de signatura. La clau anterior es manté al DNS entre set i trenta dies i després es retira deixant el camp p buit, sense esborrar l'entrada del selector.

DMARC: el que de debò comprova

Aquí hi ha el malentès que sosté mig sector. DMARC no comprova SPF i DKIM. DMARC comprova que almenys un dels dos passi i estigui alineat amb el domini de la capçalera From, que és l'única que veu el destinatari. Si tots dos passen però cap no alinea, DMARC falla.

Alineació SPF

Es compara el domini del Return-Path (el remitent del sobre, MAIL FROM) amb el domini del From. Són dues coses diferents i gairebé ningú no mira la primera.

Alineació DKIM

Es compara el domini del tag d= de la signatura amb el domini del From. Una signatura perfectament vàlida amb d= del proveïdor no alinea amb el teu domini.

Relaxada o estricta

Per defecte l'alineació és relaxada (aspf=r, adkim=r) i n'hi ha prou de compartir domini organitzatiu: news.empresa.es alinea amb empresa.es. En mode estricte (s) la coincidència ha de ser exacta.

Yahoo ho diu amb les mateixes paraules i Microsoft exigeix DMARC vàlid més alineació per SPF o per DKIM per no rebutjar amb 550 5.7.515. Tots tres demanen el mateix, i per això l'alineació no és un detall de purista: és el requisit.

La fallada clàssica: verd, verd, i DMARC a zero

El patró es repeteix en gairebé totes les auditories d'una pime espanyola. L'empresa contracta una eina de campanyes. L'eina posa el seu propi Return-Path (una cosa com bounces.proveedor.com) per gestionar els rebots, així que SPF passa, però passa per al domini del proveïdor: no alinea. I si a més la signatura DKIM la posa el proveïdor amb d=proveedor.com en comptes del domini del client, tampoc no alinea per aquí. Resultat: SPF verd, DKIM verd, DMARC fallant al cent per cent dels missatges.

Com es llegeix un informe DMARC de debò

Quan publiques un rua, els receptors t'envien cada dia un XML comprimit que resumeix, per IP d'origen, quants missatges van veure i què en van fer. No contenen contingut ni destinataris. Aquest és el fragment que cal saber llegir:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>1420</count>
    <policy_evaluated>
      <disposition>none</disposition>   <!-- què s'ha fet amb el missatge -->
      <dkim>fail</dkim>                 <!-- ALINEACIÓ, no validesa -->
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>empresa.es</header_from></identifiers>
  <auth_results>
    <dkim><domain>proveedor.com</domain><result>pass</result></dkim>  <!-- signatura vàlida... -->
    <spf><domain>empresa.es</domain><result>pass</result></spf>
  </auth_results>
</record>

Amb els informes a la mà, cada IP que envia en nom teu es classifica en un de quatre calaixos: legítima i alineada (res a fer), legítima i no alineada (cal arreglar-la), reenviaments (volum baix, moltes IP diferents, SPF fail amb DKIM pass: és normal i ho mitiga ARC) i suplantació (sense autenticació de cap mena, que és la raó per la qual s'acaba pujant a reject). La regla d'or: no es puja de graó mentre el segon calaix tingui volum material.

Comprova-ho tu mateix en tres minuts

dig +short TXT empresa.es | grep spf1
dig +short TXT _dmarc.empresa.es
dig +short TXT sel2026a._domainkey.empresa.es
dig +short MX empresa.es

L'alineació no es veu al DNS, es veu en un missatge. Obre a Gmail un correu enviat per tu, fes servir "Mostra l'original" i busca la capçalera Authentication-Results. Allà hi ha el veredicte dels tres, i el que mana és l'últim:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@proveedor.com header.s=sel1;
       spf=pass (google.com: domain of bounces.proveedor.com designates 203.0.113.10) smtp.mailfrom=bounces.proveedor.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=empresa.es

L'ordre correcte de treball

1. Inventari d'emissors: qui envia avui en nom del domini. Sol haver-n'hi tres o quatre més dels que l'empresa recorda.
2. Un SPF per flux, curt, sense fòssils i per sota de les deu consultes. Si no hi cap, se segmenta per subdomini, no s'aplana a mà.
3. DKIM de 2048 bits signant amb el domini del client a cada proveïdor, amb l'h= cobrint les capçaleres de baixa.
4. DMARC en p=none amb rua cap a una bústia que algú llegeixi de debò. Publicar un rua que ningú no processa és no tenir DMARC.
5. Llegir informes durant setmanes, tancar el calaix dels legítims no alineats i només llavors començar a pujar la política.

Aquest últim pas és una guia sencera, perquè des del maig del 2026 es fa d'una altra manera: la revisió de DMARC va eliminar el tag pct i amb ell el runbook clàssic de pujar per percentatges. Com s'arriba avui a p=reject sense perdre correu legítim és a la guia de DMARC sense trencar res.