Cómo distinguir un fallo temporal de DNS de un error de SPF
La pista inicial está en el resultado SPF del mensaje recibido: temperror apunta a un problema transitorio de consulta y permerror a una evaluación que no puede completarse por la configuración.
Equipo enginerIT· 2 min de lectura
La pista inicial está en el resultado SPF del mensaje recibido: temperror apunta a un problema transitorio de consulta y permerror a una evaluación que no puede completarse por la configuración. Un fail significa otra cosa: la dirección de origen no queda autorizada. Conserva el resultado completo antes de tocar el DNS.
Empieza por una entrega concreta
Pide al destinatario las cabeceras del mensaje afectado o el diagnóstico del rechazo. Anota fecha con zona horaria, dominio evaluado, resultado SPF y servidor que lo emitió. El nombre visible del remitente no basta para identificar el dominio consultado. Trabaja con el dominio del sobre SMTP que figure en la evaluación, que puede diferir del que aparece en De.
Recoge además una entrega correcta del mismo sistema emisor. Comparar mensajes de aplicaciones distintas puede llevarte a atribuir al DNS un fallo que solo afecta a una ruta de envío.
Elige la comprobación según el resultado
Ante temperror, revisa disponibilidad y respuesta del DNS autoritativo con quien lo administra. Repite la consulta y una entrega de prueba en otro momento, guardando ambos resultados. Que una consulta funcione ahora no demuestra que funcionara cuando se recibió el mensaje. Evita sustituir el SPF mientras aún investigas una caída temporal.
Ante permerror, revisa el registro publicado: sintaxis, duplicidades y cadena de consultas. Microsoft señala el exceso de diez búsquedas DNS como una causa. No cuentes solo los mecanismos include visibles: su contenido también puede ampliar las consultas. Si aparece fail, contrasta la IP emisora real con las fuentes que la empresa ha autorizado.
Cierra el caso con una prueba comparable
Pide al propietario del sistema de envío que confirme la ruta y las fuentes legítimas antes de modificar autorizaciones. Si corriges el registro, conserva su versión anterior y cambia una causa cada vez. Envía desde la aplicación afectada a un destinatario externo de prueba y revisa las cabeceras nuevas.
Documenta si el resultado cambió y qué sigue sin explicar. Un SPF correcto no acredita que el contenido sea seguro ni resuelve por sí solo toda la autenticación del dominio. Si el fallo solo ocurre tras un reenvío, investiga ese recorrido antes de ampliar el SPF.
Comprobaciones para cerrar la tarea
- ✓ Guardar el resultado SPF literal y el dominio evaluado.
- ✓ Comparar una entrega fallida y otra correcta de la misma aplicación.
- ✓ Confirmar el diagnóstico con un mensaje posterior al cambio.
Fuentes y documentación
- Diagnóstico de autenticación en Microsoft 365 — Diferencia entre temperror, permerror y fallos de autenticación.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →