Correo transaccional: lo único que no te recomiendo autohospedar

15 de agosto de 2026 · 29 min de lectura

Este blog va de autohospedar cosas. Llevo varios artículos explicando cómo montar en tu propio servidor lo que otros te alquilan por meses.

Este va de la única pieza que te recomiendo no autohospedar.

No es una contradicción, es lo que sale de mirar los números. Montar un servidor de correo es lo fácil: apt install postfix y en diez minutos tienes uno funcionando. El problema es que funcionar y entregar son dos cosas distintas, y de la segunda tu servidor decide más bien poco.

Y no lo digo solo yo. Lo dice, por escrito, la empresa que te vende el servidor donde lo montarías:

«Desaconsejamos firmemente ejecutar tu propio servidor de correo, porque los servidores autohospedados son difíciles de asegurar y mantener, con frecuencia acaban marcados como spam y requieren vigilancia constante.»
Documentación de DigitalOcean, revisada en julio de 2026

Al final del artículo tienes SMTP2GO conectado, funcionando gratis y con el rastreo desactivado. Pero primero conviene entender contra qué estamos peleando, porque decide todo lo demás.

Por qué tu servidor de correo no entrega

El puerto 25 está cerrado, y no es cosa de tu proveedor

El correo entre servidores viaja por el puerto 25. Casi ningún proveedor de nube te deja usarlo de salida:

En casa es peor, porque además tu operador casi con seguridad lo bloquea. Conviene precisar una cosa: el RFC 5068 no recomienda bloquear el puerto 25, se declara neutral de forma explícita. La recomendación viene de M3AAWG, la asociación del sector. Lo que el RFC sí exige: los operadores no pueden bloquearte el puerto 587.

Tu IP no tiene historial, y eso se paga

Google y Microsoft no han visto nunca tu dirección IP. Antes de fiarse hay que calentarla, enviando poco y subiendo despacio. Amazon lo cifra en de dos a seis semanas según el proveedor de destino.

Para que veas hasta qué punto se lo toman en serio los que viven de esto, mira el calendario de calentamiento de SendGrid: arrancan en veinte correos por hora y no llegan a 211 hasta una semana después. Un Postfix recién instalado hace exactamente lo contrario: manda todo lo que le eches desde el primer segundo.

Y hay listas que te incluyen sin que hagas nada mal

La Policy Blocklist de Spamhaus cubre más de 1.400 millones de direcciones IPv4, casi el 40 % del espacio enrutable. Y ellos mismos aclaran el malentendido: «las IP de este conjunto no son necesariamente malas; simplemente, no deberían estar enviando correo». Si tu proveedor declaró ese rango como no emisor, estás dentro sin haber enviado nada todavía.

Peor aún es UCEPROTECT, que en su nivel 3 lista sistemas autónomos enteros. Lo reconocen sin rodeos: «puede causar, y probablemente causará, daño colateral a usuarios inocentes». Y la misma gente vende la exclusión por suscripción a través de otro sitio. Tu vecino de rango decide tu entregabilidad.

Si copias un tutorial que te dice de poner reject_rbl_client dnsbl.sorbs.net en tu Postfix, ese tutorial lleva dos años caducado: SORBS cerró el 5 de junio de 2024 y sus zonas están vacías.

La alternativa: un relay, y por qué el nivel gratuito sobra

Un relay de correo transaccional es un servicio que recibe tus mensajes por SMTP y los entrega con sus IP, que llevan años de reputación construida y equipos dedicados a mantenerla. Tú te ahorras los cuatro problemas anteriores de golpe.

Lo interesante es que el correo transaccional de un servicio interno es poquísimo volumen. Altas, recuperaciones de contraseña, avisos de que alguien compartió algo. Para un equipo de quince personas eso son decenas de correos al mes, no miles. Cabe de sobra en cualquier nivel gratuito.

Estas son las cifras de agosto de 2026, sacadas de la página de precios de cada uno:

Las dos últimas filas merecen un aviso, porque casi todas las comparativas que vas a encontrar siguen recomendándolos:

• SendGrid anunció el final de su plan gratuito el 27 de mayo de 2025 y dio sesenta días de margen: «se pausará el envío de correo en todas las cuentas de planes gratuitos». El corte llegó el 26 de julio. Hoy solo hay una prueba de 60 días.
• Amazon SES retiró su nivel gratuito el 21 de julio de 2026, hace tres semanas, para clientes nuevos. Si te encuentras la cifra de 62.000 correos al mes por ahí, es de una etapa que terminó en 2023. Ahora entras por los créditos genéricos de AWS. Y ojo con el sandbox, que sigue vigente: hasta que te aprueben, solo puedes enviar a direcciones verificadas, 200 mensajes cada 24 horas.

Que el resto del artículo vaya de SMTP2GO no significa que sea el mejor. Varios de esta tabla valen, y la elección depende de tu caso: Mailgun da el triple de volumen, Elastic Email también, y ninguno de los tres pide tarjeta. Uso SMTP2GO porque el alta es de las más simples de contar, y porque el procedimiento es prácticamente idéntico en todos: verificar el dominio con un par de registros DNS, sacar las credenciales y meterlas en tu aplicación. Si sigues este artículo con otro proveedor, vas a reconocer cada paso.

Dicho eso, dos detalles suyos que sí me gustan y que conviene mirar en cualquiera que elijas. Admite cinco dominios remitentes en vez de uno, y guarda cinco días de registros en lugar de uno. Ese último importa más de lo que parece: cuando alguien te dice el lunes que el viernes no le llegó el alta, con un día de historial no tienes nada que mirar.

Y un detalle sobre sus límites, que se comportan distinto: si te pasas del tope diario, los correos se encolan y salen luego. Si te pasas del mensual, se rechazan y se pierden.

¿Prefieres que monte alguno de los otros? Déjamelo en los comentarios y escribo el suyo.

El alta, paso a paso

Vamos primero con lo práctico, que son diez minutos. Después explico por qué funciona lo que vas a montar, que es lo que de verdad te sirve el día que algo no llegue.

Tras confirmar el correo, lo primero es dar de alta el dominio desde el que vas a enviar. Aquí hay una decisión que conviene entender:

Para un servicio interno quieres dominio remitente, porque así puedes usar passbolt@, uptime@ o lo que necesites sin volver a pasar por aquí. El plan gratuito admite cinco.

Un minuto después, los registros ya están puestos:

El tercer registro: el que yo borro

El CNAME link sirve para que SMTP2GO reescriba todos los enlaces de tus correos y los haga pasar por su sistema de rastreo, para contar clics. Es el mismo mecanismo que usan las herramientas de marketing, y para eso está bien. Para los avisos de un servicio interno, tengo tres motivos para no ponerlo.

Uno: puede consumir tus enlaces de un solo uso

Este es el motivo serio, y no va de entregabilidad sino de que las cosas funcionen.

Los filtros corporativos abren los enlaces de tus correos antes de entregarlos. Microsoft Safe Links lo documenta así: «las URL se analizan antes de la entrega del mensaje». Barracuda, Proofpoint y Mimecast hacen lo mismo.

Ahora piensa qué es un enlace de alta o de recuperación de contraseña: solo funciona una vez. Si un escáner lo abre antes que la persona, lo deja usado. No es teoría, está documentado por los propios fabricantes de sistemas de identidad: NextAuth tiene un tutorial dedicado al problema y lo describe sin ambigüedad, «en la práctica, gastándolo». Supabase avisa de lo mismo y nombra a Safe Links. Auth0 recomienda directamente usar códigos en vez de enlaces.

Añadir un dominio de rastreo que reescribe cada enlace es meter un salto más en un camino que ya es frágil. Yo no lo hago.

