Zendesk activa el perfil Minimal: un SPF fallido puede bloquear tus mensajes al soporte
Por CaptainDNS
Publicado el 30 de septiembre de 2026
Actualizado el 30 de septiembre de 2026
Escribiste al soporte de un proveedor de software y sigues esperando respuesta. Desde el 23 de septiembre de 2026, puede que tu mensaje haya acabado fuera de la cola de tickets. Zendesk está pasando al perfil «Minimal» las cuentas que no tenían activado ningún control del remitente. Con este perfil, un SPF fallido sin DKIM válido basta para que un email nunca se convierta en ticket.
- Desde el 23 de septiembre de 2026, las cuentas de Zendesk con la autenticación de remitentes desactivada pasan de forma progresiva al perfil «Minimal».
- Con este perfil, un SPF fallido es peor que un SPF ausente: sin DKIM válido, el primero envía el email a los tickets suspendidos y el segundo lo deja pasar con una marca.
- Revisa el SPF y la firma DKIM de tu dominio. Si administras Zendesk, vigila la vista «Suspended tickets».
Qué cambia con el perfil Minimal por defecto
El 18 de junio de 2026, Zendesk anunció una nueva norma de seguridad para la autenticación de remitentes. El anuncio oficial, actualizado el 28 de septiembre de 2026, describe un despliegue en dos fases.
La fase 1 afecta a las cuentas nuevas. Ya se crean con el perfil «Minimal» por defecto. La fase 2 se dirige a las cuentas existentes que tienen desactivada la autenticación de remitentes: Zendesk les aplica «Minimal» como perfil por defecto.
El calendario de esta fase 2 muestra dos fechas de fin en la misma página. La tabla indica un inicio el 23 de septiembre de 2026 y un fin el 22 de octubre de 2026. El texto, en cambio, habla de un despliegue progresivo del 23 de septiembre al 16 de diciembre de 2026. Citamos las dos, porque la página oficial no dice cuál prevalece. Una cuenta que hoy sigue desactivada puede, por tanto, cambiar de perfil en las próximas semanas, sin fecha precisa.
La administración de la cuenta mantiene el control. Puede desactivar la autenticación o elegir un perfil más estricto: «Native traffic» o «Native and forwarded traffic (ARC)». Hay una regla que no cambia: para los emails que envían los agentes, la autenticación está siempre activa y no se puede desactivar.
Suspendido, marcado o aceptado: los tres resultados
La documentación de Zendesk sobre la autenticación del correo entrante presenta «Minimal» como el perfil menos estricto. Combina dos resultados. El SPF comprueba que el servidor que envía el mensaje figura en la lista publicada por el dominio del remitente. El DKIM comprueba una firma criptográfica añadida en el envío.
| Resultado SPF | Resultado DKIM | Resultado en Zendesk |
|---|---|---|
| Fallido | Ausente o fallido | Suspendido: vista «Suspended tickets», causa «Email authentication failed» |
| No configurado para el dominio remitente | Fallido | Aceptado, marcado como «Potential spoofing» (posible suplantación) |
| Todos los demás casos | Todos los demás casos | Aceptado |
Un mensaje suspendido no se convierte en ticket. Se queda en la vista «Suspended tickets» (tickets suspendidos), con la causa «Email authentication failed» (fallo en la autenticación del email). Ningún agente lo verá en su cola habitual.
La segunda fila merece una pausa. Un dominio que no publica ningún SPF, con una firma DKIM fallida, pasa de todos modos. El agente ve un aviso, pero recibe el ticket.
Por qué un SPF fallido es peor que un SPF ausente
Mira la situación desde el lado del cliente, no del proveedor. Escribes desde tu dominio al soporte de un software que funciona con Zendesk. Tu dominio publica un SPF, pero el servidor que entregó tu mensaje no aparece en él: un nuevo proveedor de envío que nadie añadió, un include borrado por error. El SPF falla. Si tu mensaje no lleva una firma DKIM válida, Zendesk lo suspende. Tú esperas una respuesta; el proveedor, por su parte, no tiene ningún ticket que atender.
El mismo mensaje, enviado desde un dominio sin SPF y con el mismo DKIM fallido, habría llegado con la marca «Potential spoofing». Con este perfil, un SPF fallido pesa más que un SPF ausente.
No saques la conclusión de que debes retirar tu SPF. Sin él, tu dominio es más fácil de suplantar, y DMARC pierde uno de los dos mecanismos en los que se apoya. La respuesta correcta es reparar el SPF y firmar tus mensajes con DKIM. En el perfil «Minimal», un DKIM válido basta para evitar la suspensión, aunque el SPF falle.
Los reenvíos hacen este punto todavía más concreto. Muchos proveedores publican una dirección de soporte en su propio dominio y luego la reenvían a Zendesk. El servidor que entrega tu mensaje a Zendesk ya no es el tuyo, y tu SPF falla a menudo sin que tu registro tenga la culpa. La firma DKIM, en cambio, sigue siendo válida mientras el relay no modifique el mensaje. Es ella la que lleva el mensaje hasta el ticket.
Qué revisar, primero como remitente y luego como administrador de Zendesk
Como remitente, empieza por el SPF. Haz la lista de los servicios que envían email con tu dominio: servicio de correo, CRM, facturación, herramienta de campañas de email. Cada uno debe estar autorizado por tu registro. El verificador SPF de CaptainDNS lee el registro publicado, resuelve los include y comprueba si una dirección IP concreta está autorizada.
Después, comprueba que cada flujo saliente lleva una firma DKIM válida, hecha con tu dominio y no solo con el del proveedor. La firma alineada con tu dominio es la que DMARC tiene en cuenta. Si un mensaje reciente a un soporte se quedó sin respuesta, haz estas dos comprobaciones antes de reenviarlo: un nuevo envío en las mismas condiciones correrá la misma suerte.
Del lado de la administración de Zendesk, la consigna del proveedor cabe en una frase: «Monitor your Suspended tickets view regularly», es decir, vigila con regularidad la vista de tickets suspendidos. Zendesk añade que los problemas de spam se resuelven en el origen («Spam issues must be resolved at the source»). Un cliente legítimo que aparece en esta vista con la causa «Email authentication failed» no tiene por qué ser el culpable: quizá deba corregir su SPF o su DKIM, pero un reenvío también puede romper su SPF. Revisa primero tus propias redirecciones y, si tiene que corregir su dominio, avísale por otro canal.
Si tu dirección de soporte es un alias reenviado a Zendesk, mira también el perfil «Native and forwarded traffic (ARC)». Es más estricto que «Minimal», pero se apoya en ARC, un mecanismo que conserva los resultados de autenticación de un relay a otro.
Comprueba la firma DKIM de tu dominio
Un DKIM válido evita la suspensión incluso cuando el SPF falla. Prueba cada selector que usan tus servicios de envío.
Lo que este artículo no es
Esta entrada no detalla las reglas que Gmail impone a los remitentes: nuestro artículo sobre el endurecimiento de las reglas de envío de Gmail de noviembre de 2025 las trata aparte.
Tampoco es una guía de resolución de problemas de SPF. Para un error de sintaxis, un mecanismo mal escrito o la superación de las 10 consultas DNS, lee la guía de SPF PermError. Las firmas fallidas tienen su propio artículo: DKIM fail: todas las causas y cómo corregirlas.
Por último, esta entrada no compara las herramientas de soporte del mercado. Se ciñe a Zendesk y a su perfil «Minimal», según las dos páginas oficiales citadas más abajo.
FAQ
Mi email al soporte en Zendesk no tuvo respuesta, ¿lo suspendieron?
Es posible si el SPF de tu dominio falló y tu mensaje no tenía un DKIM válido. En ese caso está en la vista «Suspended tickets» del proveedor, con la causa «Email authentication failed». Revisa tu SPF y tu DKIM y luego contacta con el proveedor por otro canal.
¿Por qué un SPF fallido bloquea y un SPF ausente pasa?
En el perfil «Minimal», Zendesk suspende un email cuando el SPF falla y el DKIM está ausente o falla. Si el dominio no tiene SPF configurado y el DKIM falla, el email se acepta con la marca «Potential spoofing». Repara tu SPF en lugar de eliminarlo.
¿Cuándo pasará mi cuenta de Zendesk a Minimal?
Las cuentas nuevas ya lo tienen. Para las cuentas existentes con la autenticación desactivada, la página oficial indica un inicio el 23 de septiembre de 2026, con un fin el 22 de octubre de 2026 en su tabla y el 16 de diciembre de 2026 en su texto. Zendesk no precisa cuál prevalece.
¿Cómo evito la suspensión cuando un email se reenvía?
Firma tus mensajes con un DKIM válido y alineado con tu dominio: sigue siendo válido si el relay no modifica el mensaje, mientras que el SPF suele fallar tras un reenvío. Del lado de la administración, el perfil «Native and forwarded traffic (ARC)» tiene en cuenta los mensajes reenviados.
Fuentes: anuncio de Zendesk sobre la nueva norma de autenticación de remitentes y documentación de Zendesk sobre la autenticación del correo entrante (SPF, DKIM, DMARC y ARC).
