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.