Dos: el dato que justifica el rastreo ya no es fiable

El rastreo de aperturas funciona con una imagen transparente de un píxel. Desde iOS 15, la Protección de Privacidad de Apple descarga ese contenido remoto «al recibir el mensaje, en lugar de al verlo». Es decir: el píxel se dispara aunque nadie abra nada. Gmail, por su parte, sirve las imágenes desde su propio proxy desde 2013, así que la IP y el navegador que registras no son los del usuario.

La frase definitiva la firma el propio Google en sus directrices para remitentes: «Google no rastrea las tasas de apertura», y añade que unas aperturas bajas «no son necesariamente un indicador fiable de problemas de entrega».

Tres: los dominios de rastreo compartidos acaban bloqueados

Cuando el rastreo va por un dominio compartido, compartes también su reputación. Netcraft documentó una campaña de suplantación montada sobre el rastreo de clics de un proveedor grande, con al menos nueve cuentas de clientes comprometidas. Spamhaus tiene un código específico para esto en su lista de dominios: 127.0.1.103, «dominio redirector abusado por spam».

Y hay un cuarto motivo que ya no es técnico: en 2026 tanto la autoridad italiana como la francesa han publicado directrices que exigen consentimiento previo para los píxeles de seguimiento. La francesa, eso sí, exime expresamente los correos transaccionales ligados a un servicio que el usuario ha pedido. Que es justo nuestro caso, pero mejor no tener que discutirlo.

Cómo se quita

Se borra desde tu propio DNS, no desde SMTP2GO:

Y ahora la parte que había que comprobar, porque una cosa es la teoría y otra que el proveedor no se enfade. Vuelves a SMTP2GO, le das a verificar otra vez, y esto es lo que sale:

El dominio sigue verificado, los correos siguen saliendo autenticados, y el panel se limita a marcar el rastreo como deshabilitado. Sin dramas.

Comprobar que ha quedado bien

Antes de conectar nada, mira que el DNS ha quedado como quieres: los dos de autenticación resolviendo, y el de rastreo sin resolver nada. Sustituye el identificador por el tuyo, que es el que te ha dado SMTP2GO:

# El de los rebotes: tiene que devolver return.smtp2go.net
dig +short em799236.itrafa.com CNAME

# El de DKIM: tiene que devolver una clave, no un vacio
dig +short s799236._domainkey.itrafa.com TXT

# Y el de rastreo NO debe devolver nada
dig +short link.itrafa.com CNAME

Si el primero no devuelve return.smtp2go.net., o el segundo no devuelve una clave, el registro está mal escrito o el DNS todavía no ha propagado. Si el tercero devuelve algo, es que el de rastreo sigue vivo. Y con los tres así, toca entender por qué esto funciona sin tocar nada más de tu dominio.

Por qué no tocas el SPF ni el DMARC de tu dominio

Ya tienes los tres registros puestos y comprobados. Esto es lo que hacen, y por qué no hay que tocar nada más.

Un correo lleva dos remitentes. El de la cabecera From:, que es el que ve el usuario, y el del sobre, el MAIL FROM, que viaja en el Return-Path y solo ven los servidores. SPF valida el del sobre, no el que ve el usuario: el RFC 7208 es explícito y desaconseja comprobar otras identidades.

El primer CNAME pone ese sobre a tu nombre. Al crear em799236.tudominio.com apuntando a return.smtp2go.net, el receptor valida SPF contra tu subdominio y, siguiendo el CNAME, acaba leyendo el registro de SMTP2GO. Tu SPF raíz no interviene en ningún momento, y por eso puede seguir en -all con solo Microsoft 365 dentro.

DMARC añade una condición más: el dominio que SPF ha validado tiene que alinear con el del From:. En modo relajado, que es el de por defecto (aspf=r), basta con que compartan dominio organizativo, y em799236.tudominio.com y tudominio.com lo comparten. El segundo CNAME hace lo propio por el lado de DKIM: la firma sale con d=tudominio.com. Con que alinee uno de los dos, DMARC da por bueno el mensaje, así que tu política puede seguir en p=reject sin tocarla.

