Qué es un registro SPF y cómo lo usan los receptores
SPF (Sender Policy Framework) es un registro TXT en tu dominio que indica qué servidores pueden enviar correo usando ese dominio en el remitente del sobre, la dirección MAIL FROM que también se conoce como Return-Path. Cuando un servidor receptor recibe un mensaje, consulta el registro SPF del dominio del sobre, recorre los mecanismos en orden y se detiene en el primero que coincide con la IP que conecta. El calificador de ese mecanismo decide el resultado: pass (+), fail (-), softfail (~) o neutral (?). Si no coincide nada, el mecanismo all final fija el valor por defecto.
Los mecanismos son sencillos. ip4 e ip6 listan direcciones o rangos CIDR de forma directa. a y mx significan «lo que apunten los registros A o MX de este host». include incorpora el registro SPF de otro dominio, que es la forma de autorizar a un proveedor: include:_spf.google.com significa «cualquier IP que publique Google puede enviar en mi nombre». Un dominio solo puede tener un registro SPF; dos registros que empiecen por v=spf1 son un error permanente y los receptores lo tratan como si no hubiera SPF.
SPF por sí solo es débil, porque el remitente del sobre es invisible para quien lee el mensaje y resulta fácil de configurar. Su valor real llega a través de DMARC, que comprueba que el dominio autenticado por SPF esté alineado con el dominio visible de la cabecera From. Por eso un dominio de cold email necesita SPF, DKIM y DMARC juntos, y no uno solo de los tres.
El límite de 10 búsquedas DNS y por qué rompe el SPF en silencio
El RFC 7208 limita a 10 los mecanismos que consultan DNS en cada evaluación. include, a, mx, redirect, exists y ptr cuestan una búsqueda cada uno, y cada include se sigue de forma recursiva, así que los includes que hay dentro del registro de tu proveedor también suman a tu total. ip4 e ip6 son gratis. Si superas el límite, los receptores devuelven permerror, que DMARC interpreta como un fallo de SPF. No hay ningún aviso: el registro simplemente deja de funcionar, normalmente el mismo día en que se añadió una herramienta de marketing nueva.
El generador cuenta tus búsquedas directas y suma una estimación de los includes anidados de cada proveedor. El include de Google Workspace, por ejemplo, arrastra tres registros de bloques de red, así que cuesta unas cuatro búsquedas por sí solo. Las estimaciones cambian cuando los proveedores reorganizan sus registros, y por eso la herramienta marca como cerca del límite cualquier valor de 8 o más, en lugar de esperar a 11.
- Incluye solo proveedores que envíen desde este dominio exacto. Un CRM que envía desde tu dominio principal no pinta nada en el registro de un dominio secundario.
- Usa ip4 e ip6 para los servidores que controlas tú; nunca cuentan para el límite.
- Si no consigues bajar de 10, mueve las herramientas de poco volumen a un subdominio con su propio registro SPF.
- No uses nunca ptr. Está obsoleto, es lento y cuenta como búsqueda.
Qué política usar: ~all, -all o ?all
El mecanismo all fija el resultado para cualquier IP que no haya coincidido con nada más. ~all (softfail) dice que los remitentes no listados probablemente no son legítimos; -all (fail) dice que seguro que no lo son; ?all (neutral) no dice nada. Para DMARC, softfail y fail son equivalentes, ambos cuentan como fallo de SPF, así que ~all no pierde protección una vez que DMARC está en marcha. Y evita un problema concreto: unos pocos receptores rechazan el correo con SPF -all en el momento de la conexión, antes de evaluar DKIM y DMARC, lo que rompe el correo reenviado que habría pasado por DKIM.
La recomendación práctica para dominios de cold email es ~all junto con una política DMARC que acabe llegando a rechazo. Pasa a -all solo cuando hayas verificado todas las fuentes de envío a través de los informes DMARC durante varias semanas. ?all no debería publicarse nunca: no da ninguna señal a los receptores y no ofrece ninguna protección contra la suplantación. +all autoriza a todo internet y muchos filtros lo tratan como señal de spam en sí mismo.
SPF para cold email: un registro por cada dominio secundario
Desde febrero de 2024, Gmail y Yahoo exigen que todo remitente se autentique con SPF o DKIM, y que quien envíe 5.000 mensajes o más al día a un proveedor publique SPF, DKIM y DMARC y mantenga las quejas de spam por debajo del 0,3 %. Microsoft aplicó requisitos equivalentes a Outlook.com en 2025. Los equipos de cold email suelen repartir el volumen entre varios dominios secundarios, y cada uno es un dominio de envío distinto a ojos de estas reglas. Cada uno necesita su propio registro SPF, con únicamente el proveedor que aloja sus buzones, normalmente Google Workspace o Microsoft 365.
No copies el registro de tu dominio principal en los dominios secundarios. El registro principal lista tu CRM, tu herramienta de facturación, tu soporte y tu plataforma de newsletter, y ninguno de ellos envía desde el dominio de outreach: esos includes de más gastan búsquedas y amplían la superficie de ataque. El registro de un dominio secundario suele ser un único include y ~all, muy por debajo del límite. Después de publicarlo, usa el verificador de arriba para confirmar que el registro en vivo coincide, y luego configura DKIM y DMARC. ColdBox ejecuta esa misma verificación en cada dominio conectado y te avisa si un registro cambia o desaparece.