Guia pràctica d'autenticació del correu electrònic

El teu domini envia correu encara que no siguis tu qui escriu els missatges: butlletins, factures, avisos del CRM, restabliments de contrasenya. La seguretat del correu al DNS és el conjunt de paràmetres públics que diuen al món quins servidors poden enviar correu en nom teu i si un missatge ve de debò de la teva organització. Els grans proveïdors de correu ja tracten una autenticació feble o inexistent com un problema d’entrega, no com un extra opcional.

Què t’hi jugues si no en fas cas: les factures acaben a la carpeta d’spam dels teus clients, Gmail frena o bloqueja les teves campanyes de màrqueting i qualsevol pot falsificar un correu del teu director general al teu equip de finances sense tenir accés a res de la teva infraestructura. És la suplantació (spoofing). Configura bé l’autenticació una vegada i la majoria d’aquests problemes desapareixen.

Què t’emportes d’aquesta guia: definicions en llenguatge planer (domini arrel, selector DKIM, alineació DMARC), una llista del que has de reunir abans de tocar el DNS, un ordre de desplegament segur i maneres concretes de comprovar-ho, sense memoritzar números d’RFC. Coordinar l’accés al registrador i als proveïdors també és feina de governança: s’assembla a alinear equips quan la fiabilitat importa (DevOps i com trencar els silos, en anglès).

En resum

• SPF declara qui pot enviar correu en nom del teu domini.
• DKIM signa criptogràficament el teu correu sortint perquè els receptors puguin verificar que ningú no l’ha alterat.
• DMARC vincula SPF i DKIM a l’adreça «De» visible i diu als receptors què han de fer quan no coincideixen.
• Comença DMARC en mode de supervisió (p=none), corregeix els orígens que fallen als informes i després passa a quarantine i, finalment, a reject.
• Comprova-ho amb eines en línia gratuïtes o amb Comprova el correu, l’eina gratuïta d’aquest web: sense obrir el terminal.
• Avui: envia la plantilla de petició de més avall a qui controli el teu DNS i confirma que els informes agregats de DMARC comencen a arribar en una setmana.

Fes clic per ampliar

Per què «sense autenticació, mala entrega» s’ha tornat normal

Els proveïdors de correu filtren un volum enorme d’abusos. Per protegir els usuaris, cada cop esperen més que els remitents demostrin la seva identitat amb la seguretat del correu al DNS, en lloc de refiar-se només de la línia «De».

Google publica al seu Centre d’ajuda el que espera dels remitents massius per als administradors de Workspace, incloses l’autenticació i la responsabilitat sobre la taxa d’spam^{[1]Google Workspace Admin Help. «Email sender guidelines». Consultat el 2026.}. Yahoo ofereix pautes semblants al seu portal de bones pràctiques per a remitents^{[1]Yahoo Inc. Yahoo Sending Guidelines (best practices).}.

La lliçó pràctica per a qui no és tècnic és més senzilla que aquestes pàgines de polítiques: si els teus registres DNS no coincideixen amb com envies el correu de debò, les teves campanyes legítimes poden acabar a l’spam (o rebotar) mentre els suplantadors continuen aprofitant les escletxes.

Model mental: el DNS com el tauler d’anuncis de l’entrada del teu edifici

Pensa en el DNS com un tauler d’anuncis públic associat al teu nom de domini. Qualsevol persona a internet el pot llegir; només qui té accés al registrador el pot canviar. Els protocols d’autenticació del correu són avisos penjats en aquest tauler:

• SPF respon: «Quines adreces IP i quins proveïdors poden enviar correu en nom del nostre domini?»
• DKIM respon: «Aquí tens una clau pública: els missatges signats amb la nostra clau privada demostren que ningú no els ha alterat pel camí».
• DMARC respon: «Si SPF o DKIM no estan alineats amb el domini visible del remitent, això és el que han de fer els receptors; i envieu-nos informes».

Tres termes en llenguatge planer que sentiràs als panells de DNS:

• Domini arrel: el teu domini, sense res més (example.com), no un subdomini com mail.example.com. L’SPF del correu sortint sol ser aquí, en un registre TXT (sovint marcat com a @).
• Selector DKIM: una etiqueta que tria el teu proveïdor de correu per poder rotar les claus; al DNS es publica your-selector._domainkey.example.com.
• Alineació: els receptors comproven que el domini que ha superat SPF o DKIM coincideix (o està relacionat) amb el domini que el destinatari veu al camp «De»; si no, DMARC pot fallar encara que SPF i DKIM passin per separat^{[1]IETF. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).}.

