Un solo SPF para facturador y boletín

El facturador de boletas y facturas, el CRM o la plataforma del boletín te van a pedir que autorices su envío en el DNS. El paso que rompe el correo de la empresa es agregar un segundo TXT que empiece con v=spf1. El RFC 7208 exige un solo registro SPF por nombre. Si hay dos, la comprobación devuelve permerror para todo el correo que use ese nombre en el sobre, casillas incluidas.

Esta guía es para fusionar ese permiso en el TXT que ya tienes, contar las consultas DNS y comprobar el mensaje real. Si todavía estás leyendo quién envía a tu nombre antes de endurecer DMARC, sigue en cómo leer los reportes agregados.

Qué comprueba el SPF

SPF autoriza direcciones IP para una identidad de correo. En un envío normal, esa identidad es el MAIL FROM del sobre SMTP: la dirección de retorno, la que ves después como Return-Path. No es el campo De que lee el cliente.

El mismo RFC también puede comprobar el nombre del HELO. DMARC, en el RFC 9989 (publicado en mayo de 2026, reemplaza al RFC 7489), usa solo el dominio del MAIL FROM. Si el camino de retorno viene vacío, como en algunos avisos automáticos del servidor, esa identidad pasa a ser postmaster en el dominio del HELO. Una boleta o un boletín salen con un sobre con dirección. Ahí manda el Return-Path.

Por eso un servicio puede mostrar [email protected] en el De y, al mismo tiempo, usar un sobre de su propio dominio. El SPF de tu dominio no interviene en esa comprobación. El de ellos sí, y puede dar pass sin que tu dominio quede alineado para DMARC. Más abajo está qué pedirles además del include:.

El registro se publica como TXT. El tipo de registro llamado SPF quedó fuera del RFC 7208. Si el panel ofrece los dos, elige TXT.

Un solo TXT con v=spf1

El receptor pide los TXT del nombre y se queda con los que empiezan por v=spf1. Las mayúsculas no cambian el resultado: V=SPF1 también cuenta. Si no queda ninguno, el resultado es none. Si queda más de uno, es permerror.

permerror significa que el DNS publicado no se puede interpretar. Lo corrige quien administra la zona. No es un “quizá spam” del mensaje nuevo: falla la evaluación completa de ese nombre. Las casillas que ayer pasaban SPF quedan en el mismo error hasta que vuelvas a dejar un solo registro.

Los otros TXT del mismo nombre siguen ahí. Una verificación de sitio, un código de un servicio o un texto que no empieza con v=spf1 no es un segundo SPF. DKIM vive en selector._domainkey y DMARC en _dmarc: son otros nombres.

Si ya tienes dos SPF, el arreglo es uno solo con todos los mecanismos que de verdad usas. Mientras los dos sigan publicados, el error se mantiene.

Cómo se fusiona el include

Anota el TXT completo antes de tocarlo. El valor nuevo conserva lo que ya autoriza a tus casillas y suma solo el mecanismo que documenta el proveedor hoy. No copies el registro de otra empresa ni el ejemplo de un formulario.

Pide por escrito tres datos. El mismo pedido está en la guía de reportes DMARC:

El include: o las direcciones ip4: / ip6: que su documentación manda publicar.
El DKIM de tu dominio: el nombre selector._domainkey y si es CNAME o TXT.
La dirección del De y la del sobre, si no son la misma.

Del proveedor copias el mecanismo, no su registro entero. Su TXT suele traer v=spf1 al principio y un all al final. Esos dos no entran en el tuyo.

all siempre coincide, y el RFC pide ignorar todo lo que venga después. Si pegas el ~all del proveedor en medio, el include: que escribiste a la derecha no se evalúa. El facturador sigue sin autorización y el registro parece “completo”.

Un ejemplo, con nombres que no son de ningún proveedor. No lo publiques:

v=spf1 include:spf.correo.example include:spf.facturador.example include:spf.boletin.example ~all

include: no pega los mecanismos del otro dominio dentro del tuyo. Consulta el SPF de ese nombre y solo aprovecha un pass. Si el incluido responde fail, softfail o neutral, tu registro sigue con el mecanismo siguiente. El -all del proveedor no rechaza tu correo: decide el all que dejaste al final del tuyo.

Si el nombre del include: no tiene SPF, el resultado de esa consulta es none y el include: lo convierte en permerror para todo el chequeo. Un error de tipeo en el dominio del facturador deja en permerror también a las casillas. Después de guardar, compara el texto con lo que te entregaron.

