Herramientas populares

Tema

Verificar SPF — Registro SPF

Verifique el registro SPF de cualquier dominio como lo hacen los servidores de correo receptores: cada include con su propio costo de consulta DNS, el total acumulado frente al límite de 10, las consultas vacías y el resultado para cualquier IP de envío, con el término que lo decidió.

Fuentes: los registros TXT del dominio y cada include, mediante Google Public DNS (con Cloudflare 1.1.1.1 detrás) · check_host de la RFC 7208, ejecutado en nuestro servidor · no se guarda nada

Exactamente el nombre que escriba: SPF no se hereda, así que mail.example.com necesita su propio registro.

Pruebe

¿Qué es un registro SPF?

Un registro SPF es un registro TXT que enumera los servidores autorizados a enviar correo de un dominio. Empieza con v=spf1, nombra a los remitentes término por término y termina con lo que los receptores deben pensar de todos los demás (RFC 7208, abril de 2014, todavía el estándar vigente).

Los receptores lo comparan con la dirección del servidor que se conecta y con el dominio del remitente del sobre, el MAIL FROM o Return-Path, no con la línea From: que ve un lector. Vincular SPF con From: es tarea de DMARC.

Un registro cubre solo el nombre exacto en el que está publicado: SPF no se hereda, así que mail.example.com necesita un registro propio. Un dominio que no envía correo debe publicar v=spf1 -all.

Un registro SPF, término por términogoogle.com · TXT · registrado el 24 de octubre de 2026 · TTL 5 minutos
v=spf1Versióninclude:_spf.google.comMecanismo · 1 consulta~allCalificador ~ · mecanismo all

El include apunta a _spf.google.com · 8 rangos, sin más consultas

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

VersiónExactamente v=spf1, al principio: un registro que empiece de otra forma no es un registro SPF.
Mecanismosinclude, a, mx, ip4, ip6, exists, ptr y all, probados de izquierda a derecha: la primera coincidencia decide.
Calificadores+ pass (el predeterminado), - fail, ~ softfail, ? neutral, escritos delante de un mecanismo.
Modificadoresredirect= cede la verificación a otro registro; exp= explica un fail.
El registro completo de google.com son tres términos: un receptor obtiene el include, compara la IP de envío con sus rangos o llega a ~all. Registrado mediante Google Public DNS el 24 de octubre de 2026.

Cómo verificar un registro SPF

Escriba un dominio arriba y el verificador lee sus registros TXT, elige el que empieza con v=spf1 y sigue cada include y redirect como lo haría un servidor receptor, contando cada consulta DNS sobre la marcha.

A mano, pida los registros TXT: dig TXT example.com +short o nslookup -type=TXT example.com. La respuesta contiene todos los registros TXT del nombre; el registro SPF es el que empieza con v=spf1, y uno largo llega como varias cadenas entre comillas que SPF une sin espacio. Cada include es una consulta más, y usted tendría que contarlas.

Para saber si un servidor concreto puede enviar, cambie a Probar una IP: ejecuta la misma verificación para esa dirección y muestra el término que coincidió.

dig TXT example.com +short

Todos los registros TXT del nombre, tal como los tiene su resolutor; el registro SPF es el que empieza con v=spf1. Ejecútelo de nuevo para cada include.

Qué muestra dig y qué nogithub.com · dig TXT · registrado el 24 de octubre de 2026
Terminal1 de 24 registros TXT
$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  300  IN  TXT  "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# después cada include, una consulta a la vez:
$ dig +short TXT _spf.salesforce.com
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"
  1. Un registro empieza con v=spf1. Los 23 otros registros TXT que lo acompañan (tokens de verificación y similares) no importan para SPF, salvo por el tamaño de la respuesta.
  2. 2 cadenas, unidas sin espacio. La división de 255 bytes cae dentro de ip4:62.253.227.114: los receptores vuelven a unir las cadenas, así que no hay problema.
  3. TTL 5 minutos. Cuánto tiempo pueden conservar los resolutores esta copia después de un cambio. El servidor propio de la zona dice 5 minutos; un resolutor muestra lo que queda de su copia.
  4. Cada include es una consulta aparte. Seguir el registro de github.com lleva 10 consultas, con los anidados incluidos. dig muestra un nombre a la vez: la cuenta hasta 10 le toca sumarla a usted.
Windows
$ nslookup -type=TXT github.com 8.8.8.8
PowerShell
# todos los registros TXT del nombre, de Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8
Esta página
/es/spf-checker?domain=github.com
La respuesta TXT de github.com desde su propio servidor de nombres: el registro SPF llega como dos cadenas, unidas sin espacio, entre los demás registros TXT del dominio.

Cómo leer el resultado: el árbol de includes

El veredicto dice qué reciben los receptores para un remitente que el registro no incluye: válido con su final (softfail para ~all, fail para -all), o un permerror con su causa, o "no se pudo verificar" cuando el DNS no respondió.

La columna azul marino es el presupuesto de consultas: una celda por consulta DNS, coloreada según el include que la gasta, el total acumulado frente a 10 y las consultas vacías como anillos. Pasada la 10.ª, las celdas se vuelven rojas y se marca la rama donde se detienen los receptores.

La vista Árbol enumera las lecturas, primero las que fallan, cada una con su sección de la RFC y su solución, y luego cada consulta en el orden en que la hace un receptor.

Verificar SPF de github.com: 10 de 10 consultas DNS, una vacía y el costo de cada include en el presupuesto de consultasVerificar SPF de github.com: 10 de 10 consultas DNS, una vacía y el costo de cada include en el presupuesto de consultasEl veredictoLo que reciben los receptores para un remitente que el registro no incluye, y el final que lo decide.El registro, término por términoCada término coloreado según su tipo; un include lleva la marca de su propietario y su propio costo de consultas.Las lecturasUn registro, sintaxis válida, consultas, vacías, el final, ptr, DMARC: primero las que fallan, cada una con su solución.El presupuesto de consultasCada consulta DNS como una celda, coloreada según el include que la gasta, frente al límite de 10.El costo de cada includeUna rama por include: sus propias celdas, lo que anida y el total acumulado.Las consultas vacíasAnillos para las consultas que volvieron vacías; la tercera termina la verificación.
Una verificación SPF de github.com: el veredicto, el registro dividido en sus términos, las lecturas y el presupuesto de consultas con el costo propio de cada include. Seleccione un número para ver qué muestra cada parte.

El límite de 10 consultas y "too many DNS lookups" (permerror)

Los receptores cuentan cada término que necesita una consulta DNS, include, a, mx, ptr, exists y redirect, a través de cada include anidado, y se detienen en 10. La 11.ª da permerror (RFC 7208 §4.6.4). ip4, ip6, all y exp no cuestan nada.

Es un permerror, no un fail: lo que haga un receptor con él es decisión suya, pero con DMARC un permerror nunca cuenta como pass. Y como la verificación se detiene en la primera coincidencia, un registro que supera el límite sigue dando pass para los remitentes listados al principio y solo se rompe para los listados al final.

El costo se esconde dentro de los includes: include:_netblocks.mimecast.com gasta 9 por sí solo, el de Yandex 360 gasta 8, el de Freshdesk 7 y el de Mailgun 5. Los includes de Google y de Microsoft 365 cuestan 1 cada uno. Para bajar de 10, quite los remitentes que ya no usa y pase un remitente masivo a un subdominio con su propio registro.

Quién gasta las 10 consultasCostos medidos el 24 de octubre de 2026 · un registro inventado con includes reales

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

17 consultas necesarias
Listado dentro de las primeras 10 consultas: passMicrosoft 3651Mimecast2–10
Listado después de la consulta 10: permerrorMailgun11–15Twilio SendGrid16–17

Todos los demás reciben permerror también, no el fail de -all del registro: los receptores se detienen antes de llegar a él.

Cuánto cuesta un includeEl include documentado por cada proveedor · medido el 24 de octubre de 2026
  • _netblocks.mimecast.comMimecast9 consultas
  • _spf.yandex.netYandex 3608 consultas
  • email.freshdesk.comFreshdesk7 consultas
  • mailgun.orgMailgun5 consultas
  • icloud.comiCloud+5 consultas
  • spf.titan.emailTitan Email4 consultas
  • secureserver.netGoDaddy3 consultas
  • _spf.google.comGoogle Workspace1 consulta
  • spf.protection.outlook.comMicrosoft 3651 consulta
Consultas contadas como lo hace la RFC 7208 §4.6.4: el include mismo más todo lo que hay dentro. Los conteos en vivo de esta página siempre salen del recorrido, no de esta tabla.

¿Qué son las consultas vacías?

Una consulta vacía (void lookup) es una consulta que vuelve sin registros: el nombre no existe (NXDOMAIN) o existe sin el registro pedido. Los receptores deben permitir dos; la tercera es permerror (RFC 7208 §4.6.4).

