Los registros MX indican a otros servidores dónde entregar correo entrante para un dominio. No configuran WordPress para autenticar en SMTP, no autorizan From ni garantizan que el formulario haya generado una notificación.
Mantén intacto el routing entrante correcto y rastrea la salida por separado.
Dibuja las dos rutas
El correo empresarial entrante viaja desde el emisor hasta el proveedor MX del dominio. Una notificación WordPress sale de la web por PHP, SMTP o API y después llega al gateway del destinatario.
Anota transporte activo, From, destinatario y hora de una prueba. No supongas que el proveedor que recibe el correo de empleados también envía el de la web.
Confirma primero que el formulario guardó la entrada.
Verifica la generación
Revisa avisos habilitados, condiciones y tokens de destinatario en el formulario activo. Si no hay evento en el mail log, el fallo existe antes de consultar cualquier MX.
Usa una dirección autorizada fija en From y al visitante en Reply-To. Valida los destinatarios y que la página use el ID que editas.
Una prueba SMTP genérica no demuestra que se ejecutara el aviso real.
Identifica el transporte saliente
WordPress puede usar PHP mail local, relay del hosting, SMTP autenticado o API. Encuentra la configuración activa y busca por la hora.
Si PHP aceptó el mensaje, consulta cola y respuesta del hosting. Si usa SMTP, verifica hostname, puerto, TLS y propiedad de la credencial.
No cambies los MX del destinatario para reparar la conexión entre WordPress y su proveedor.
Comprueba el routing local
cPanel o Plesk pueden tratar el dominio como local aunque los MX apunten a Microsoft 365, Google Workspace u otro servicio. Los mensajes hacia el mismo dominio acabarían en un buzón local inexistente sin consultar el DNS público.
Compara local/remote exchanger con el diseño real. Cambia solo después de confirmar que ningún buzón legítimo depende del servidor.
Prueba la resolución desde el propio hosting además de un resolver público. Un resolver local, una zona privada o /etc/hosts puede devolver un destino distinto aunque las herramientas externas muestren MX correctos.
Conserva una reversión, porque un error también puede afectar la entrada.
Autentica al remitente
SPF autoriza la infraestructura del envelope sender, DKIM firma y DMARC comprueba alineación con From. Un MX correcto no crea ninguno.
Publica los registros del emisor actual en DNS autoritativo. Mantén una política SPF y el selector DKIM exacto. Completa la verificación del proveedor.
Inspecciona Authentication-Results en una copia real, no solo un indicador verde del panel.
Sigue proveedor y receptor
Busca aceptación, aplazamiento, rebote o supresión en el emisor. Tras la aceptación, el gateway elegido por los MX asume la entrega o devuelve el resultado.
Conserva la respuesta SMTP por destinatario. Un código 250 del receptor prueba aceptación en ese salto; un aplazamiento 4xx o rechazo 5xx identifica una política remota, no un problema del MX publicado.
Pide al administrador autorizado revisar cuarentena, reglas, alias y restricciones por message ID.
La carpeta Spam es solo uno de los posibles destinos.
Evita cambios DNS sin relación
No alteres prioridades MX, añadas el servidor web como MX ni apuntes correo a la IP del sitio salvo que la arquitectura lo exija. Podrías interrumpir el email empresarial sin reparar el formulario.
El registro A, SSL web y proxy de Cloudflare también son distintos de la autenticación saliente, excepto si WordPress conecta a un hostname SMTP personalizado.
Cambia únicamente el primer traspaso fallido demostrado.
Verifica ambas funciones
Tras reparar, envía un formulario identificado y confirma entrada, notificación, aceptación y llegada. Envía después una prueba entrante al buzón corporativo para demostrar que los MX siguen bien.
Inspecciona Reply-To y SPF/DKIM/DMARC. Revisa entradas guardadas durante el fallo.
Solicita ayuda urgente cuando el routing local contradiga los MX o se desconozca el proveedor saliente. Comparte DNS público, horas y resultados de cola redactados, nunca credenciales o contenido.