Dicho de otra forma: los mensajes del relay se autentican con registros que cuelgan de tu dominio pero cuyo contenido mantiene SMTP2GO. Tú publicas dos punteros y ellos se encargan del resto, incluida la rotación de la clave de firma.

No añadas SMTP2GO a tu registro SPF. Además de innecesario, es arriesgado: SPF tiene un límite duro de diez consultas DNS y Microsoft 365 ya gasta unas cuantas. Pasarse no falla «un poco», devuelve permerror, y eso no tumba el correo del relay: tumba el SPF de todo tu dominio, correo corporativo incluido.

Un apunte para quien vaya a buscar documentación: DMARC cambió de norma en 2026. El RFC 7489 quedó obsoleto, y donde había uno ahora hay tres: el RFC 9989, que además deja obsoleto también el 9091, más el RFC 9990 para los informes agregados y el RFC 9991 para los de fallo. El cambio que más te puede afectar: la etiqueta pct= ha desaparecido, que era la forma estándar de desplegar DMARC poco a poco. En su lugar entra t=, el modo de prueba, y el cambio de fondo es que ya no hay despliegue por porcentajes: o aplicas la política o no la aplicas. Se sigue acotando con sp= y np=.

Los cuatro datos que vas a necesitar

Los registros DNS autentican tu dominio, pero no son con lo que se envía. Para eso hacen falta unas credenciales, y están en un sitio que no es evidente: en el panel de SMTP2GO, en Sending → SMTP Users.

Ahí creas un usuario, y el servicio te da una contraseña. Con eso ya tienes los cuatro datos:

Y ojo con la contraseña, porque este es el momento. SMTP2GO la muestra en claro aquí y solo aquí. Cópiala a tu gestor antes de salir de esta pantalla. Si la pierdes no se recupera, se genera otra, y eso significa tocar la configuración de todo lo que ya estuviera enviando con la anterior.

Los ocho puertos, y cuál usar de verdad

El panel te da una lista de ocho puertos. Los probé uno a uno antes de escribir esto: los ocho aceptan conexión, los ocho negocian TLS 1.3 y en los ocho llegué a autenticar, cortando la conversación antes de enviar nada. El cifrado lo puedes comprobar tú con esta orden:

El cifrado no lo decide el número de puerto, lo decide el protocolo. En el 25, el 587, el 2525, el 80 y el 8025 la sesión empieza en claro y sube a TLS con STARTTLS. En el 465, el 443 y el 8465 va cifrada desde el primer byte, sin fase previa. Por eso los ocho salen con TLS 1.3 ahí arriba: el 2525 no es «el puerto sin cifrar», es un 587 con otro número.

Dicho eso, no son intercambiables del todo, y el criterio es este:

• 587, por defecto. Es el puerto registrado en la IANA para el envío de correo (RFC 6409) y lo entiende absolutamente todo. Si tu red lo deja salir, no busques más.
• 465, si tu cliente lo admite. Va cifrado desde el primer byte, así que no hay fase en claro que un intermediario pueda tumbar para que la sesión se quede sin cifrar. El RFC 8314 lo recomienda por eso.
• 2525, solo si te bloquean los otros. No está registrado en la IANA para nada: es una convención del sector, y funciona justamente porque no aparece en las listas de bloqueo habituales.
• 443, como último recurso. En una red que filtra de todo, es la que más difícil se lo pone: por fuera no se distingue de una conexión HTTPS.

Y acuérdate de la primera sección: el que te bloquea el 25 es tu proveedor, no SMTP2GO. Que ellos tengan ocho puertos abiertos no significa que tú puedas salir por los ocho.

Compruébalo antes de configurar nada

