SPF declara quina infraestructura pot enviar utilitzant un domini d’envelope sender. Publicar un altre registre SPF TXT per a un segon proveïdor invalida el resultat en lloc de sumar permisos.
Inventaria totes les fonts legítimes i modifica una sola política.
Identifica el domini que avalua SPF
Inspecciona Return-Path en un missatge o log. SPF avalua aquest domini, que pot ser diferent del From visible.
Anota si WordPress utilitza el domini web, un subdomini o un domini de rebots del proveïdor. No editis l’SPF del domini visible si l’envelope sender és en un altre lloc.
L’alineació DMARC es comprova per separat.
Localitza el registre autoritatiu
Consulta DNS mitjançant diversos resolvers i confirma els nameservers actius. El panell de l’allotjament no té efecte quan Cloudflare o un altre servei és autoritatiu.
Recopila tots els TXT que comencen per v=spf1. Hi ha d’haver una única política per a aquell hostname. Desa el valor i el TTL actuals.
Comprova cometes accidentals, espais i fragments creats pel panell. Diverses cadenes dins d’una resposta TXT poden ser vàlides; diversos registres SPF independents no.
Inventaria els serveis legítims
Enumera correu corporatiu, WordPress, helpdesk, CRM, newsletters, factures i relay de l’allotjament que utilitzin el mateix domini. Confirma la propietat actual i la documentació de cada proveïdor.
No conservis includes obsolets “per si de cas”: amplien la confiança i consumeixen consultes DNS.
Separa màrqueting i transaccional en subdominis amb finalitat pròpia quan sigui adequat.
Fusiona mecanismes en una política
Afegeix l’include, IP o mecanisme documentat abans del qualificador all. Conserva la sintaxi i evita cometes intel·ligents o salts d’un editor.
Una estructura simplificada:
v=spf1 include:provider-one.example include:provider-two.example -allSón placeholders; publica només els valors reals dels proveïdors.
Controla el límit de consultes DNS
SPF limita els mecanismes que generen consultes. Includes imbricats, redirect, a i mx poden esgotar el màxim encara que el text sigui curt.
Analitza l’expansió completa. Elimina serveis sense ús abans de considerar flattening compatible, perquè una llista fixa d’IP pot quedar obsoleta.
El límit s’aplica durant l’avaluació, inclosos includes i redirects recursius, no al nombre visible de paraules. Revisa cada branca fins als mecanismes IP i detecta bucles o includes amb errors temporals. Un permerror no es resol canviant -all per ~all.
No afegeixis a o mx amplis si aquests hosts no envien.
Escull el qualificador final
-all, ~all i ?all expressen polítiques diferents. No debilitis el final per ocultar un error; incorpora correctament el remitent i conserva la intenció.
Coordina amb l’administrador si el domini també suporta correu d’empleats. Una reparació de WordPress no ha de trencar el correu corporatiu.
Espera el TTL anterior i consulta almenys dos resolvers públics. Publica en una finestra amb accés a la reversió. Si el panell divideix un TXT llarg, verifica que DNS el retorni com una sola política lògica.
Verifica les dues fonts i DMARC
Envia un missatge identificat per cada proveïdor després de propagar. Revisa SPF i el domini autenticat. Després comprova DKIM i l’alineació DMARC amb From.
SPF pass pot no satisfer DMARC si Return-Path no està alineat. Configura un domini de rebots propi o DKIM alineat quan estigui disponible.
Prova també una font no autoritzada per confirmar el comportament esperat, mitjançant una eina controlada i sense falsificar enviaments a tercers.
Prova el formulari real, no només el dashboard.
Mantén el registre
Documenta el propietari i la condició d’eliminació de cada mecanisme. Revisa la política en retirar un proveïdor, allotjament o plataforma.
Supervisa informes d’autenticació i rebots sense recopilar dades innecessàries. Conserva l’historial DNS i la reversió.
Demana ajuda si se supera el límit, es desconeix la propietat o diversos sistemes comparteixen domini. Comparteix el registre públic i capçaleres amb dades ocultes, mai credencials DNS o claus privades.
Un exemple reproduïble del segon remitent sense canviar DNS
El 24 d’octubre de 2026 vam executar un exercici propi de selecció de registres sense connexió. Utilitza respostes TXT fictícies i IP reservades per a documentació. Comprova selecció i unió de cadenes, no propagació DNS, lliurament de correu ni l’avaluació SPF completa.
Cas A: dos registres TXT separats
"v=spf1 ip4:198.51.100.24 -all"
"v=spf1 ip4:203.0.113.44 -all"
Selecció observada: permerror
Cas B: un registre TXT
"v=spf1 ip4:198.51.100.24 ip4:203.0.113.44 -all"
Selecció observada: selected
Cas C: un registre TXT amb dues cadenes
"v=spf1 ip4:198.51.100.24 " "ip4:203.0.113.44 -all"
Selecció observada: selectedLa diferència és quants registres hi ha, no quantes cadenes entre cometes mostra el panell. A C s’uneixen les cadenes del mateix registre; l’espai al final de la primera és intencionat. selected només indica que l’exercici ha trobat una política SPF. No equival a SPF pass ni confirma l’autorització d’un remitent real.
Per reproduir la distinció, inventaria cada resposta TXT per separat i concatena únicament les seves pròpies cadenes. Contrasta el resultat amb RFC 7208, apartats 3.2–3.3 i 4.5 —en anglès—. No publiquis aquestes adreces d’exemple. La reparació real encara necessita domini del remitent de sobre, instruccions del proveïdor, avaluació de consultes expandides i un missatge identificat de cada emissor.
Conserva una fitxa abans i després per emissor: domini de sobre, proveïdor, resultat d’autenticació, hora i destinació controlada. Si el domini també serveix al correu corporatiu, sol·licita una valoració de SPF i lliurament del formulari abans de modificar una política amb altres emissors desconeguts.