Servidor SMTP de respaldo para WordPress: sigue enviando a pesar de un error 401, 500 o de superar la cuota

Servidor SMTP de respaldo para WordPress: el problema planteado en los foros

La pregunta surge a menudo en los foros de WordPress.org: el sitio envía sus correos electrónicos a través de Mailgun, Brevo, otro proveedor o una cuenta SMTP. Un día, el envío falla. Los mensajes a veces son «401 Forbidden» o «450 4.7.1 monthly message limit exceeded». Otras veces, el proveedor simplemente responde con un error 500. Los formularios de contacto, los pedidos y las restablecimientos de contraseña dejan de enviarse.

Alguien lo resume así en el foro: el plugin de envío falla y, en lugar de recurrir a otra cosa, bloquea todo. Lo que se busca entonces es un servidor SMTP de respaldo para WordPress: una segunda ruta de envío que se utiliza cuando la primera se niega a funcionar.

Para llegar a ese punto, primero hay que saber por qué el servidor principal se niega. Solo entonces se decide si un respaldo es suficiente o si se debe corregir el error en su origen.

Leer el error antes de buscar un respaldo

Los tres errores mencionados anteriormente no tienen la misma causa, ni se solucionan de la misma manera.

Un error 401 significa que el proveedor no reconoce las credenciales: clave de API revocada o mal copiada, contraseña modificada, cuenta suspendida o dominio aún no validado en el proveedor. Un servidor de respaldo permite seguir enviando, pero hasta que no se corrija la clave, el servidor principal no volverá a funcionar.

Una cuota superada, como el «450 4.7.1 monthly message limit exceeded», proviene de tu plan en el proveedor. El servidor funciona, pero se niega a enviar más antes de que termine el período. Este es el caso en el que un segundo servidor resulta más útil, siempre que no utilice la misma cuenta y, por lo tanto, la misma cuota.

Un error 500 suele provenir del lado del proveedor y, por lo general, es temporal. El respaldo sirve entonces para no perder nada durante la caída.

En nexya, el módulo de Correo mantiene un registro de envíos. Para cada correo electrónico que no se haya enviado, muestra la causa exacta proporcionada por el servidor. Ahí es donde se puede leer el código y el mensaje, en lugar de adivinar a partir de un formulario que ya no responde.

• 401: credenciales rechazadas, se deben corregir en el proveedor o en la conexión.
• Cuota superada: límite del plan alcanzado, una segunda cuenta o un segundo proveedor toman el relevo.
• 500: error por parte del proveedor, a menudo temporal, el respaldo evita pérdidas.

Lo que hace la versión gratuita del módulo de Correo

El módulo de Correo es gratuito, al igual que el resto de nexya, y sin límite en el número de sitios. Se activa desde el panel principal (hub). Mientras esté desactivado, ninguno de sus ganchos (hooks) se ejecuta en el sitio.

Ofrece tres formas de envío: un servidor SMTP, un proveedor mediante API o una cuenta de Gmail o Microsoft 365 conectada con OAuth, sin contraseña guardada en el sitio. Un correo electrónico de prueba verifica la conexión tan pronto como se configura.

El registro de envíos indica la causa de cada fallo. Para un fallo aislado, a menudo es suficiente: se lee el error, se corrige la clave o se cambia de plan y, a continuación, se vuelve a enviar un correo electrónico de prueba.

La versión gratuita, por otro lado, no incluye un segundo servidor de envío ni alertas en caso de fallo. Este código no está presente en absoluto; forma parte de nexya Pro.

Lo que añade nexya Pro: un segundo servidor y una alerta

nexya Pro, disponible en nexya.dev, añade al módulo de Correo un segundo servidor de envío y alertas en caso de fallo. Cuando el servidor principal rechaza un correo electrónico, el envío cambia al servidor de respaldo y una alerta te avisa del problema.