Esto son treinta segundos y te ahorra una tarde entera. Antes de tocar la aplicación, mira por qué puertos puede salir el servidor donde la vas a montar. Si el que elegiste está filtrado, no lo vas a descubrir por un mensaje de error claro: lo vas a descubrir porque no llega nada y te vas a poner a revisar la contraseña, que estaba bien.

No hace falta instalar nc ni telnet. /dev/tcp es una redirección del propio bash y está siempre:

for p in 25 587 2525 465; do
  if timeout 5 bash -c "</dev/tcp/mail.smtp2go.com/$p" 2>/dev/null; then
    echo "  $p  abierto"
  else
    echo "  $p  BLOQUEADO"
  fi
done

Se lee solo: si responde al instante, el puerto sale. Si tarda los cinco segundos enteros y dice BLOQUEADO, ese puerto está filtrado y ahí no hay nada que configurar, hay que pedir que lo abran o usar otro. Y si te sale bloqueado todo, revisa si tu cortafuegos de salida está en lista blanca, que es más común de lo que parece en redes de empresa.

Tres ajustes del formulario, y uno te cuesta media cuota

El alta sale adelante sin tocar ninguno de estos tres ajustes. Merece la pena mirarlos igualmente.

Ponle un límite de envío, aunque no lo necesites

En el propio formulario está Rate Limit, y viene marcado Use default, que en una cuenta nueva significa ilimitado. Quítale esa marca y pon una cifra.

Qué cifra: mira lo que envía de verdad ese servicio y multiplícalo por cinco. Si tu web manda veinte avisos al día, ponle cien. No te va a estorbar nunca en el uso normal, y el día que un bucle mal cerrado se dispare a las tres de la mañana, se corta ahí en vez de comerse los mil correos del mes. Un tope no es una restricción, es un detector de averías que además las frena.

Apaga el rastreo también aquí

Más arriba he contado por qué borro el tercer CNAME, el del rastreo. Pues bien: los interruptores están además en cada usuario, en la pestaña Tracking & Status. Apagar Open Tracking y Click Tracking aquí es el cinturón que acompaña a los tirantes, y es lo que hace que tus enlaces salgan tal cual los escribiste.

La copia de auditoría te duplica el consumo

En Advanced hay una opción que parece regalada: Email Auditing, que manda copia oculta de todo lo que envías a la dirección que le pongas. Suena a red de seguridad. Pero léete la letra pequeña, que está ahí mismo: esas copias cuentan para tu cuota mensual. Es decir, la activas y pasas de 1.000 correos a 500 reales.

Al lado está Bounce Notifications, que sí conviene encender: te avisa por correo cada vez que un mensaje rebota. Es la diferencia entre enterarte al día siguiente y enterarte en agosto.

Uno por servicio, no uno para todo

Última decisión, y es la que más se agradece con el tiempo. Puedes crear varios usuarios SMTP sin coste, así que crea uno por cada cosa que envíe y ponle una descripción que se entienda: web, copias de seguridad, Uptime Kuma.

El motivo es de contención, y encaja con el tope de antes. Una credencial SMTP vive en claro en el fichero de configuración de cada servicio que la usa: en el wp-config, en el docker-compose, en el guion de las copias. Cualquiera que llegue a leer ese fichero se la lleva. Y con esa credencial no solo puede enviar: puede enviar como tu dominio, firmado y alineado, que es exactamente lo que hemos pasado media tarde montando.

Con una credencial compartida, ese día tienes que rotarla y reconfigurar a la vez todo lo que envíe correo en tu red, mientras el resto sigue sin funcionar. Con una por servicio, revocas esa y ya está. Y si además cada una lleva su tope, el que se lleve una no puede pasar de esa cifra: el daño tiene techo antes de que tú te enteres. Como efecto secundario, el registro de actividad te dice qué usuario envió qué, así que «¿quién ha mandado esto?» tiene respuesta.

Manda un correo de prueba antes de tocar tu aplicación