Un término que apunta a un host que ya no existe, a:old.example.com, no es un error por sí solo: simplemente no coincide y cuenta una consulta vacía. Lo mismo pasa con exists:%{i}._spf.mta.salesforce.com para cada remitente que Salesforce no incluye, y por eso importa el orden de los includes.

Una falla del servidor o un tiempo de espera agotado no es una consulta vacía: es un temperror, y los receptores suelen reintentar más tarde.

Cuatro respuestas, tres resultadosRFC 7208 §4.6.4

El propio registro de salesforce.com para 192.0.2.1, registrado el 24 de octubre de 2026

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Consultas vacías2 / 2una tercera: permerror
  1. exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · consulta 3 · en _spf.salesforce.com
  2. exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · consulta 4 · en salesforce.com

Resultado: softfail, con las dos consultas vacías permitidas ya gastadas

El nombre existe, el registro noa:mail.example.com para un nombre que sigue ahí pero ya no tiene una dirección: NOERROR sin respuesta. Sin coincidencia, una vacía, y la verificación continúa.NODATAvacía
El nombre no existeexists:%{i}._spf.mta.salesforce.com construye un nombre a partir de cada IP de envío; para una dirección que Salesforce no incluye, la respuesta es NXDOMAIN: una vacía cada vez.NXDOMAINvacía
La tercera vacíamx:shop.example.com, un nombre que ya no existe, después de 2 vacías: los receptores se detienen aquí.NXDOMAINpermerror
Ninguna respuestaSERVFAIL o tiempo de espera agotado para include:_spf.vendor.example: el DNS falló, así que nada cuenta como vacía.SERVFAILtemperror, no una vacía

El include include:spf.bmv.jp de blastmail empieza con dos términos exists como esos: para una dirección que no incluye, gasta por sí solo las dos consultas vacías permitidas.

Solo una respuesta vacía cuenta como vacía. Una falla es un temperror, y la verificación se reintenta más tarde.

Aplanar SPF (flattening): cuándo ayuda y cuándo rompe

Aplanar reemplaza un include por las direcciones que enumera, de modo que el registro cuesta menos consultas. Funciona para rangos que rara vez cambian, y sale mal cuando un proveedor agrega un servidor que usted no copió: el correo de ese servidor falla SPF.

Microsoft dice que no se aplane include:spf.protection.outlook.com, y los includes de Google y de Microsoft ya cuestan una consulta cada uno. Pasar un remitente masivo a un subdominio como news.example.com le da un registro, y 10 consultas, propios.

Un include, aplanadomailgun.org · registrado el 24 de octubre de 2026

Antes

include:mailgun.org

Consultas
5
Registros obtenidos
5
Bytes en su registro
19
Mailgun cambia un rango
se toma al instante

Después

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 más

Consultas
0
Bytes en su registro
450
Cadenas TXT necesarias
2
Mailgun cambia un rango
su copia está desactualizada

El riesgo de la copia desactualizada. Usted copia 22 rangos hoy; cuando Mailgun agrega uno, el correo de ese rango falla SPF hasta que alguien lo nota y actualiza el registro.

  1. copiado
  2. Mailgun agrega un rango
  3. el correo de ese rango falla SPF
Aplane solo los rangos que rara vez cambian, como las direcciones de sus propios servidores.
No aplane Microsoft 365: Microsoft dice que sus direcciones de envío cambian a menudo, así que conserve el include.
Prefiera un subdominio por remitente masivo: cada uno recibe un registro, y 10 consultas, propios.
Aplanar cambia consultas por mantenimiento: la copia es correcta solo hasta que el proveedor cambia sus rangos.

~all frente a -all (y DMARC)

El último término dice qué pasa con todo remitente no incluido. -all es fail, la declaración más fuerte; ~all es softfail, "probablemente no"; ?all es neutral, que los receptores tratan como si no hubiera SPF; +all deja pasar a todos y nunca debe publicarse.

Entre ~all y -all no hay una respuesta equivocada. Google documenta ~all para Google Workspace y Microsoft -all para Microsoft 365. Con DMARC en modo de aplicación, ~all deja que DMARC decida según DKIM: algunos receptores rechazan por -all antes de que DMARC vea una firma DKIM válida, así que el correo reenviado puede rebotar (RFC 9989 §7.1).