Si las casillas están en Google Workspace, la ayuda de SPF de Workspace documenta include:_spf.google.com y recomienda cerrar con ~all cuando solo envía Workspace. Ese include: se conserva y el del facturador se agrega en el mismo TXT. La guía de Cloudflare para Workspace lo dice en la misma frase: un segundo TXT con v=spf1 hace fallar la comprobación. El día que edites, confirma el nombre con dig TXT _spf.google.com +short. El contenido de ese registro lo cambia Google.

Para el facturador, el CRM o el boletín, el include: sale de la documentación de ese servicio, con fecha de hoy. Una tabla copiada de otra guía envejece. El correo con el PDF o el XML de la boleta lo envía el facturador que contrataste. El valor no se deduce del nombre comercial.

ip4: e ip6: sirven cuando el proveedor documenta direcciones estables. No suman consultas DNS. No saques la IP de una cabecera recibida y la pegues: puede ser un relay compartido, y si la cambian tu registro queda atrasado. ptr no se publica: el RFC 7208 dice que no se use, y además gasta consulta.

redirect= es otra herramienta. Con un all en el registro, el redirect se ignora. No lo agregues encima del TXT que ya cierra con all.

El límite de 10 consultas

El RFC 7208 limita a 10 los términos que consultan DNS durante toda la evaluación, incluidos los que aparecen dentro de cada include:. Si el conteo pasa de 10, el resultado es permerror. Otra vez el registro completo, no solo el servicio nuevo.

Cuentan: include, a, mx, ptr, exists y redirect.

No cuentan: all, ip4, ip6 y exp.

La ayuda de Workspace resume el tope como diez include:. El límite del RFC también suma a, mx, ptr, exists, redirect y lo que haya dentro de cada include:. Un solo include: puede esconder varios.

Hay dos topes aparte. Cada mx no puede resolver más de 10 direcciones A o AAAA; si se pasa, ese mecanismo da permerror. Las consultas que vuelven vacías o con nombre inexistente se llaman void lookups: la implementación debería cortar en dos y devolver permerror.

El registro también conviene corto. Cada trozo de un TXT mide como máximo 255 octetos. Si el DNS parte el texto en varios trozos de un mismo registro, se concatenan sin agregar espacios. Un segundo TXT “para que quepa el resto” vuelve al permerror de dos SPF. El RFC pide, además, que la respuesta quepa en 512 octetos. Como guía, si el nombre más todos los TXT de ese nombre quedan bajo unos 450 octetos, la respuesta cabe en un paquete UDP chico. Un TXT de verificación en el mismo nombre entra en esa cuenta de tamaño y no entra en la cuenta de registros SPF.

Para contar el tuyo:

dig TXT tudominio.cl +short

Anota cada include:, a, mx, ptr, exists y redirect. Para cada include:, repite la consulta y suma los términos de adentro. Las direcciones de documentación 192.0.2.10 y 192.0.2.11 no son servidores reales. El ejemplo siguiente tampoco se publica.

Qué consultas	TXT que encuentras	Cuánto suma
`include:spf.correo.example`	`v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 -all`	1. Los `ip4` no suman
`include:spf.facturador.example`	`v=spf1 include:a.facturador.example include:b.facturador.example -all`	3, si `a` y `b` solo tienen `ip4`
`include:spf.boletin.example`	`v=spf1 a mx include:c.boletin.example ~all`	4, si `c` solo tiene `ip4`

Cada fila ya incluye la consulta del include: de tu registro. La suma es 8. Cabe. Si el boletín trae otros tres include: con nombre propio, el total pasa de 10 y las casillas caen en permerror junto con el boletín.

Si no cabe:

Quita mecanismos de servicios que ya no envían.
Prefiere ip4: o ip6: solo cuando el proveedor documente esas direcciones como estables.
Pasa el envío automático a un subdominio, con su propio SPF. El presupuesto de 10 de ese nombre no se mezcla con el del dominio pelado.

El comprobador de Scott Kitterman, autor del RFC 7208, está en kitterman.com/spf/validate.html. Usa una biblioteca del RFC y prueba los límites de proceso. La prueba por nombre de dominio lee lo que está publicado. La de sintaxis solo revisa el texto que pegas, sin buscar el registro del dominio: sirve antes de guardar, y no reemplaza la prueba con el dominio ya publicado.

~all y -all

El calificador va pegado al mecanismo. Si no escribes uno, vale + (pass).

Calificador	Resultado cuando coincide	Qué declara
`+`	`pass`	Esa IP está autorizada
`-`	`fail`	No está autorizada
`~`	`softfail`	Probablemente no está autorizada
`?`	`neutral`	No se afirma nada