Este paso ahorra las tardes tontas. Si lo haces, sabes con certeza si el problema está en el relay o en la configuración de tu aplicación, en vez de andar adivinando.

curl habla SMTP, así que no hay que instalar nada más. Sustituye las credenciales y tu dirección:

curl --url 'smtp://mail.smtp2go.com:587' --ssl-reqd \
  --user 'TU_USUARIO:TU_CONTRASENA' \
  --mail-from '[email protected]' \
  --mail-rcpt '[email protected]' \
  --upload-file - <<'EOF'
From: Avisos <[email protected]>
To: [email protected]
Subject: Prueba de SMTP2GO

Si lees esto, el relay funciona.
EOF

El --ssl-reqd no es decorativo: obliga a cifrar la conexión y falla si el servidor no lo ofrece. Sin él, curl mandaría tus credenciales en claro si algo saliera mal.

Si el correo llega, el relay está bien y lo que quede por resolver está en tu aplicación. Si no llega, mira el registro en Reports → Activity del panel: ahí ves si el mensaje salió, si rebotó y por qué. Recuerda que en el plan gratuito ese historial dura cinco días.

Y ya que lo tienes delante, ábrelo y dale a mostrar original. Esas son las tres líneas que cierran el círculo: si SPF, DKIM y DMARC dicen PASS, los registros que pusiste están haciendo su trabajo. Si DKIM pasa pero con un dominio que no es el tuyo, el segundo CNAME está mal. Y si DMARC falla teniendo los otros dos en PASS, es un problema de alineación, que es lo que explica la sección anterior.

Si tu dominio ya usa Microsoft 365 o Google Workspace

Este es el caso de casi cualquier empresa pequeña, y el que más miedo da: ya tienes el correo corporativo funcionando y no quieres romperlo por añadir un relay para cuatro avisos.

No lo vas a romper, y no tienes que tocar nada de lo que ya tienes. Lo comprobé sobre un dominio real que envía por Microsoft 365, con el SPF terminado en -all y DMARC en p=reject, que es la configuración más estricta que se puede tener. Los correos de SMTP2GO pasan igualmente, por lo que ya viste en la sección de la alineación.

Lo único que sí conviene cuidar es el remitente. Envía siempre desde una dirección de tu propio dominio, del tipo [email protected]. Si pones el From: de otro dominio, quien manda es el DMARC de ese otro y tu configuración no te protege.

La fecha que conviene tener apuntada

Ya lo tienes montado, así que esto va de por qué te va a hacer falta más allá del servicio que acabas de conectar. Puede además que hayas llegado a este artículo por el otro camino: que algo dejara de enviar sin que nadie tocara nada. Si es tu caso, esto te va a sonar.

En muchas organizaciones hay aplicaciones y dispositivos enviando con el usuario y la contraseña de una cuenta corporativa, apuntando al servidor SMTP de Microsoft o de Google. El caso más repetido es una cuenta creada para eso, del tipo [email protected], que alguien dio de alta el día que llegó la multifunción. Eso se está acabando, y los dos proveedores van a ritmos distintos.

Google: esto ya pasó

Google ya apagó las llamadas «aplicaciones menos seguras», de forma escalonada entre mediados de 2024 y la primera mitad de 2025. Su documentación lo dice sin rodeos: «CalDAV, CardDAV, IMAP, SMTP y POP dejarán de funcionar con contraseñas heredadas».

Y una muestra de lo difícil que es seguirle el rastro a estos plazos: Google publica cuatro fechas distintas del apagado en cuatro páginas oficiales suyas (30 de septiembre de 2024, enero de 2025, 14 de marzo de 2025 y 1 de mayo de 2025). No voy a elegir una y hacer como que es la buena. Lo que importa es que hoy ya está apagado.

Y un matiz que cambia el diagnóstico: Google no cerró SMTP. Lo que dejó de aceptar es la contraseña de la cuenta. Las contraseñas de aplicación siguen funcionando, así que un dispositivo se puede reconfigurar. El problema es que hay que saberlo y hacerlo.