Los cuatro finalesRFC 7208 §2.6 · RFC 9989 §7.1
~all
softfail“Probablemente no autorizado”: los receptores no deberían rechazar solo por esto.
Documentado porGoogle WorkspaceMailguniCloud+
-all
failLa declaración más fuerte: un receptor puede rechazar el mensaje en SMTP.
Documentado porMicrosoft 365ZendeskGoDaddy
?all
neutralNinguna declaración: los receptores lo tratan exactamente como si no hubiera SPF.
Documentado porFastmailLos includes de IONOS y OVHcloud también terminan en ?all: es inofensivo ahí, porque solo coincide un pass dentro de un include.
+all
pass para todosCualquier servidor de Internet pasa como el dominio.
No lo publique nunca

-all con DMARC en p=reject

  1. SPF: fail
  2. rechazado en SMTP
  3. DKIM nunca se verifica

Algunos receptores actúan primero según SPF, así que un mensaje reenviado con una firma DKIM válida puede rechazarse antes de que se ejecute DMARC, y la pérdida nunca aparece en los informes de DMARC.

~all con DMARC en p=reject

  1. SPF: softfail
  2. DMARC verifica DKIM
  3. DKIM alineado: pass

DMARC decide. Sin una firma DKIM, sin embargo, Microsoft dice que DMARC se ignora en la práctica para los fallos de ~all, y por eso recomienda -all.

Tanto ~all como -all son opciones válidas; ?all no dice nada, y +all deja pasar a cualquiera.

Errores comunes del registro SPF y cómo corregirlos

La mayoría de los registros rotos vienen de tres descuidos: un segundo registro SPF agregado junto al primero en vez de unirlos, un include de un proveedor que ya no existe y un valor copiado de la documentación con un error de escritura.

La documentación de algunos proveedores imprime estos errores: Mimecast escribe –all con un guion medio, Postmark include: spf.mtasv.net con un espacio, Twilio SendGrid enumera un mecanismo aaaa que no existe. Cualquier error de sintaxis convierte todo el registro en permerror. Un punto final después de un dominio, en cambio, es válido.

Ocho registros, ocho resultadosEjemplos inventados de errores reales

Dos registros SPFpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Solución: únalos en uno: un v=spf1, cada include una vez, un solo final.

Más de 10 consultaspermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 consultas

Solución: quite los remitentes que ya no usa, o dé a un remitente masivo un subdominio propio.

Una tercera consulta vacíapermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 vacías

Solución: elimine los términos cuyos nombres ya no existen y ponga al final los includes exists.

Un include sin registro SPF detráspermerror

v=spf1 include:spf.retired-vendor.example -all

Solución: corrija el nombre o quite el proveedor que dejó.

Un guion medio en –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

Impreso así en la propia documentación de Mimecast

Solución: un guion simple: -all.

Un espacio después de include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

Impreso así en la propia documentación de Postmark

Solución: include:spf.mtasv.net

Un mecanismo aaaapermerror

v=spf1 aaaa:example.com ~all

Impreso así en la propia documentación de Twilio SendGrid

Solución: a:example.com; a ya coincide con los registros AAAA de los remitentes IPv6.

Un punto finalválido

v=spf1 include:spf.protection.outlook.com. -all

Válido: la RFC 7208 §7.3 dice que no se publique, pero los receptores deben aceptarlo.

La ayuda de Zendesk también dice “redirect: syntax is supported”: el modificador se escribe redirect= (RFC 7208 §6.1).

Cada registro es un ejemplo inventado; los errores son los que los receptores ven con más frecuencia.

Qué exigen Gmail, Yahoo y Microsoft

Desde febrero de 2024, Gmail y Yahoo exigen a todo remitente configurar SPF o DKIM. Los remitentes masivos necesitan ambos, un registro DMARC de al menos p=none y un dominio de From: alineado con uno de ellos. Outlook.com pide SPF y DKIM a los remitentes de alto volumen, y rechaza a los que no los tienen desde el 5 de mayo de 2025.

El umbral de Gmail es de más de 5000 mensajes al día a cuentas personales; Yahoo no publica ninguno. SPF por sí solo nunca deja el correo "alineado": el dominio de MAIL FROM tiene que ser suyo, no el dominio de rebote del proveedor.