all coincide siempre, así que el calificador del final es la política para quien no entró antes. -all es un fail. ~all es un softfail: el RFC lo define como una declaración débil, no como un rechazo. ?all no afirma. +all autoriza a cualquier IP. No lo publiques.

Si el registro no trae all ni redirect, el resultado por defecto es neutral, el mismo de ?all. Conviene cerrar el TXT con un all para que el diagnóstico sea legible.

Para DMARC solo cuenta un pass alineado. ~all y -all dejan fuera de ese pass a quien no coincidió con un mecanismo anterior. La diferencia se nota en los receptores que miran el SPF por su cuenta: un fail es una negativa explícita y un softfail es la versión débil. La ayuda de SPF de Workspace recomienda la tilde y advierte que el guion puede ser demasiado estricto para correo legítimo que todavía no está en el registro.

Si tu zona ya usa uno de los dos y las casillas funcionan, conserva ese calificador. No lo cambies para que calce con el ejemplo del facturador. Cambiar de ~all a -all endurece a todo lo que no esté listado, incluido un formulario que se te pasó.

El include no alinea el De

DMARC pasa si SPF o DKIM dan pass y ese dominio queda alineado con el De. El RFC 9989 lo recomienda con los dos mecanismos, no con uno solo. No existe una lista estándar de “dominios ajenos autorizados a usar mi De”. Un pass en el dominio del proveedor no autoriza el tuyo.

Estas son las tres formas en que suele llegar el correo del facturador, del CRM o del boletín:

Sobre (`Return-Path`)	Qué hace tu SPF del dominio pelado	Qué pide DMARC
`@tudominio.cl`	Tiene que incluir a ese servicio, en el único TXT	Con `pass`, el SPF queda alineado
Un dominio del proveedor	No interviene en ese chequeo	Hace falta un DKIM con `d=` de tu dominio, o un sobre en un nombre tuyo
`@boletas.tudominio.cl`	No interviene: ese nombre tiene su propio SPF	Con alineación relajada, el sobre de ese subdominio alinea con el De de la empresa

La alineación relajada (aspf=r) es el valor por defecto. Compara el dominio organizacional. En un .cl de empresa, boletas.tudominio.cl y tudominio.cl cuentan como la misma organización. La estricta (aspf=s) exige el mismo nombre completo: ese par falla. El detalle para leerlo en el XML está en la guía de reportes.

El DKIM que te sirve trae d=tudominio.cl o d= de un subdominio tuyo. Una firma con el dominio del facturador puede ser válida y, aun así, quedar desalineada. Suele publicarse como CNAME en selector._domainkey. El selector lo indica el proveedor. En Cloudflare, si ese CNAME tiene aplanado, puede dejar de servir: el ajuste está en la guía de Cloudflare delante del hosting.

Un reenvío cambia la IP que entrega y suele romper el SPF. La firma DKIM puede seguir verificando si el mensaje no se tocó. Por eso el include: y el DKIM de tu dominio van juntos.

Gmail, Yahoo y Outlook.com piden autenticación a quien les escribe. El desglose por volumen está en la guía de reportes. En corto, con las páginas vigentes al escribir esto:

Gmail. Desde el 1 de febrero de 2024, todo remitente hacia cuentas personales necesita SPF o DKIM. Quien envía más de 5.000 mensajes al día a esas cuentas necesita SPF y DKIM, un DMARC (puede ser p=none) y el De alineado con el SPF o con el DKIM en el correo directo. La tasa de spam que muestra Postmaster Tools se mantiene bajo el 0,3 %. La fuente es la guía para remitentes.
Yahoo. También desde febrero de 2024: SPF o DKIM para todos, y para el envío masivo SPF y DKIM, un DMARC de al menos p=none que además pase, y el De alineado. La alineación relajada les sirve. No publican un umbral numérico de “masivo”. La fuente es el Sender Hub.
Outlook.com. Desde el 5 de mayo de 2025, un dominio que envía más de 5.000 mensajes al día a los servicios de consumo de Microsoft tiene que pasar SPF y DKIM, publicar DMARC (el ejemplo que dan admite p=none; en la página de políticas recomiendan p=reject) y alinear al menos uno de los dos con el De. Si no se cumple, el mensaje va a correo no deseado y puede terminar en 550 5.7.515.

Esas reglas no reemplazan la lectura de tus propios envíos. Un include: pegado el mismo día que pasas DMARC a rechazo puede rebotar la boleta si el sobre no quedó alineado.

Un subdominio para lo automático

Cuando el dominio pelado ya va justo de consultas, o cuando no quieres mezclar la reputación del boletín con la de las casillas, el envío automático usa un nombre propio. Dos variantes:

El De también cambia. Las boletas salen de [email protected]. Publicas el SPF en boletas, no en el dominio pelado. El cliente ve ese nombre. El SPF del dominio pelado no se hereda: la consulta es al nombre exacto del sobre. Sin un TXT en boletas, el resultado es none.

El De de la empresa se mantiene y el sobre usa el subdominio. El cliente sigue viendo [email protected]. El Return-Path es @boletas.tudominio.cl, donde está el SPF del proveedor. Con alineación relajada, ese sobre alinea con el De. Hace falta que el proveedor permita configurar ese sobre. Si ellos fijan el Return-Path en su dominio, este camino no está disponible y vuelve a hacer falta el DKIM con d= tuyo.

En los dos casos el MX del dominio pelado sigue donde está el correo de las personas. El subdominio de envío no tiene por qué recibir correo de casillas. Si el proveedor te pide un MX para los rebotes, usa el que él documente, en ese nombre, y no reemplaces el MX de tudominio.cl.

DMARC del subdominio: si no hay un _dmarc en el nombre del De, se aplica la política del dominio organizacional. Un boletín en boletin.tudominio.cl entra en la misma decisión que el dominio pelado cuando llegue el momento de cuarentena o rechazo. La forma de leerlo y de subir la política está en la guía de reportes.

Dónde se edita el TXT

Edita la zona que de verdad responde. Si los servidores de nombre apuntan a Cloudflare, un cambio en cPanel o DirectAdmin no sale a internet. Cómo dejar el correo fuera del proxy está en la guía de Cloudflare delante del hosting.

Antes de guardar, deja el TXT actual copiado en un lugar que no sea la zona. El TTL que ya tiene el registro es el plazo que otros resolvers pueden seguir mostrando el valor viejo. Bajar el TTL hoy no acelera una copia que todavía está en caché con el plazo anterior.

cPanel

Entra a Zone Editor, abre Administrar y busca el TXT del dominio pelado que empieza con v=spf1. Usa Editar en esa fila. Añadir registro crea otro TXT: es el botón que deja dos SPF.

No instales el SPF sugerido de Email Deliverability si el aviso dice que el servidor no controla el DNS. Ese valor es de la cuenta donde lo estás mirando, y el botón no escribe en la zona real. El detalle está en correo avanzado de cPanel.

El nombre del registro del dominio pelado se ve como el dominio. El TTL de las filas de ejemplo del tutorial es 14400. Déjalo como está.

DirectAdmin

La zona está en Administración DNS. Localiza el TXT con v=spf1. AÑADIR REGISTRO crea uno nuevo: no lo uses mientras el SPF actual siga en la tabla.

Si la fila se puede editar, cambia el valor ahí. Si en tu pantalla solo puedes eliminarla, borra ese TXT y agrega enseguida el texto fusionado, con nombre @. No dejes los dos publicados. ANULAR VALOR TTL no edita la fila. La casilla de copiar el registro a los punteros se deja como viene si no tienes claro qué punteros hay.

El formulario puede mostrar v=spf1 include:ejemplo.cl ~all. Es un borrador. ejemplo.cl no autoriza a tu facturador ni al correo de Bitsur. No lo guardes encima del TXT que ya funciona.

Cloudflare

En DNS, Records, edita el TXT del dominio pelado. El nombre figura como @. El contenido es el SPF completo, en una sola línea, sin comillas de más. Un TXT no se puede proxyear: queda en Solo DNS y no hay nube que cambiar.

Si todavía no hay ningún SPF, ahí sí corresponde agregar un registro. Tipo TXT, nombre @, y el valor único. Si ya existe, edita ese. La guía de registros de correo pide los valores de tu proveedor.

Después del cambio, en cualquier panel:

dig TXT tudominio.cl +short @1.1.1.1
dig TXT tudominio.cl +short @8.8.8.8

Tiene que aparecer un solo texto que empiece con v=spf1, igual al que guardaste. Si dig parte la respuesta en varios trozos entre comillas, léelos pegados y sin espacio extra. Si sigue el valor anterior, el TTL viejo no ha vencido en ese resolver.

Cómo comprobar el envío

Un dig correcto dice que publicaste un solo registro. No dice que el facturador esté usando el sobre que autorizaste. Hacen falta dos mensajes a una casilla tuya, idealmente en Gmail, porque ahí se abre el original con un clic:

Uno desde una casilla de una persona, el mismo camino de siempre.
Uno desde la herramienta: una boleta de prueba, un aviso del CRM o un envío de prueba del boletín. El correo de la casilla no representa al facturador.

