"550 5.7.23 The message was rejected because of Sender Policy Framework violation" (fallo de SPF): cómo solucionarlo

Qué significa

El servidor receptor ha comprobado el registro SPF de tu dominio y ha visto que el servidor que envió el email no está autorizado a enviar en nombre de tu dominio. Con Microsoft 365 y Exchange, el rebote tiene este aspecto:

550 5.7.23 The message was rejected because of Sender Policy Framework violation

Otros servidores usan textos más cortos. El mensaje suele parecerse a uno de estos:

550 5.7.1 SPF fail - not authorized
550 5.7.1 Rejected by SPF

SPF (Sender Policy Framework) es un registro TXT en el DNS de tu dominio que enumera los servidores autorizados a enviar emails en su nombre. Cuando envía un servidor que no está en la lista, SPF «falla». Si el registro termina en -all («rechazar todo lo demás»), muchos receptores rechazan el email directamente.

Por qué ocurre

• Falta un remitente en SPF. Has empezado a usar una herramienta de newsletters, un CRM, una tienda online, una herramienta de facturación o un nuevo proveedor de email y no lo has añadido.
• La IP de tu servidor ha cambiado (nuevo hosting, nuevo VPS) y SPF sigue indicando la antigua.
• Existen dos registros SPF para el dominio. Eso no es válido, y SPF falla para todos los remitentes.
• Demasiadas consultas. SPF solo permite 10 consultas DNS (cada include:, a o mx cuenta). Por encima, SPF devuelve un error que algunos receptores tratan como un fallo.
• Reenvíos. El email se envió a una dirección que lo reenvía a Microsoft 365 o a otro buzón. El servidor que reenvía no está en tu SPF, así que la comprobación falla allí.
• Alguien está suplantando tu dominio. En ese caso, el rechazo es SPF haciendo su trabajo.

Cómo comprobarlo

1. Haz una prueba con Delivmail. Desde la misma app o servidor que provocó el rebote, envía un email a la dirección única de la página de inicio (/). El informe muestra la IP de envío, el dominio comprobado por SPF (el remitente del sobre, o Return-Path) y el resultado de SPF con su motivo.
2. Escanea tu dominio. Usa /domain-scanner para leer tu registro SPF. Te muestra si hay dos registros, un error de sintaxis o demasiadas consultas.
3. Lee las cabeceras del rebote. El rebote suele contener una línea como Received-SPF: Fail con la IP comprobada.

Cómo solucionarlo

1. Identifica el servicio que envía. El informe de Delivmail muestra la IP. La documentación del servicio indica su include SPF, por ejemplo include:spf.protection.outlook.com para Microsoft 365 o include:_spf.google.com para Google Workspace.
2. Añádelo a tu único registro SPF. Modifica el registro existente, no crees un segundo:

   v=spf1 include:spf.protection.outlook.com include:spf.newsletter-example.com ip4:203.0.113.10 -all

3. Fusiona los duplicados. Si tienes dos registros v=spf1, combínalos en uno.
4. No superes las 10 consultas. Quita los servicios que ya no usas. Sustituye a y mx por ip4: cuando conozcas la IP.
5. Plantéate ~all mientras haces pruebas. Marca a los remitentes desconocidos como sospechosos en lugar de rechazarlos. Vuelve a -all cuando todo se supere.
6. Configura también DKIM. DKIM firma el email y resiste los reenvíos. Con DKIM y DMARC configurados, los receptores dependen menos de SPF por sí solo.

Si la causa es un reenvío

Pide a la persona que reenvíe de otra forma (una regla de buzón que redirija con SRS, o que recoja el correo directamente), o asegúrate de que tus emails van firmados con DKIM para que DMARC pueda superarse igualmente.

Comprueba que está solucionado

Espera a que el cambio DNS se propague (a menudo unos minutos, hasta el TTL del registro, a veces unas horas). Usa el Escáner de dominio para confirmar que hay un único registro SPF válido y después haz una nueva prueba con Delivmail desde el mismo servicio: SPF debería mostrar pass. Por último, vuelve a enviar el email a la dirección que rebotó.