Cuando gestionas una web, das por hecho que el email funciona: que llegan los leads del formulario, que el cliente recibe la confirmaci\u00f3n de pedido, que el \u201che olvidado mi contrase\u00f1a\u201d no falla. Cuando eso no pasa, no es un detalle menor: es p\u00e9rdida de confianza, de ventas y de credibilidad.<\/p>\n\n\n\n
El culpable suele ser silencioso y recurrente: la configuraci\u00f3n de correo \u201cpor defecto\u201d del sitio. En much\u00edsimas instalaciones (especialmente en WordPress) los emails salen de una forma que para Gmail u Outlook se parece demasiado al spam. La soluci\u00f3n no es reenviar o rezar, sino cambiar el canal de salida por uno profesional y autenticado usando SMTP (Simple Mail Transfer Protocol).<\/p>\n\n\n\n
El problema es que, al configurar SMTP, aparece una pregunta que parece simple y es cr\u00edtica: \u00bfqu\u00e9 puerto SMTP debo usar en 2026? La respuesta correcta es la llave para tener un env\u00edo fiable y seguro.<\/p>\n\n\n\n
wp_mail()<\/code> en WordPress) suele ir sin autenticaci\u00f3n<\/strong>, desde un servidor web sin reputaci\u00f3n de correo. Eso dispara los filtros anti-spam.<\/li>\n\n\n- La soluci\u00f3n real (el \u201cc\u00f3mo\u201d): usa un servicio SMTP transaccional<\/strong> (por ejemplo SendGrid, Brevo o Mailgun) para enrutar el correo por un servidor confiable y autenticado.<\/li>\n\n\n
- Bot\u00f3n f\u00e1cil en WordPress: un plugin sin configuraci\u00f3n como Site Mailer by Elementor<\/a><\/strong> puede reenrutar el email transaccional sin tocar puertos, sin API keys y sin configurar DNS manualmente.<\/li>\n\n\n
- Transaccional vs marketing: SMTP es para email transaccional<\/strong> (formularios, resets, recibos). Para newsletters y env\u00edos masivos usa una plataforma de email marketing (ESP)<\/strong> para no cargarte la reputaci\u00f3n de env\u00edo.<\/li>\n\n<\/ul>\n\n\n\n
Qu\u00e9 es SMTP y por qu\u00e9 importa en una web<\/h2>\n\n\n\n
SMTP (Simple Mail Transfer Protocol) es, en la pr\u00e1ctica, el \u201cservicio postal\u201d est\u00e1ndar de Internet para mover emails entre clientes y servidores. No es un detalle acad\u00e9mico: define c\u00f3mo se entrega el correo y, por tanto, si tus mensajes llegan o se pierden por el camino.<\/p>\n\n\n\n
Cuando env\u00edas un email, no viaja m\u00e1gicamente directo a la bandeja de entrada del destinatario. El flujo t\u00edpico es:<\/p>\n\n\n\n
\n\n- Tu web o cliente env\u00eda el mensaje a un servidor de salida<\/strong> (por ejemplo
smtp.gmail.com<\/code>). Este paso se conoce como submission<\/strong>.<\/li>\n\n\n- Ese servidor busca el servidor del destinatario y relaya<\/strong> el mensaje hacia \u00e9l.<\/li>\n\n\n
- El servidor del destinatario retiene el email hasta que el usuario consulta su bandeja de entrada.<\/li>\n\n<\/ol>\n\n\n\n
SMTP cubre tanto el paso de submission como el de relay. Y un \u201cpuerto SMTP\u201d es simplemente la \u201cpuerta numerada\u201d del servidor por la que se permite esa comunicaci\u00f3n.<\/p>\n\n\n\n
El problema t\u00edpico en WordPress: wp_mail()<\/code><\/h3>\n\n\n\nPor defecto, WordPress no usa SMTP. Usa una funci\u00f3n basada en PHP llamada wp_mail()<\/code> que intenta enviar el email desde el propio servidor web.<\/p>\n\n\n\nEsto es un golpe directo a la entregabilidad por varios motivos:<\/p>\n\n\n\n
\n\n- No es un servidor de correo<\/strong>: el servidor est\u00e1 optimizado para servir p\u00e1ginas, no para enviar email con garant\u00edas (colas, reintentos, pol\u00edticas, etc.).<\/li>\n\n\n
- No hay autenticaci\u00f3n real<\/strong>: el servidor \u201cdice\u201d que env\u00eda como
tudominio.com<\/code>, pero no demuestra de forma robusta que est\u00e9 autorizado.<\/li>\n\n\n- No hay reputaci\u00f3n de env\u00edo<\/strong>: Gmail\/Microsoft punt\u00faan servidores de correo con reputaci\u00f3n; un servidor web t\u00edpico no tiene reputaci\u00f3n como MTA (Mail Transfer Agent). Eso lo convierte en un emisor \u201cdesconocido\u201d y sospechoso.<\/li>\n\n\n
- Mala vecindad de IP<\/strong>: en hosting compartido, tu IP puede estar asociada a cientos de sitios. Si uno env\u00eda spam y la IP cae en listas negras, tu correo leg\u00edtimo se hunde con \u00e9l.<\/li>\n\n<\/ol>\n\n\n\n
Resultado: el proveedor de inbox ve un correo sin autenticaci\u00f3n s\u00f3lida, desde un servidor que \u201cparece web\u201d y sin reputaci\u00f3n, y lo manda a spam o lo bloquea sin avisar. La forma sensata de arreglarlo es hacer que WordPress deje de depender de wp_mail()<\/code> y env\u00ede por un canal SMTP profesional (o v\u00eda API del proveedor).<\/p>\n\n\n\nHistoria r\u00e1pida de los puertos SMTP (y por qu\u00e9 varios ya no tienen sentido en 2026)<\/h2>\n\n\n\n
Entender los puertos es entender c\u00f3mo Internet ha ido endureciendo el email contra el abuso. La evoluci\u00f3n de SMTP est\u00e1 marcada por la lucha continua contra el spam.<\/p>\n\n\n\n
Puerto 25: el original (y la autopista del spam)<\/h3>\n\n\n\n
En 1982 se defini\u00f3 el puerto 25<\/strong> como canal para el relay entre servidores (MTA a MTA). Era abierto y sin autenticaci\u00f3n: cualquier servidor pod\u00eda conectarse a otro por el 25 y entregarle correo.<\/p>\n\n\n\nEl problema es obvio con perspectiva: los spammers pod\u00edan conectar a servidores por el 25, inyectar miles o millones de mensajes y usar esos servidores como plataforma de env\u00edo. Era una autopista sin peajes: sin cifrado, sin autenticaci\u00f3n y f\u00e1cil de abusar.<\/p>\n\n\n\n
D\u00f3nde estamos hoy: por ese legado, casi cualquier ISP, proveedor cloud y red residencial bloquea conexiones salientes al 25<\/strong> para frenar bots en m\u00e1quinas infectadas y servidores comprometidos. Por eso no debes usar el 25 para submission<\/strong> desde tu web. Aunque tu hosting lo permitiese (no deber\u00eda), gran parte de Internet bloquear\u00e1 el env\u00edo.<\/p>\n\n\n\nPuerto 465: la primera v\u00eda segura (SMTPS)<\/h3>\n\n\n\n
A finales de los 90 qued\u00f3 claro que hac\u00eda falta cifrado. Ah\u00ed aparece el puerto 465<\/strong> con SMTPS<\/strong> (\u201cSMTP over SSL\u201d), que inicia el handshake SSL\/TLS desde el primer momento<\/strong>. Es lo que se llama Implicit SSL\/TLS<\/strong>: el t\u00fanel cifrado existe antes de enviar comandos SMTP.<\/p>\n\n\n\nDurante un tiempo no fue un est\u00e1ndar oficial de la IETF y lleg\u00f3 a considerarse \u201cdeprecated\u201d en favor de STARTTLS. Aun as\u00ed, el 465 volvi\u00f3 con fuerza y hoy es un est\u00e1ndar aceptado, seguro y muy popular. Proveedores grandes (incluido Gmail) lo recomiendan en muchos escenarios. Para un sitio web es una opci\u00f3n perfectamente v\u00e1lida.<\/p>\n\n\n\n
Puerto 587: el est\u00e1ndar moderno (STARTTLS)<\/h3>\n\n\n\n
Para resolver el encaje con los est\u00e1ndares, la IETF design\u00f3 el puerto 587<\/strong> como el puerto oficial de email submission<\/strong> (es decir, tu web o cliente enviando correo). En el 587, el cifrado habitual es STARTTLS<\/strong>, tambi\u00e9n llamado Explicit TLS<\/strong>.<\/p>\n\n\n\nEl flujo es as\u00ed:<\/p>\n\n\n\n
\n\n- Tu web conecta con el servidor por el 587 inicialmente en texto plano.<\/li>\n\n\n
- Env\u00eda
EHLO<\/code> para presentarse.<\/li>\n\n\n- El servidor responde con capacidades, entre ellas
STARTTLS<\/code>.<\/li>\n\n\n- Tu web env\u00eda el comando
STARTTLS<\/code> para \u201celevar\u201d la conexi\u00f3n.<\/li>\n\n\n- Se crea el t\u00fanel TLS y, a partir de ah\u00ed, se env\u00edan credenciales y contenido del email de forma cifrada.<\/li>\n\n<\/ol>\n\n\n\n
En 2026, cualquier servidor que no fuerce cifrado en el 587 se considera inseguro. En la pr\u00e1ctica, 587 es el puerto recomendado y m\u00e1s com\u00fan para submission<\/strong>, compatible con pr\u00e1cticamente cualquier proveedor SMTP.<\/p>\n\n\n\nPuerto 2525: puerto alternativo (fallback)<\/h3>\n\n\n\n
El puerto 2525<\/strong> no es un puerto SMTP \u201coficial\u201d. Es un puerto alternativo que muchos proveedores ofrecen como plan B.<\/p>\n\n\n\nCu\u00e1ndo usarlo: cuando tu hosting bloquea 587<\/strong> y 465<\/strong>. No es lo habitual, pero ocurre (por ejemplo, algunas plataformas cloud restringen el 587 para evitar abusos y te fuerzan a usar su relay o un servicio dedicado que escucha en 2525). Normalmente usa el mismo enfoque de cifrado tipo STARTTLS.<\/p>\n\n\n\nVeredicto 2026: qu\u00e9 puerto SMTP usar en tu web<\/h2>\n\n\n\nOpci\u00f3n principal: 587 con STARTTLS<\/h3>\n\n\n\n
Es tu primera elecci\u00f3n. Es el est\u00e1ndar moderno de submission, lo soporta pr\u00e1cticamente todo el mundo y est\u00e1 pensado justo para lo que necesitas. Cuando configures un plugin SMTP, el primer intento<\/strong> deber\u00eda ser 587 + STARTTLS (TLS)<\/strong>.<\/p>\n\n\n\nOpci\u00f3n secundaria: 465 con SMTPS<\/h3>\n\n\n\n
Si 587 falla (por bloqueo, pol\u00edtica del proveedor o configuraci\u00f3n), o si tu proveedor lo prefiere expl\u00edcitamente, 465 + SMTPS (SSL\/TLS impl\u00edcito)<\/strong> es una alternativa excelente y segura.<\/p>\n\n\n\nCasi nunca: 25<\/h3>\n\n\n\n
Para env\u00edo desde tu web, no. El 25 se queda para relay entre servidores, no para submission desde aplicaciones. En hosting moderno suele estar bloqueado y, aunque no lo est\u00e9, te expones a problemas de seguridad y entregabilidad.<\/p>\n\n\n\n
Tabla comparativa r\u00e1pida de puertos SMTP<\/h3>\n\n\n\n