Por lo tanto, el mensaje se envía de todos modos y sabes que debes revisar el servidor principal. Esto es exactamente lo que piden los temas del foro: dejar de depender de un solo proveedor y no enterarse de la caída tres días después gracias a un cliente que nunca recibió su confirmación.

nexya Pro se entrega a través de Freemius después de la compra. Toma el relevo del plugin gratuito con la misma configuración: la conexión principal ya configurada permanece en su lugar, solo hay que añadir la segunda. nexya Pro también conserva los registros durante más tiempo, lo que ayuda a detectar caídas recurrentes.

Un servidor de respaldo no reemplaza la corrección del error: mantiene el sitio en condiciones de enviar mientras tú lo solucionas.

Configuración de un servidor de envío de respaldo, paso a paso

1. 1

   Activar el módulo Mail

   En el centro de control de nexya, active el módulo Mail. Mientras esté desactivado, ninguno de sus ganchos (hooks) se ejecutará en el sitio.

   
2. 2

   Leer la causa del fallo en el registro

   Abra el registro de envío y anote el código y el mensaje del servidor: 401, cuota superada o error 500. Corrija en el origen lo que sea posible, por ejemplo, una clave de API o un dominio no validado.

   
3. 3

   Verificar la conexión principal

   Compruebe el método de envío principal (SMTP, proveedor de API, Gmail o Microsoft 365 con OAuth) y luego envíe un correo electrónico de prueba para confirmar que vuelve a funcionar.

   
4. 4

   Añadir el segundo servidor con nexya Pro

   Con nexya Pro, añada un segundo servidor de envío en otra cuenta u otro proveedor. Si el servidor principal falla, el envío cambiará a este respaldo y una alerta le avisará. Pruébelo inmediatamente con el correo electrónico de prueba.

   

Elegir correctamente el servidor de respaldo

Un respaldo solo es útil si no se cae al mismo tiempo que el servidor principal. Algunas reglas sencillas ayudan a elegirlo.

Usa otra cuenta o, mejor aún, otro proveedor. Dos conexiones en la misma cuenta comparten la misma cuota y las mismas credenciales: una cuota superada o una clave revocada bloquea ambas.

Varía el método si puedes. Por ejemplo, una API como principal y una cuenta de Gmail o Microsoft 365 conectada con OAuth como respaldo, o un SMTP con tu proveedor de hosting. Los tres métodos del módulo de Correo se pueden utilizar en cualquiera de los dos roles.

Verifica la dirección de envío. El servidor de respaldo debe tener permiso para enviar en nombre de tu dominio. De lo contrario, los correos electrónicos se enviarán pero correrán el riesgo de llegar a la carpeta de correo no deseado. El módulo no verifica los registros SPF, DKIM o DMARC: esto debe comprobarse con el proveedor y en la zona DNS del dominio.

Por último, prueba el respaldo una vez configurado, utilizando el correo electrónico de prueba, sin esperar a la próxima caída.

• Una cuenta o un proveedor diferente al principal.
• Un método diferente si es posible: API, SMTP u OAuth.
• Un dominio de envío autorizado en el proveedor de respaldo.
• Un correo electrónico de prueba enviado en cuanto se realiza la configuración.

Lo que nexya aún no hace

Existe una limitación directamente relacionada con este caso: no se puede desactivar una conexión sin eliminarla. Si quiere apartar el servidor principal temporalmente mientras soluciona un problema con la clave, debe borrarlo y volver a configurarlo después. Por lo tanto, antes de eliminar una conexión, anote su configuración: host, puerto, usuario, clave o cuenta conectada.

Los datos conocidos del módulo tampoco describen una conmutación por error automática a la función mail() de PHP. El respaldo previsto es un segundo servidor que usted mismo configura en nexya Pro.

El módulo tampoco incluye un botón para reenviar un correo electrónico fallido. El registro indica qué no se envió y por qué. El reenvío se realiza desde la herramienta original, por ejemplo, volviendo a procesar la solicitud recibida a través de un formulario.