En Gmail abre el mensaje y elige Mostrar original. En Outlook, abre las cabeceras. Busca Authentication-Results. El formato está en el RFC 8601. Puede haber más de una cabecera, una por servidor que la agregó. Lee la del buzón donde recibiste el mensaje.

Este bloque es un ejemplo de lectura, no una cabecera sacada de un envío real:

Authentication-Results: mx.ejemplo;
    spf=pass [email protected];
    dkim=pass header.d=tudominio.cl;
    dmarc=pass header.from=tudominio.cl

Campo	Qué confirma
`spf=`	El resultado: `pass`, `fail`, `softfail`, `neutral`, `none`, `temperror` o `permerror`
`smtp.mailfrom`	El dominio del sobre. Es el nombre cuyo SPF se evaluó
`dkim=` y `header.d`	Si la firma verificó y con qué dominio
`dmarc=` y `header.from`	Si hubo alineación con el De

spf=pass con smtp.mailfrom en el dominio del proveedor, y dkim con header.d también en ese dominio, deja dmarc=fail aunque el De sea el tuyo. Falta la firma o el sobre en un nombre tuyo.

spf=permerror en el dominio de tus casillas, después del cambio, pide volver al TXT anterior y revisar dos registros, un include: mal escrito o más de 10 consultas. spf=softfail o spf=fail solo en el mensaje del facturador, con las casillas en pass, significa que ese sobre no está en el registro y el resto sigue autorizado.

temperror es un fallo transitorio de DNS. Se reintenta. No se corrige borrando el TXT.

La prueba por IP del comprobador de Kitterman sirve cuando ya conoces la IP de salida que documenta el proveedor. El veredicto que importa sigue siendo el de la cabecera del mensaje de prueba.

A los días, el reporte agregado DMARC muestra la source_ip de ese servicio y si policy_evaluated quedó en pass. Ahí se ve si el arreglo sobrevivió más allá de la prueba.

Lista de chequeo

Inventario escrito: casillas, facturador, CRM, boletín y formulario. Quién lo administra, qué De usa y qué día sale correo.
El TXT anterior está copiado fuera de la zona.
Hay un solo TXT que empieza con v=spf1 en ese nombre.
El include: o las IP son las que documenta el proveedor ahora.
No quedó pegado el v=spf1 ni el all del proveedor dentro del tuyo. Hay un solo all, al final.
El calificador de ese all es el que ya tenías, salvo que hayas decidido el cambio con el inventario completo.
La suma de consultas, con los include: anidados, no pasa de 10.
dig contra un resolver público muestra el texto nuevo y uno solo.
La casilla de una persona sigue en spf=pass.
El envío de prueba de la herramienta muestra spf=pass en el dominio del sobre, o dkim=pass con d= de tu dominio, y dmarc=pass si ya publicas DMARC.
Si el límite no daba, el automático salió por un subdominio y el SPF del dominio pelado no se mezcló.
El MX de las casillas quedó como estaba.

Si quieres que lo revisemos

Escríbenos con el dominio, dónde está el DNS (cPanel, DirectAdmin o Cloudflare) y la lista de herramientas que envían. No mandes contraseñas en el primer mensaje. El correo de las personas puede seguir en el correo corporativo mientras el facturador o el boletín usan un include: o un subdominio.

Si un envío de las casillas cae en spam después del cambio, separa un permerror de un filtro de contenido con la guía de correos que llegan a spam.

Preguntas frecuentes

¿Un TXT de verificación del sitio es un segundo SPF?

Si no empieza con v=spf1, el receptor lo descarta para esta comprobación. Se queda en la zona. Dos textos que sí empiezan así, aunque uno esté en mayúsculas, producen permerror.

¿Puedo dejar solo el SPF del facturador?

Las casillas dejan de estar autorizadas en el sobre del dominio. El registro único tiene que incluir a quien ya enviaba y al servicio nuevo.

¿El boletín puede salir de la casilla de todos los días?

SPF puede autorizarlo y, aun así, ser una mala idea de volumen. Una campaña no se resuelve reenviando el mismo mensaje desde la casilla del equipo. La separación está en la guía de correos a spam.

¿El cambio se ve al momento?

Lo ve de inmediato un resolver que no tenía el TXT en caché. Quien guardó el valor anterior puede seguir viéndolo durante el TTL que ese registro ya tenía. Comprueba con dig en 1.1.1.1 y en 8.8.8.8 antes de dar por cerrada la prueba de envío.

Menú

Cómo autorizar un facturador, un CRM o un boletín sin romper el SPF