Gestiono varios sitios WordPress. En cada uno sale un número de emails que nadie imagina: notificaciones de contacto, restablecimientos de contraseña, confirmaciones de pedido, avisos a los gestores. El registro de correo WordPress de FluentSMTP es la herramienta que reviso en cuanto un cliente me escribe «no he recibido nada». Antes miraba los logs del servidor SMTP por línea de comandos. Tenía que hacer coincidir a mano grep y timestamps. Ahora abro una página del panel de WordPress y lo tengo todo delante.
Por qué reviso el registro de correo WordPress antes que los logs del servidor
El caso típico es siempre el mismo. Un formulario de contacto que «no llega». Un cliente que no recibe el email de restablecimiento de contraseña. Un pedido que se queda sin confirmación. Sin un log a mano, la primera hipótesis es la carpeta de spam. Luego los logs del servidor SMTP. Luego quizá el firewall. Con FluentSMTP me salto esos pasos. Veo enseguida si WordPress realmente intentó enviar ese email. A quién, cuándo, con qué respuesta del servidor de envío.
FluentSMTP registra cada llamada a wp_mail(). No solo los emails de plugins de terceros, también los que genera el núcleo: notificaciones de nuevo usuario, avisos de actualización, alertas de error. Para cada envío el log muestra remitente, destinatario, asunto, cabeceras completas, cuerpo del mensaje. Y la respuesta del proveedor SMTP o de la API usada. Si un email ha fallado, esa respuesta del servidor está ahí. No tengo que adivinarla.
Qué encuentro realmente en el registro de envíos
El plugin soporta decenas de conectores: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. También Google Workspace y Microsoft 365 vía OAuth, además del clásico SMTP genérico. En los sitios que gestiono uso casi siempre SMTP autenticado con el dominio del cliente. Alguna vez una API dedicada, cuando el volumen de emails crece. En ambos casos el registro de correo WordPress no cambia. Cada línea tiene un estado, enviado o fallido. Hay un botón para revisar el contenido o reenviar el mensaje, sin que el usuario tenga que repetir la acción que lo generó.
El reenvío manual es la función que más uso. Un formulario rellenado dos veces porque «no llegaba» se convierte en un clic sobre el log. No un nuevo aviso al cliente. Para los fallos repetidos he activado las notificaciones en Telegram. En cuanto una conexión deja de funcionar, lo sé antes de que me lo escriba alguien. En vez de descubrirlo por un ticket de soporte.
El log no se limita a las notificaciones dirigidas a mí o al cliente que administra el sitio. Ahí acaba también cada email de salida generado por el sitio hacia terceros: la confirmación de pedido que una tienda online envía al cliente final, el recibo de un pago, el aviso de envío. Si esa confirmación no llega, la veo en el registro de correo WordPress exactamente como una notificación interna. Tiene el mismo botón para reenviarla al destinatario correcto, sin hacerle repetir la compra.
Cómo configuro FluentSMTP en los sitios que gestiono
Después de conectar el conector adecuado, cambio la conservación del log. Por defecto se mantiene activo mucho tiempo. Yo la llevo a 30-60 días, según el tráfico del sitio. Sirve para rastrear un problema señalado con retraso. Sin llenar la base de datos de líneas que nunca consultaré. Luego activo al menos un canal de notificación para los fallos, Telegram o Slack según el cliente. El log solo no avisa a nadie: hay que abrirlo para leerlo.
En los sitios con formulario de contacto uso también Cisilino Site Defense Network para el bloqueo de bots. Menos spam entrante significa menos emails generados por los formularios. El log queda más legible, con menos ruido que filtrar cuando busco el mensaje correcto.
Las credenciales SMTP no quedan en claro en la base de datos
Un detalle que compruebo siempre antes de guardar una conexión: dónde acaban las credenciales. FluentSMTP las cifra por defecto con las claves SALT de WordPress, las mismas presentes en wp-config.php para la seguridad de las sesiones. Se puede desactivar el cifrado, pero el propio plugin lo marca como no recomendado. En los sitios que gestiono prefiero otra opción: guardar la contraseña de la API o del SMTP directamente en wp-config.php, fuera de la base de datos. Defino las constantes antes de que el plugin las lea. Así, ni un volcado de la base de datos ni un acceso no autorizado al panel expone la clave del proveedor de envío. Es el mismo principio que aplico en otros sitios: menos secretos en la base de datos, mejor.
Varias conexiones a la vez, no solo una
FluentSMTP permite configurar varias conexiones a la vez, no solo una. En un sitio configuro la predeterminada y añado una segunda como reserva: si el primer proveedor no responde, el envío pasa automáticamente a la conexión de reserva, sin que yo tenga que intervenir. La elección de la conexión depende de la dirección del remitente. Cada conexión tiene su «From». El resto pasa por la predeterminada, con la reserva lista solo si la predeterminada falla de verdad: un error del proveedor, no un email que acabó en spam. Es una de las razones por las que lo prefiero a un único SMTP sin alternativas. Si SendGrid o Amazon SES tienen un problema durante unas horas, el sitio sigue enviando de todas formas, y lo veo enseguida en el registro de correo WordPress. Todo incluido en la versión gratuita, sin una versión pro de pago: solo se paga el proveedor de envío elegido, no el plugin.
Un chequeo de salud cada día, no solo cuando algo se rompe
Además del log línea por línea, FluentSMTP hace un chequeo de salud de la conexión cada día, de forma automática. Si el proveedor deja de responder, el aviso llega antes de que un cliente me escriba «el sitio ya no envía emails». El mismo panel muestra un gráfico con los totales diarios de envíos correctos y fallidos. Es útil para entender de un vistazo si una caída es normal o es el síntoma de algo que se está rompiendo, sin abrir el registro de correo WordPress línea por línea cada vez. También hay un resumen periódico por email, con los totales de la semana. No es un aviso de error, es un boletín que leo de pasada para saber si el volumen de envíos está dentro de lo normal.
Para quien, como yo, gestiona varios sitios desde la línea de comandos, FluentSMTP también expone comandos WP-CLI. Hay una prueba de envío, un chequeo de salud de la conexión, las estadísticas y la limpieza de los logs antiguos. Los uso en los mismos scripts que ya corren en los servidores para otros controles de mantenimiento, sin abrir el panel de cada sitio uno por uno.
Los límites honestos del registro de correo WordPress
No es una solución mágica. La conservación se basa en los días, no en un número máximo de líneas. En un sitio con mucho tráfico transaccional la tabla del log puede crecer rápido. Conviene tenerla controlada, o fijar una conservación más corta. Las notificaciones de fallo llegan solo por los canales de chat configurados, no por email. Tiene sentido: un email que avisa de un email fallido corre el riesgo de fallar también. Pero hay que saberlo de antemano.
Por último, el log registra lo que ha pasado por el lado de WordPress y por el lado del proveedor. No garantiza la entrega en la bandeja del destinatario. Si un email aparece como enviado pero acaba en spam, es un problema de reputación del dominio o de configuración SPF/DKIM. No algo que un log pueda resolver por sí solo. Sigue siendo, aun así, el primer sitio donde miro, antes de cualquier otra comprobación.
El plugin es gratuito y de código abierto. Página oficial en wordpress.org, sin funciones bloqueadas detrás de una versión pro. Para quien gestiona aunque sea un solo sitio con un formulario de contacto, vale la pena instalarlo solo por el registro de correo WordPress. La primera vez que resuelve un «no he recibido el email» en un minuto en vez de en media hora, ya se ha pagado solo.
Deja una respuesta