Comprovador de registres SPF

El paper de l'SPF en l'autenticació del correu electrònic

El protocol SPF (Sender Policy Framework) és un pilar fonamental en la seguretat del correu electrònic. Permet als propietaris d'un domini especificar quins servidors de correu estan autoritzats a enviar missatges en el seu nom. Quan un servidor receptor rep un correu, consulta el registre SPF publicat al DNS del domini del remitent per verificar si la IP de l'emissor està autoritzada. Aquesta validació ajuda a prevenir la suplantació d'identitat (spoofing) i millora la reputació del domini.

L'SPF utilitza un registre de tipus TXT que comença obligatòriament amb la declaració de versió v=spf1. A partir d'aquí, es defineixen diversos mecanismes, modificadors i qualificadors que determinen el comportament de la política de seguretat. Per als administradors de dominis i el personal de configuració de correu, analitzar correctament la sintaxi d'aquest registre és crucial per evitar problemes de lliurament.

Funcionament del Comprovador de registres SPF

El Comprovador de registres SPF és una eina dissenyada per analitzar un registre TXT SPF mitjançant el desglossament dels seus termes, l'estimació de les consultes DNS que activarà i la identificació de possibles errors de sintaxi o riscos de política.

L'eina processa el text introduït per l'usuari i genera un resum detallat dels components sense realitzar consultes externes. El processament de les dades es realitza localment: el teu registre SPF es queda al navegador. BroBroGo no el puja ni el desa, garantint que la informació no es transmeti a servidors externs. A més, la pàgina no consulta el DNS, no amplia els registres del proveïdor, no prova una IP remitent ni confirma què retornarà un servidor de correu receptor.

Paràmetres d'entrada i límits

• Valor TXT de l'SPF: Una cadena de text que representa el registre SPF, el qual ha de començar estrictament amb v=spf1. S'accepten i s'uneixen els fragments TXT de DNS entre cometes.
• Longitud màxima: El text introduït ha de mantenir-se per sota dels 20.000 caràcters. Si se supera aquest límit, es mostrarà l'error: Aquest registre és inusualment gran. Mantén-lo per sota de 20.000 caràcters..
• Camps buits: Si s'intenta realitzar una comprovació sense text, el sistema mostrarà el missatge: Enganxa primer un registre SPF..

Estructura de l'anàlisi i resultats

Un cop processat el registre, l'eina genera una secció anomenada Anàlisi SPF que desglossa la informació en els següents blocs:

1. Resum de l'SPF: Mostra de manera compacta l'estat general del registre.
2. Termes DNS directes: Un recompte numèric estimat de les consultes DNS que realitzarà el primer registre.
3. Mecanismes: El nombre total de mecanismes detectats.
4. Riscos: El recompte de riscos de política o sintaxi no informatius trobats.

Taula de termes analitzats

Cada terme identificat es desglossa en una taula amb quatre columnes específiques:

El límit de 10 consultes DNS i els seus riscos

Un dels aspectes més crítics de l'especificació SPF és el límit de consultes DNS. Durant l'avaluació completa d'un registre per part d'un servidor de correu receptor, el nombre màxim permès de consultes DNS que es poden activar és de 10. Els termes que sumen per a aquest límit són include, a, mx, ptr, exists i redirect.

Si un registre supera aquest límit, es produeixen les següents conseqüències:

• L'eina activarà la nota de política: Aquest registre ja conté ‹detail› termes que activen el DNS, per sobre del límit SPF de 10..
• Els receptors SPF han de tractar com un error permanent (PermError) qualsevol avaluació que superi el límit de 10 termes amb consulta DNS. Això pot provocar que els correus legítims siguin rebutjats o marcats com a correu brossa.
• Cal tenir en compte que les destinacions d'include o redirect poden afegir més consultes DNS que aquesta estimació del primer registre, ja que aquestes referències externes poden contenir, al seu torn, altres mecanismes que requereixin consultes addicionals.