Las reglas de los tres proveedores de buzonesLeído en las páginas propias de cada proveedor, 24 de octubre de 2026
GmailYahooOutlook.com
Umbral masivoGmailmás de 5000 mensajes al día a cuentas personales de Gmail, contados por dominio principalYahooninguno publicado: “We will not specify a volume threshold”Outlook.commás de 5000 al día (el blog de Microsoft); 5000 o más desde un mismo dominio de From: (su artículo de soporte)
Todos los remitentesGmailSPF o DKIM, más DNS directo e inverso, TLS y una tasa de spam inferior a 0,3 %YahooSPF o DKIM, más DNS directo e inverso y una tasa de spam inferior a 0,3 %Outlook.comninguna regla estricta
Remitentes masivosGmailSPF y DKIM, DMARC (basta p=none), From: alineado con SPF o DKIM, cancelación de suscripción con un clic en el correo de marketingYahooSPF y DKIM, DMARC al menos p=none y aprobado, From: alineado con SPF o DKIM, cancelación de suscripción con un clicOutlook.comSPF debe dar pass y DKIM debe dar pass, DMARC al menos p=none, alineado con SPF o DKIM
En vigor desdeGmail1 de febrero de 2024; los rechazos aumentaron desde noviembre de 2025Yahoofebrero de 2024Outlook.com5 de mayo de 2025 (rechazo)
El fallo de SPF aparece comoGmail4.7.275.7.27Yahoono documentado para SPFOutlook.com550 5.7.515

Japón: el ajuste más estricto de NTT docomo, 「全て拒否する」, rechaza el correo cuya IP de envío no autoriza el registro SPF del dominio, y el correo de dominios que no publican ningún registro SPF. docomo.ne.jp

Fuentessupport.google.comsenders.yahooinc.comtechcommunity.microsoft.com

Las reglas de cada proveedor tal como las enuncian sus propias páginas el 24 de octubre de 2026.

Consulta de registro SPF frente a dig y nslookup

dig y nslookup muestran los registros TXT tal como los tiene su resolutor: el registro SPF y lo que más haya en el nombre. No siguen los includes, no cuentan consultas ni vacías y no dicen qué decidiría un receptor.

Una consulta de registro SPF como esta recorre todo el registro, así que las cifras coinciden con lo que calcula un servidor receptor. Use dig para un nombre, este verificador para el veredicto.

Tres formas de ver SPFQué muestra cada una
Este verificadordig TXTnslookup -type=TXT
Muestra los registros TXTEste verificadorSídivididos en términosdig TXTSínslookup -type=TXTSí
Une las cadenas de un registro largoEste verificadorSícomo los receptoresdig TXTNomuestra cada cadena por separadonslookup -type=TXTNomuestra cada cadena por separado
Sigue cada includeEste verificadorSíel árbol completodig TXTNoun nombre por consultanslookup -type=TXTNoun nombre por consulta
Cuenta las consultas hasta 10Este verificadorSíun total acumulado, por includedig TXTNoa manonslookup -type=TXTNoa mano
Cuenta las consultas vacíasEste verificadorSícon los nombresdig TXTNonslookup -type=TXTNo
Dice que dos registros = permerrorEste verificadorSídig TXTNoimprime ambosnslookup -type=TXTNoimprime ambos
Prueba una IP de envíoEste verificadorSícheck_host y el término que coincidedig TXTNonslookup -type=TXTNo
Consulta a su propio resolutorEste verificadorNoGoogle Public DNS, desde nuestro servidordig TXTSínslookup -type=TXTSí
La misma pregunta hecha de tres formas: dig y nslookup muestran lo que tiene su propio resolutor, el verificador lo que calcula un receptor.

Verificador SPF: preguntas frecuentes

¿Qué es verificar un registro SPF?

Verificar un registro SPF es leer el registro SPF de un dominio, el registro TXT que empieza con v=spf1, y recorrerlo como lo hace un servidor de correo receptor: cada include y redirect seguido, cada consulta DNS contada contra el límite de 10 y cada respuesta vacía contra el límite de 2. Termina con lo que reciben los receptores para un remitente no incluido, o con el permerror y su causa.

¿Cómo pruebo si una dirección IP puede enviar correo de mi dominio?

Elija Probar una IP, escriba el dominio y la dirección del servidor de envío, IPv4 o IPv6, y si quiere la dirección MAIL FROM y el nombre HELO. El verificador ejecuta check_host para esa dirección y muestra pass, fail, softfail, neutral o permerror, el término exacto que coincidió, su calificador y la cadena de includes que llevó hasta él.

¿Qué significa "SPF too many DNS lookups"?

