Tienes un filtro delante del correo. Tu SPF no va donde crees.
Si tu MX apunta a Proofpoint, Cisco, Hornetsecurity o similar, el correo entra por ahí. Pero el SPF habla de por dónde sale, y casi nunca es el mismo sitio. Confundirlo es el fallo que más veces hemos visto en esta configuración.
Aquí no hay un valor para copiar, y es a propósito. El include correcto depende de tu contrato con la pasarela y no se puede ver desde fuera. Lo que sí podemos darte es cómo saber cuál tienes, qué preguntar y en qué orden tocarlo.
1. Averigua cuál tienes: te lo dice tu propio MX
El registro MX de tu dominio es público. Su nombre lleva la huella del filtro que tienes contratado:
| Pasarela | Huella en el MX | Dominios |
|---|---|---|
| Proofpoint También ppe-hosted.com en Proofpoint Essentials. | pphosted.com | 68 |
| Cisco Secure Email Antes IronPort. El MX suele acabar en .iphmx.com. | iphmx.com | 33 |
| Trend Micro Email Security En Europa el MX va bajo .trendmicro.eu, no .com. | trendmicro.eu | 33 |
| Hornetsecurity También el antiguo antispameurope.com. | hornetsecurity.com | 31 |
| Iberlayer (Email Guardian) Española. Huella observada en nuestra muestra, no lista oficial. | iberlayer.com | 9 |
| Mimecast | mimecast.com | 5 |
| Heimdal | heimdalsecurity.com | 5 |
| Symantec / Broadcom Email Security.cloud Antes MessageLabs. | messagelabs.com | 4 |
| Barracuda Suele ir bajo ess.barracudanetworks.com. | barracudanetworks.com | 3 |
| SpamTitan (TitanHQ) | spamtitan.com | 3 |
| SpamExperts / N-able Mail Assure | mailspamprotection.com | 3 |
| SpamCluster | spamcluster.com | 3 |
Medido por nosotros en 200 dominios españoles de energía y sanidad con pasarela detectada. Que tu MX no se parezca a ninguno no
descarta que tengas pasarela: hay appliances con el nombre de tu propia empresa
(correo-seguro.tuempresa.es) e integraciones que filtran sin tocar el MX. Si
no coincide ninguna, mira las cabeceras de un mensaje recibido, los conectores de tu buzón
y el contrato. Y si de verdad no hay filtro, tu guía es la de tu proveedor:
las tienes todas aquí.
2. El error que hay que no cometer
El MX es la entrada. El SPF es la salida.
Una pasarela recibe tu correo, lo filtra y lo entrega en tu buzón real (normalmente Microsoft 365 o Google Workspace). Eso es entrada. Cuando tu gente escribe, el mensaje sale del buzón real — y a veces también de la pasarela, si esta manda avisos o reenvía en tu nombre.
La regla no es «pon los dos». Es más concreta: autoriza solo lo que entrega
directamente a Internet usando un remitente de sobre (MAIL FROM) de tu
dominio. Si todo tu correo sale por la pasarela, el include de tu buzón puede sobrar;
si el buzón también sale directo, tiene que seguir. Y si la pasarela solo filtra la
entrada, no se añade por eso.
No retires una fuente hasta demostrar que ya no existe ese camino: compruébalo en las cabeceras de mensajes reales recibidos fuera de la empresa, y con tu proveedor.
Cuidado con el límite de diez
Durante una evaluación de SPF pueden procesarse como máximo diez términos que
requieren DNS (include, a, mx,
exists, redirect), contando los que arrastran los includes de
forma recursiva. Buzón + pasarela + facturación + boletines se juntan enseguida.
Pasado el límite el resultado es permerror, no «sin SPF»: hay receptores
que lo penalizan o lo rechazan. Y hay que integrarlo en el único registro
v=spf1 del dominio y antes del all final — un segundo
registro SPF da permerror, y lo que va detrás de all no se
evalúa nunca.
3. Qué preguntarle a tu proveedor
- ¿Vuestra plataforma entrega a Internet con un
MAIL FROMde mi dominio, o solo recibe y entrega en mi buzón? - Si entrega: ¿cuál es el include exacto que debo integrar en mi SPF?
- ¿Firmáis con DKIM y con qué
d=y qué selector? ¿Rompéis la firma anterior al añadir pies o reescribir enlaces? ¿Selláis con ARC? - En los reenvíos, ¿reescribís el
MAIL FROMcon SRS y a qué dominio queda? - Y a mi proveedor de buzón: conector de entrada, filtrado mejorado (o equivalente) para que evalúe al emisor original y no a la pasarela, confianza en ARC, TLS, y bloqueo de la entrega directa que se salte el filtro.
La quinta es la que más se olvida y no se deduce del DNS: si el buzón evalúa el SPF contra la IP de la pasarela en vez de contra el emisor de verdad, salen falsos positivos que nadie entiende.
4. El orden que no corta correo
- Si aún no tienes DMARC, empieza en
p=nonecon dirección de informes. No pide al receptor que cambie nada — aunque no garantiza la entrega: cada receptor aplica además sus propias reglas. Y si tu dominio ya está enquarantineorejecty funciona, no lo bajes. - Usa los informes como fuente parcial: solo reportan los receptores que participan, llegan agregados y con retraso, y un envío estacional puede tardar semanas en aparecer. Contrástalos con tu inventario, los logs de la pasarela y los rebotes. No autorices una IP solo porque aparece, ni retires una fuente solo porque no aparece.
- Comprueba el alineamiento, que es lo que de verdad decide DMARC. En un mensaje
recibido fuera de la empresa, mira tres cosas: el dominio del
From:, el dominio delReturn-Pathque pasa SPF y eld=de la firma DKIM que pasa. DMARC solo pasa si al menos uno de los dos autenticados está alineado con elFrom:. Una firma válida de la pasarela no vale si tuFrom:es tu dominio y eld=es el suyo. - Sube a
p=quarantinecuando lo legítimo pase alineado. - El rechazo no es un destino automático. El RFC vigente desaconseja
p=rejecten dominios cuyos usuarios participan en listas de correo, porque los reenvíos rompen la autenticación. Si decides adoptarlo, que todos los flujos lleven DKIM alineado y no dependas solo de SPF. Como orientación, un mes en cada fase — y más si tienes envíos estacionales.
Compruébalo aquí mismo
Antes o después de tocar el DNS: escribe tu dominio y mira qué se ve desde fuera. Sin registro, sin tocar tus sistemas y sin salir de esta página.
¿Prefieres no tocar el DNS tú?
Lo delicado no son los tres registros: es descubrir todos los sistemas que envían en tu nombre (facturación, CRM, marketing) y llegar a rechazo sin cortar correo legítimo. ALTRUIA Escudo lo hace por fases y te deja el expediente por escrito. Dinos tu dominio y te decimos si merece la pena en tu caso.
Preguntas frecuentes
¿El MX me dice cuál es mi SPF?
No. El MX dice por dónde ENTRA el correo y el SPF por dónde SALE. Con una pasarela delante son dos caminos distintos, y confundirlos es el fallo más repetido: se publica el include del filtro, se quita el del buzón real y el correo legítimo empieza a caer.
¿Pongo el include de la pasarela, el del buzón, o los dos?
Los que entreguen a Internet con un remitente de sobre de tu dominio. Si todo sale por la pasarela, el del buzón puede sobrar; si el buzón también sale directo, tiene que seguir. Compruébalo en cabeceras de mensajes reales antes de quitar nada, e intégralo en el único registro v=spf1, antes del all.
¿Por qué no dais aquí el valor exacto?
Porque depende de tu contrato con la pasarela y no se puede ver desde fuera. Dar un valor inventado sería peor que no dar ninguno: quien lo pegara se quedaría con un SPF que no autoriza a su propio correo.
¿Se me puede romper el correo?
Por eso se empieza siempre con DMARC en p=none: observas los informes sin cortar nada. Cuando confirmes que todo lo legítimo pasa, subes a p=quarantine y después a p=reject.