Regles de sintaxi i validació de termes

El comprovador valida el text segons les especificacions estàndard de l'SPF i genera alertes específiques per a cada desviació detectada:

• Requisits de la versió: El registre ha de començar amb v=spf1. Si no és així, es mostra El registre ha de començar amb v=spf1.. Si el terme de versió no està al principi, s'indica Terme ‹term›: v=spf1 ha de ser el primer terme.. Si es detecta duplicitat, es genera la nota El registre conté més d'un terme v=spf1..
• Mecanismes desconeguts: Qualsevol element no reconegut es marcarà amb Terme ‹term›: “‹detail›” no és un mecanisme SPF reconegut..
• Valors absents o malformats: Si un mecanisme requereix un paràmetre i aquest no és vàlid, es mostra Terme ‹term›: falta el valor de ‹detail› o no té un format vàlid..
• Adreces IP: Les adreces IPv4 o IPv6 i els seus respectius intervals CIDR es validen estrictament. Els errors es notifiquen com Terme ‹term›: introdueix una adreça IPv4 o un interval CIDR vàlid. o Terme ‹term›: introdueix una adreça IPv6 o un interval CIDR vàlid..
• Modificadors: Els modificadors duplicats generen l'alerta Terme ‹term›: el modificador ‹detail› apareix més d'una vegada.. A més, un modificador no pot tenir un qualificador +, -, ~ o ?; si en té, es mostra Terme ‹term›: un modificador no pot tenir un qualificador +, -, ~ o?..

Riscos de política i bones pràctiques

Més enllà de la sintaxi estricta, la configuració de les polítiques de l'SPF determina l'eficàcia real de la protecció del correu. L'eina identifica diversos patrons que, tot i ser sintàcticament correctes, suposen un risc de seguretat o de rendiment:

• Ús de +all: Aquest qualificador autoritza qualsevol remitent de l'espai d'adreces d'Internet, fet que normalment anul·la la finalitat de l'SPF. Es notifica amb la nota: +all autoritza qualsevol remitent i normalment anul·la la finalitat de l'SPF..
• Ús de ?all: Defineix una política neutra. Es mostra la nota: ?all retorna un resultat neutre i ofereix poca orientació de política als receptors..
• Absència de política terminal: Si el registre no té ni all ni redirect, els remitents sense coincidència reben un resultat neutre per defecte. Es genera l'avís: El registre no té ni all ni redirect, de manera que els remitents sense coincidència reben un resultat neutre..
• Mecanismes redundants o inaccessibles: Definir més d'un mecanisme all dificulta la revisió de la política. A més, els termes posteriors a all no són accessibles durant l'avaluació SPF. Si es defineix un redirect en un registre que també conté all, el redirect s'ignora completament.
• El mecanisme ptr: La publicació del mecanisme ptr està desaconsellada en les especificacions modernes. L'eina mostrarà la nota: El mecanisme ptr no s'hauria de publicar perquè és lent i poc fiable..

Si el registre analitzat compleix totes les regles i no presenta cap d'aquestes situacions, la secció de notes mostrarà el missatge: No s'ha trobat cap risc de sintaxi ni de política al registre enganxat..

Preguntes freqüents

Com es calcula l'estimació de consultes DNS de l'SPF?

L'estimació compta els termes include, a, mx, ptr, exists i redirect del registre enganxat. Els registres inclosos i redirigits poden afegir més consultes, de manera que una comprovació local no pot saber el total recursiu final.

Què passa si l'SPF necessita més de 10 consultes DNS?

Els receptors SPF han de tractar com un error permanent qualsevol avaluació que superi el límit de 10 termes amb consulta DNS. El límit inclou tota la cadena d'include i redirect, no només el primer registre.

Un resultat net demostra que la meva configuració SPF funciona?

No. Aquesta pàgina només comprova el text que enganxes. No consulta el DNS, no amplia els registres del proveïdor, no prova una IP remitent ni confirma què retornarà un servidor de correu receptor.