Significa que verificar el registro requiere más de 10 consultas DNS, el límite de la RFC 7208. Cada include, a, mx, ptr, exists y redirect cuesta una, incluidas las anidadas dentro de includes. Los receptores se detienen en la 11.ª con permerror, así que los remitentes listados después de ese punto dejan de pasar SPF. Quite los includes que no usa, o pase un remitente a un subdominio con su propio registro.

¿Qué es un permerror de SPF?

Un permerror es el resultado de SPF que significa "este registro no se puede evaluar". Viene de más de 10 consultas DNS, más de 2 consultas vacías, dos registros SPF en un mismo nombre, un include de un nombre sin registro SPF o un error de sintaxis. No es un fail: los receptores deciden qué hacer con él, pero con DMARC nunca cuenta como pass.

¿Qué es una consulta vacía en SPF?

Una consulta vacía es una consulta DNS hecha para un término SPF que vuelve sin nada: el nombre no existe (NXDOMAIN) o no tiene un registro del tipo pedido. La RFC 7208 dice que los receptores deben permitir dos; la tercera es permerror. Una falla del servidor o un tiempo de espera agotado no es una consulta vacía sino un temperror, que los receptores suelen reintentar más tarde.

¿Mi registro SPF debe terminar con ~all o con -all?

Ambos son válidos. -all (fail) es la declaración más fuerte y Microsoft la documenta para Microsoft 365; ~all (softfail) es lo que Google documenta para Google Workspace. Con firma DKIM y DMARC en quarantine o reject, ~all suele ser el final más seguro, porque algunos receptores rechazan por -all antes de que DMARC pueda aceptar una firma DKIM válida.

¿Puede un dominio tener dos registros SPF?

No. Si un nombre tiene dos registros TXT que empiezan con v=spf1, los receptores no pueden elegir uno y la verificación termina en permerror antes de cualquier consulta, para todos los remitentes (RFC 7208 §4.5). Suele pasar cuando se agrega el registro de un proveedor nuevo junto al antiguo. Únalos en un solo registro con un v=spf1, cada include una vez y un solo final.

¿Qué es aplanar un registro SPF y debo hacerlo?

Aplanar reemplaza los includes por los rangos de IP que enumeran, de modo que el registro necesita menos consultas DNS. Sirve para rangos que rara vez cambian, pero una copia aplanada queda desactualizada en cuanto el proveedor agrega servidores, y el correo de ellos falla SPF. Es preferible quitar los includes que no usa o dar a un remitente masivo su propio subdominio; nunca aplane el include de Microsoft 365.

¿Un subdominio necesita su propio registro SPF?

Sí. SPF no se hereda: un registro cubre solo el nombre exacto en el que está publicado, así que mail.example.com o news.example.com necesita su propio registro si aparece en MAIL FROM o HELO. Esto difiere de DMARC, que recurre al dominio de la organización. Un subdominio que no envía correo puede publicar v=spf1 -all.

¿Por qué SPF da pass aquí pero falla en Gmail?

Normalmente porque Gmail verificó otro dominio u otra dirección. SPF se evalúa para el dominio de MAIL FROM (Return-Path) y la IP del servidor que se conecta, que pueden ser el dominio de rebote de su proveedor, no el suyo. El reenvío también rompe SPF, porque la IP del reenviador no está en su registro. Revise el encabezado Authentication-Results de un mensaje real y pruebe aquí esa IP y ese dominio.

¿Cuál es la diferencia entre SPF, DKIM y DMARC?

SPF enumera los servidores autorizados a enviar de un dominio y se verifica contra el remitente del sobre. DKIM firma cada mensaje con una clave publicada en el DNS, así que la firma sobrevive al reenvío. DMARC los vincula con la dirección de From: que ve un lector: un mensaje pasa DMARC cuando SPF o DKIM da pass para un dominio alineado con From:, y la política dice qué hacer en caso contrario.

¿Cuánto tarda en surtir efecto un cambio en un registro SPF?

Tanto como los resolutores conserven el registro anterior: hasta su TTL, que fija el dominio (300 segundos para google.com y github.com, una hora para microsoft.com cuando lo verificamos). Los receptores preguntan a su resolutor, así que un cambio se ve cuando vence cada copia en caché. Este verificador muestra el TTL tal como lo sirve el servidor de nombres propio del dominio; verifique de nuevo pasado ese tiempo.

¿Le falta algo?Sugiera una función o una herramienta nueva

Más herramientas de correo y DNS