Microsoft: te pasa en diciembre

Aquí todavía funciona, y por eso conviene leer esto ahora y no en enero. La cronología oficial, que además sustituye a una anterior más agresiva, es esta:

Es decir: si tienes algo enviando con usuario y contraseña de una cuenta de Microsoft 365, tienes hasta finales de diciembre. Después seguirá siendo reactivable a mano, pero ya empiezas a nadar contracorriente, y en 2027 anuncian el final definitivo. Un apunte para quien se fíe de los plazos: esta fecha ya se ha aplazado dos veces, de septiembre de 2025 a abril de 2026 y de ahí a diciembre. Que se haya movido dos veces no es motivo para no prepararse, es motivo para no dejarlo para el último mes.

Microsoft ofrece un recambio propio que se llama High Volume Email, y conviene saber qué es antes de que alguien te lo proponga: sirve para destinatarios internos de tu organización, y solo para eso. Para mandar un aviso a un cliente no vale. Además se factura desde el 1 de junio de 2026, a 42 dólares por millón de destinatarios, y sin una política de facturación asignada la cuenta directamente no envía.

Por qué esto se descubre siempre por un ticket

He visto el mismo patrón varias veces, y es el que hace que este cambio duela más de lo que debería. Nadie vigila lo que lleva años funcionando.

El caso típico es la impresora que llevaba seis años escaneando a correo sin que nadie la tocara. La configuró alguien que ya no está, con la contraseña de una cuenta que nadie recuerda, y funcionaba. Un día deja de funcionar, y el equipo de sistemas no se entera por un aviso ni por un panel: se entera porque empiezan a llegar tickets de gente diciendo que el escáner ya no manda nada.

Y que esto no es una manía mía lo dice el propio sector: Ricoh publicó un aviso formal en mayo de 2025, actualizado en febrero de 2026, listando qué funciones dejan de ir (escaneo a correo, fax por Internet, notificaciones) y en qué modelos. Xerox tiene otro, con firmware compatible con OAuth ya disponible y sin cambiar de máquina. Si tu parque es de esas marcas, hay deberes con nombre y apellidos.

Lo mismo pasa con los avisos de la copia de seguridad, con el formulario de la web, con el aviso del sistema de alarmas y con cualquier automatización que alguien montó hace años. Todo eso comparte una característica: nadie lo mira hasta que se rompe, y cuando se rompe no avisa, simplemente deja de enviar.

Aquí es donde un relay deja de ser una comodidad y pasa a ser lo sensato. Esas credenciales no dependen de ninguna cuenta de persona, no caducan con las políticas del correo corporativo, y si mañana hay que rotarlas se rotan en un sitio y ya está. Es la diferencia entre un inventario y una sorpresa.

Y ahora, a conectarlo

Ya tienes el relay funcionando y comprobado. Lo que queda es meter esos cuatro datos en cada servicio, y eso sí cambia según cuál sea.

El siguiente artículo que publico es el de Passbolt, donde lo conecto de principio a fin. Es el caso perfecto para esto: sin correo funcionando, Passbolt no te deja dar de alta absolutamente a nadie.

Autohospedar tiene sentido en casi todo. En el correo saliente, la cuenta no sale: pelearte durante semanas con listas de bloqueo y calentamiento de IP, para acabar entregando peor que un servicio que no te cobra nada. Delegar esto no es rendirse. Es elegir dónde gastas tus tardes.

Seguir leyendo en IT Rafa

• Cómo instalar Passbolt con Docker, el gestor de contraseñas que no arranca sin correo (en camino)
• Cómo conectar tu dominio a Cloudflare de forma gratuita, que es donde vas a poner estos registros
• Cómo instalar Docker y Docker Compose en Linux
• Instalar Uptime Kuma con Docker, otro servicio que agradece un relay de correo