Junts, aquests registres tanquen l’escletxa que permetria a un estafador falsificar CEO@yourcompany.com sense tenir accés a la teva infraestructura.

SPF (Sender Policy Framework)

SPF viu en un sol registre TXT al domini arrel (sovint @ als panells de DNS). Hi apareixen els remitents autoritzats (el teu servidor de correu, Microsoft 365, Google Workspace, Mailchimp, etc.), sovint amb punters include: cap a registres que gestiona cada proveïdor.

El que has de saber sense memoritzar la sintaxi:

• Exactament un registre TXT d’SPF al domini arrel. Si hi ha diverses cadenes SPF, els receptors retornen un error en l’avaluació SPF^{[1]IETF. RFC 7208: Sender Policy Framework (SPF). Seccions 4.5 i 4.6 (registres múltiples i avaluació).}.
• Acaba amb -all (rebuig estricte, hard fail) o ~all (rebuig suau, soft fail) quan confiïs en el teu inventari de remitents. Durant una migració, els proveïdors solen recomanar un tracte més suau fins que els informes demostrin que tot està cobert.

Què fer si no ets tècnic: exporta la cadena SPF del DNS i escriu a cada proveïdor que envia en nom del teu domini (màrqueting, facturació, suport) per confirmar que hi surt.

Quan cal trucar a un especialista (SPF PermError)

Si fas servir moltes eines SaaS, de vegades se supera el límit de consultes DNS que SPF permet durant l’avaluació^{[1]IETF. RFC 7208, secció 4.6.4 (límits durant l’avaluació SPF).}. Un símptoma típic són caigudes misterioses en l’entrega després d’afegir un altre proveïdor. Arreglar-ho sol voler dir concentrar el correu sortint en menys servidors d’enviament o aplanar els include, i no és cosa de fer a cegues en producció.

DKIM (DomainKeys Identified Mail)

DKIM afegeix una signatura digital a les capçaleres del correu sortint. Els receptors obtenen la teva clau pública del DNS a través d’un registre de selector com selector1._domainkey.example.com.

Per què als receptors els agrada DKIM:

• Aguanta el reenviament. SPF sovint es trenca quan el correu passa per llistes de distribució o reenviaments, perquè canvia el servidor que es connecta; la signatura pot sobreviure a aquests camins si arriba intacta.
• Delata les manipulacions. Si s’altera el cos o alguna capçalera signada, la signatura normalment deixa de ser vàlida.

Segueix les indicacions del teu proveïdor sobre la longitud i la rotació de les claus; Google Workspace recomana claus de 2048 bits quan es generen claus DKIM^{[1]Google Workspace Admin Help. «Authenticate mail with DKIM». Consultat el 2026.}. El protocol es defineix a l’RFC 6376^{[1]IETF. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.}.

Què fer si no ets tècnic: demana al teu informàtic o al teu proveïdor SaaS el nom del selector i el TXT que hi ha d’haver al DNS, i comprova que aquest TXT existeix. Si màrqueting fa servir una altra plataforma, potser publica un selector diferent: apunta’ls tots al teu full de càlcul.

Vigila els selectors oblidats. Si canvies de plataforma d’enviament (ESP) i no esborres el selector antic, DKIM continua «passant» a través d’una infraestructura que ja no controles. Rota les claus més o menys un cop l’any i elimina del DNS els selectors tan bon punt donis de baixa el servei que els feia servir.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Publica DMARC com a registre TXT a _dmarc.example.com. Conté la política (p=), les adreces per als informes agregats (rua=) i els requisits d’alineació que hem resumit abans^{[1]IETF. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).}.

Etiquetes de política que veuràs:

Els informes agregats RUA resumeixen en adjunts XML els intents d’enviament de tot el món^{[1]IETF. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).}. Envia’ls a una bústia que algú vigili o a un proveïdor: durant el desplegament, algú els ha de revisar cada setmana.

Tracta els panells de DMARC com a indicadors clau de l’operació: destapen els enviaments d’eines que ningú no controla (shadow IT) molt abans que màrqueting es recordi d’aquella integració SaaS abandonada.

Abans de tocar el DNS: reuneix això en un sol lloc

Ara que tens clars els tres protocols, fes inventari abans de tocar el DNS. Fes servir una fila del full de càlcul per proveïdor o origen de correu:

• Qui gestiona el DNS del domini (el registrador, Cloudflare o el teu proveïdor de serveis gestionats).
• On són les bústies (Google Workspace, Microsoft 365, Fastmail, etc.).
• Cada sistema que envia en nom del teu domini (CRM, facturació, plataforma d’email màrqueting, alertes).
• Els selectors DKIM que cada proveïdor espera que publiquis (consulta’n la documentació de suport o pregunta-ho al teu informàtic).
• On han d’arribar els informes agregats de DMARC (rua): una bústia a la qual només tinguin accés els qui els analitzen.
• Una captura de pantalla o una exportació del TXT d’SPF actual del domini arrel abans d’editar-lo.

Missatge inicial per al teu informàtic o el teu proveïdor de DNS

L’objectiu d’aquest missatge és obrir una conversa, no donar al teu informàtic una llista de tasques. El teu equip tècnic o el teu proveïdor ja coneixen els detalls tècnics; el que necessiten de tu és context (per què ara), permís (vols que sigui una prioritat) i una invitació perquè decideixin ells l’ordre tècnic. Fes-lo servir com a missatge inicial i deixa que ho portin ells a partir d’aquí:

Assumpte: Revisió de l'autenticació del correu d'example.com: què en penses?

Hola, [nom]:

M'agradaria revisar com està configurada l'autenticació del correu
del nostre domini. El motiu: [tria el que encaixi: els butlletins
acaben a l'spam, afegirem una plataforma d'enviament nova, ens han
parlat dels requisits de Google/Yahoo per a remitents massius,
o simplement volem partir d'una base neta abans de la propera
campanya important].

Em podries passar el següent?

1. L'estat actual dels nostres registres SPF, DKIM i DMARC (ja em va bé
   una captura o una còpia del que hi ha publicat).
2. Quines eines envien avui correu en nom del nostre domini:
   Workspace/M365, les nostres plataformes d'enviament de màrqueting i
   transaccional, el CRM, la facturació o qualsevol altra.
3. La teva opinió sobre si hi ha alguna cosa que no està bé i quins
   passos recomanaries a continuació.

El meu objectiu és que el correu legítim s'autentiqui sense problemes i
avançar cap a una política DMARC més estricta tan bon punt sapiguem qui
envia en nom nostre. Em refio del teu criteri pel que fa a l'ordre i
els terminis.

Gràcies!

Resisteix la temptació d’afegir a aquest missatge v=DMARC1, p=none|quarantine|reject o valors concrets de registres, encara que acabis de llegir-ne. Si els hi poses, semblarà que els has copiat d’un article o que qüestiones el que sap el teu informàtic. Mantén la petició en el terreny de la intenció i la visibilitat; deixa que els qui tenen accés d’administrador proposin les respostes tècniques.

Ordre de desplegament segur (no et saltis cap pas)

• Observa: publica DMARC amb p=none i recull els informes rua.
• Fes inventari: apunta cada remitent autoritzat, el seu selector DKIM i els include d’SPF.
• Corregeix els errors: ajusta SPF i DKIM fins que el correu legítim els superi de manera estable.
• Puja la política: passa a quarantine, si vols amb pct= per aplicar-la de manera esglaonada quan el receptor ho admeti. pct=20 aplica la teva política al 20 % del correu que falla: és útil per endurir-la de manera controlada abans d’arribar al 100 %.
• Rebutja: només quan les eines mostrin taxes d’aprovats altes i sostingudes, i els responsables acceptin els riscos.

Fes els canvis al DNS de mica en mica: abaixa els TTL durant les migracions si el teu proveïdor de DNS ho permet i torna’ls a apujar després.

Seguretat del transport: MTA-STS i TLS-RPT (quan el xifratge no es pot desactivar sense avisar)

L’autenticació demostra la identitat del remitent; la seguretat del transport protegeix els missatges entre servidors. El TLS oportunista pot acabar enviant sense xifrar si algú bloqueja l’intent de xifratge.

MTA-STS et permet anunciar «només salts xifrats cap a servidors MX amb identitat verificada». Publiques un TXT de referència a _mta-sts.example.com i allotges un petit fitxer de política per HTTPS a mta-sts.example.com^{[1]IETF. RFC 8461: SMTP MTA Strict Transport Security (MTA-STS).}.

TLS-RPT afegeix informes agregats quan falla la negociació TLS^{[1]IETF. RFC 8460: SMTP TLS Reporting.}.

Què fer si no ets tècnic: confirma amb el teu equip tècnic si MTA-STS té sentit abans d’activar el mode enforce, perquè una llista de MX mal configurada pot tallar el correu durant les proves.

