Consulta y valida el registro TXT de SPF de cualquier dominio: mecanismos, cualificadores, la política all y el límite de 10 búsquedas DNS. Funciona gratis en tu navegador sobre DNS-over-HTTPS, sin registro y sin almacenar nada.
Crea una cuenta gratuita de Unspam para guardar tus resultados y repetir estas comprobaciones cuando quieras, así detectas una configuración rota antes de que te cueste caro. Sin tarjeta de crédito.
SPF (Sender Policy Framework, definido en el RFC 7208) es una lista publicada de los servidores autorizados a enviar correo en nombre de tu dominio. Reside en un único registro TXT de DNS en el dominio remitente que empieza por v=spf1, seguido de los mecanismos que nombran las fuentes autorizadas y una política all final. Cuando un proveedor de correo recibe un mensaje, coteja la IP de envío con el registro SPF del dominio del envelope (Return-Path) y usa el resultado como una señal más para la llegada a la bandeja de entrada. SPF es además uno de los pilares de DMARC, así que un registro correcto forma parte de cumplir los requisitos para remitentes masivos de Gmail, Yahoo, Outlook.com y Apple.
Todo registro SPF válido empieza por v=spf1. Si el registro no comienza con esta etiqueta exacta, o si no se devuelve ningún registro TXT, el dominio no tiene una política SPF utilizable.
Nombran las fuentes que autorizas. include delega en el SPF de otro dominio (por ejemplo, tu plataforma de correo), a y mx autorizan tus propios hosts A y MX, e ip4 / ip6 enumeran direcciones concretas o rangos CIDR.
El mecanismo del final fija el comportamiento por defecto para quien no aparezca en la lista: -all es un fallo estricto (recomendado), ~all es un fallo leve (habitual mientras haces pruebas), ?all es neutral y +all autoriza a cualquiera (no lo uses).
SPF permite como máximo 10 búsquedas DNS durante la evaluación. Mecanismos como include, a y mx consumen búsquedas cada uno, y los include anidados suman las suyas, así que el comprobador recorre toda la cadena de include para contar el total real y señala los registros que superan el límite. Despliega el desglose para ver de qué mecanismo procede cada búsqueda.
Un dominio debe publicar exactamente un registro TXT v=spf1. Si el comprobador encuentra dos o más, el registro no es válido y los proveedores devolverán un PermError.
Un dominio solo puede publicar un registro TXT que empiece por v=spf1. Cuando se añade un segundo (a menudo al configurar una nueva plataforma de correo), la evaluación devuelve un PermError y SPF falla en la práctica. Combina todas las fuentes en un único registro con varios mecanismos include.
Cada mecanismo include, a, mx, ptr y exists genera búsquedas DNS, y los include anidados añaden las suyas. En cuanto la evaluación necesita más de 10, el resultado es un PermError. Elimina los include de plataformas desde las que ya no envías, o mueve una plataforma a su propio subdominio con su propio registro. Aplanar un include en entradas ip4 también funciona, pero solo con un proveedor de direcciones estables: Microsoft desaconseja aplanar su propio include, porque las direcciones que hay detrás cambian y una copia aplanada se queda obsoleta sin avisar.
Terminar el registro con +all le dice a todo el mundo que cualquier servidor está autorizado a enviar en nombre de tu dominio, lo que desactiva SPF por completo y facilita la suplantación. Usa -all para un fallo estricto, o ~all mientras terminas de confirmar tus fuentes.
Si la consulta no devuelve nada, o un registro TXT que no empieza por v=spf1, el dominio no tiene ninguna política aplicable y DMARC no tiene nada con lo que alinearse. Publica un único registro que empiece por v=spf1 y termine con un all restrictivo.
Una única cadena TXT tiene un límite de 255 caracteres. Los registros largos deben dividirse en varias cadenas entrecomilladas dentro de un solo registro TXT (lo cual es válido), no en registros separados. Dividirlo en registros separados genera, en cambio, el error de registros múltiples.
SPF autoriza al remitente del sobre en el Return-Path, no la dirección que ve tu lector. Un mensaje puede pasar SPF mostrando el From que quiera, y por eso importa la alineación DMARC: SPF por sí solo demuestra muy poco.
Todas las fechas y cifras que Unspam publica sobre los requisitos para remitentes se guardan aquí, contrastadas con la documentación de cada proveedor. Última lectura: 16 de agosto de 2026.
| Proveedor | Qué | Valor | Se aplica a |
|---|---|---|---|
| Reglas para remitentes masivos vigentes desde fuente | febrero de 2024 obligatorio | correo a direcciones personales de Gmail | |
| Endurecimiento de la aplicación desde fuente | noviembre de 2025 observado Google lo describe como gradual y progresivo, no como un interruptor que se activó en una fecha. | correo a direcciones personales de Gmail | |
| Cuenta como remitente masivo a partir de fuente | 5.000 obligatorio Esta es la cifra de Google. Yahoo se niega a publicar ninguna. | correo a direcciones personales de Gmail | |
| Techo de la tasa de quejas de spam fuente | 0,3% obligatorio Google describe el efecto como gradual, no como un corte: por encima de la cifra recomendada la entrada en bandeja ya se resiente, y en el techo se resiente más. | todos los remitentes a Gmail, no solo los masivos | |
| Tasa de quejas de spam recomendada fuente | 0,1% recomendado Postmaster Tools no divide las quejas entre todo lo que enviaste. Las mide sobre los mensajes firmados con DKIM que llegaron a la bandeja de un destinatario activo, así que un remitente ya filtrado puede ver una tasa artificialmente baja. | todos los remitentes a Gmail, no solo los masivos | |
| Yahoo | Reglas para remitentes masivos vigentes desde fuente | febrero de 2024 obligatorio | correo a Yahoo, AOL y los demás buzones de Yahoo |
| Cuenta como remitente masivo a partir de fuente | no publicado Yahoo afirma que no especificará un umbral de volumen, así que no se le puede atribuir ninguna cifra. | correo a Yahoo, AOL y los demás buzones de Yahoo | |
| Techo de la tasa de quejas de spam fuente | 0,3% obligatorio | correo a Yahoo, AOL y los demás buzones de Yahoo | |
| Outlook.com | Reglas para remitentes masivos vigentes desde fuente | mayo de 2025 obligatorio | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 |
| Cuenta como remitente masivo a partir de fuente | 5.000 obligatorio La regla se aplica a cualquier dominio que haya superado el umbral alguna vez, así que sigue aplicándose en un día de menos volumen. | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 | |
| Qué pasa con el correo que falla fuente | 550 5.7.515 observado El correo que no cumple se rechaza durante la conversación SMTP en lugar de archivarse en la carpeta de spam. La página de políticas para postmasters de Microsoft sigue describiendo la carpeta de spam como primer paso, así que un remitente puede ver cualquiera de las dos cosas, pero conviene planificar para el rebote. | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 | |
| SPF y DKIM deben superarse ambos, no solo DMARC fuente | obligatorio Más estricto que DMARC por sí solo. DMARC se supera cuando se alinea SPF o DKIM, y Outlook.com pide además que ambas comprobaciones se superen. | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 | |
| Apple | Reglas para remitentes masivos vigentes desde fuente | febrero de 2025 obligatorio | correo a iCloud Mail, me.com y mac.com |
| Cabeceras ARC en el correo reenviado fuente | obligatorio Apple es el único de los cuatro que lo pide, que es la razón honesta para fijarse en ARC. | correo a iCloud Mail, me.com y mac.com |
Unspam lee todo esto solo a partir de tu nombre de dominio.
Ninguna consulta DNS llega a esto. Requiere un mensaje real o un historial de envíos real, que es para lo que sirve una prueba de entrega en bandeja.
