{"id":21891,"date":"2026-10-11T17:50:27","date_gmt":"2026-10-11T09:50:27","guid":{"rendered":"https:\/\/synopower.club\/?post_type=docs&p=21891"},"modified":"2026-10-11T18:06:54","modified_gmt":"2026-10-11T10:06:54","password":"","slug":"synology-mailplus-smtp-relay-resend","status":"publish","type":"docs","link":"https:\/\/synopower.club\/es\/docs\/synology-mailplus-smtp-relay-resend\/","title":{"rendered":"Synology MailPlus SMTP Relay: Soluci\u00f3n de problemas de correo rechazado mediante reenv\u00edo."},"content":{"rendered":"

Un rel\u00e9 SMTP es un segundo servidor de correo que env\u00eda sus mensajes en su nombre, de modo que el receptor juzga su reputaci\u00f3n en lugar de la suya. El 9 de octubre de 2026 necesit\u00e1bamos uno con urgencia. SynoPower Club funciona completamente en Synology, y cada confirmaci\u00f3n de pedido y clave de licencia sale a trav\u00e9s de Synology MailPlus. Esa noche, un cliente en B\u00e9lgica pag\u00f3 una licencia, y el correo electr\u00f3nico que conten\u00eda la clave regres\u00f3 directamente con 552 5.2.0 Su mensaje se considera spam.<\/code>. SPF, DKIM y DMARC funcionaban correctamente. Este art\u00edculo de NAS Hosting 101 muestra c\u00f3mo agregamos Resend como rel\u00e9 SMTP solo para los dominios de destinatarios que nos rechazan, qu\u00e9 registros necesita, c\u00f3mo lo probamos y qu\u00e9 cambios realiza el servicio discretamente en sus mensajes.<\/p>\n\n\n\n

\n

Punto SynoPower Club:<\/strong> Pas\u00e9 a\u00f1os trabajando en el soporte t\u00e9cnico de Synology, y la tasa de entrega era el principal motivo por el que la mayor\u00eda de la gente abandonaba la gesti\u00f3n de su propio correo. Daban por hecho que la soluci\u00f3n era trasladar todos los buzones a un servidor virtual. Rara vez es as\u00ed. En nuestro caso, el servidor de correo funcionaba correctamente, el DNS era correcto y solo un salto en la ruta de salida ten\u00eda un nombre de dominio deficiente con algunos proveedores estrictos. Synology MailPlus permite modificar ese \u00fanico salto \u00fanicamente para esos proveedores, con una regla que nos llev\u00f3 diez minutos crear. Los buzones, los registros y los datos de los clientes nunca salieron de nuestro propio NAS.<\/p>\n<\/blockquote>\n\n\n\n

\u00bfPor qu\u00e9 se siguen rechazando los correos electr\u00f3nicos firmados correctamente desde un NAS?<\/h2>\n\n\n\n

La autenticaci\u00f3n demuestra qui\u00e9n eres, pero no garantiza tu bienvenida. SPF, DKIM y DMARC le indican al servidor receptor que un mensaje proviene realmente de tu dominio, y luego el servidor formula una segunda pregunta: \u00bfqu\u00e9 ha visto anteriormente de la direcci\u00f3n IP que env\u00eda el mensaje?<\/p>\n\n\n\n

Un servidor de correo autogestionado suele perder esa segunda pregunta de dos maneras. Si env\u00eda directamente, la IP p\u00fablica a menudo lleva un nombre DNS inverso gen\u00e9rico del proveedor de internet, que muchos destinatarios interpretan como una conexi\u00f3n dom\u00e9stica. Si, en cambio, env\u00eda a trav\u00e9s del servidor de salida del proveedor, como hac\u00eda el nuestro, el mensaje hereda la reputaci\u00f3n de una m\u00e1quina compartida con miles de otros clientes.<\/p>\n\n\n\n

\"Mensaje
El correo rebot\u00f3 al llegar a nuestro buz\u00f3n de soporte el 9 de octubre, con la direcci\u00f3n del cliente y la de nuestro servidor ocultas. El rechazo provino del propio servidor de correo del proveedor durante la entrega.<\/figcaption><\/figure>\n\n\n\n

Esa era nuestra situaci\u00f3n. El error no se refer\u00eda a nuestro dominio ni a nuestra firma. Se trataba de un fallo en la ruta de env\u00edo, y los grandes proveedores de correo electr\u00f3nico europeos, como Telenet y GMX, son conocidos por su estricto filtrado de esa se\u00f1al. Nada dentro del servidor de correo pod\u00eda cambiarlo, porque el problema se encontraba un salto despu\u00e9s del NAS.<\/p>\n\n\n\n

Qu\u00e9 cambia y qu\u00e9 no cambia un rel\u00e9 SMTP<\/h2>\n\n\n\n

Un rel\u00e9 SMTP reemplaza ese \u00faltimo salto. Su servidor se autentica en \u00e9l a trav\u00e9s del puerto 587, le entrega el mensaje y el rel\u00e9 SMTP lo entrega desde sus propias direcciones IP con su propio historial de env\u00edos. Los servicios de correo electr\u00f3nico transaccional existen precisamente para esto: sus direcciones solo env\u00edan recibos, restablecimientos de contrase\u00f1a y notificaciones, por lo que los destinatarios conf\u00edan m\u00e1s en ellos que en un servidor de correo saliente de uso general.<\/p>\n\n\n\n

Un buen servidor SMTP tambi\u00e9n firma el mensaje con una clave DKIM para tu dominio, de modo que el cliente sigue viendo tu direcci\u00f3n y DMARC se ejecuta correctamente. Sin embargo, no puede reparar contenido err\u00f3neo, un registro SPF faltante ni una lista de personas que nunca solicitaron tu correo. Primero corrige la autenticaci\u00f3n y luego revisa la ruta.<\/p>\n\n\n\n

Por qu\u00e9 elegimos Resend como rel\u00e9 SMTP<\/h2>\n\n\n\n

Nuestro primer intento fue con Amazon SES. Verificamos el dominio, indicamos que nuestro volumen de correos electr\u00f3nicos era de entre 20 y 50 correos transaccionales al d\u00eda, y al d\u00eda siguiente nos denegaron el acceso a producci\u00f3n sin darnos ninguna explicaci\u00f3n. Esta es una experiencia com\u00fan para una cuenta nueva, y dej\u00f3 a una tienda con claves de licencia pendientes de entrega.<\/p>\n\n\n\n

\"Amazon
El comienzo de la respuesta de Amazon Web Services. El resto del mensaje explica que la revisi\u00f3n considera factores que no puede compartir, por lo que no hab\u00eda nada espec\u00edfico que corregir.<\/figcaption><\/figure>\n\n\n\n

El segundo intento fue el de reenv\u00edo, y enviaba correos firmados para nuestro dominio unos diez minutos despu\u00e9s del registro. Tres cosas lo hicieron ideal para una peque\u00f1a tienda alojada en Synology:<\/p>\n\n\n\n