Una millora ràpida i gratuïta: CAA

Un registre CAA limita quines autoritats de certificació poden emetre certificats TLS per al teu domini. Publicar-lo és un canvi de cinc minuts sense risc operatiu si hi poses les autoritats que fas servir de debò, i redueix força la probabilitat que algú emeti per error o de manera fraudulenta un certificat a nom teu^{[1]IETF. RFC 8659: DNS Certification Authority Authorization (CAA).}.

Demana al teu informàtic que publiqui un registre CAA amb les autoritats de certificació que fas servir avui (p. ex., letsencrypt.org, digicert.com). En la majoria de dominis n’hi ha prou de confirmar amb quina autoritat es fan les renovacions.

Temes avançats (DNSSEC, DANE, BIMI)

El primer pas, per a la majoria d’organitzacions, és deixar ben resolts SPF, DKIM i DMARC. Considera tot el que segueix avançat i consulta especialistes en DNS o seguretat abans d’activar res.

Si aquestes files et sonen a xinès, no passa res: desa-les per al teu interlocutor tècnic.

Comprova-ho sense obrir el terminal

Tres opcions gratuïtes i fiables per revisar els teus registres DNS i els resultats d’autenticació:

• Comprova el correu, l’eina gratuïta d’aquest web: fa les mateixes comprovacions d’SPF, DKIM, DMARC, MX, MTA-STS i TLS-RPT que la línia d’ordres, al teu navegador. Sense instal·lar res i sense registre.
• MXToolbox: una eina veterana de consulta de TXT i MX, amb un informe centrat en l’entrega.
• Google Postmaster Tools: si envies un volum significatiu a Gmail, és la referència fiable de com veu Google el teu domini.

Després de publicar els registres, envia un missatge de prova des de cada plataforma d’enviament a un compte personal de Gmail o d’Outlook i llegeix els resultats d’autenticació (el nom exacte dels menús pot variar segons l’idioma i la versió):

• Gmail: obre el missatge, fes clic al menú dels tres punts → Mostra l’original i busca spf=pass, dkim=pass i dmarc=pass al bloc Authentication-Results.
• Outlook (web o escriptori): obre el missatge → … → Visualitza → Visualitza l’origen del missatge (o Fitxer → Propietats → Capçaleres d’Internet) i busca les mateixes línies Authentication-Results.

Les eines comercials de DMARC (dmarcian, Postmark DMARC Digests, Valimail, etc.) converteixen els informes XML en panells i van més enllà, però a petita escala són opcionals.

Facis servir l’eina que facis servir, recorda que només llegeix registres MX i TXT públics: per si sola no demostra que el correu arribi a la safata d’entrada ni que estigui alineat. Els Authentication-Results d’un missatge de prova real són la prova definitiva.

Problemes que convé esmentar quan parlis amb els proveïdors

• Diverses cadenes TXT d’SPF al domini arrel: cal fusionar-les en un sol registre^{[1]IETF. RFC 7208: Sender Policy Framework (SPF). Seccions 4.5 i 4.6 (registres múltiples i avaluació).}.
• Màrqueting en un subdomini sense alineació: de vegades es resol amb DMARC o DKIM específics per al subdomini, en lloc de forçar a cegues l’alineació amb el domini principal.
• Un remitent SaaS oblidat després de cancel·lar un contracte: treu-ne els include de l’SPF quan un proveïdor marxi.

Conclusió

La seguretat del correu al DNS és governança del domini, no una casella que es marca una vegada. SPF enumera les vies d’enviament autoritzades, DKIM en demostra la integritat, DMARC vincula la identitat amb la política, i els proveïdors de correu exigeixen cada cop més una autenticació coordinada, tant per al correu massiu com per al transaccional^{[1]Google Workspace Admin Help. «Email sender guidelines». Consultat el 2026.}.

Aquesta setmana, fes aquestes tres coses:

• Envia la plantilla de petició de més amunt a qui controli el teu DNS i demana els valors actuals abans de canviar res.
• Publica (o confirma) DMARC a _dmarc.example.com amb p=none i una bústia rua= que funcioni.
• Llegeix el teu primer informe agregat i identifica els un o dos remitents amb més errors d’alineació.

Endureix la política només quan els informes siguin estables. Per revisar ara mateix els teus registres, fes servir Comprova el correu, de franc; si vols ajuda per interpretar errors estranys, escriu-me des de la pàgina de contacte.