Seguridad y entrega

Cifrado en tránsito (TLS)

• Entrada (puerto 25): ofrecemos STARTTLS con TLS 1.2 o 1.3 y un certificado de Let's Encrypt. Como en todo servidor de correo, un remitente que no usa TLS aún puede entregar.
• Envío (puerto 587): STARTTLS es obligatorio antes del inicio de sesión; sin él, el servidor no acepta la contraseña.
• Entrega al destino: usamos STARTTLS siempre que el servidor de destino lo ofrece, como Gmail, Outlook y los grandes proveedores, e intentamos primero verificar el certificado. Si el destino exige TLS con su política MTA-STS, el mensaje solo sale cifrado y con certificado válido; sin esa exigencia, preferimos la conexión cifrada al texto plano aunque el certificado no coincida. Detalles en Entrega a otros dominios.
• Panel y API: solo HTTPS.

MTA-STS y TLS-RPT

MTA-STS indica a los demás servidores que tu MX acepta TLS con un certificado válido, lo que dificulta interceptar la conexión. Nuestro dominio publica su política (en modo de prueba) y recibe informes TLS-RPT. Para tu dominio, el panel muestra un CNAME mta-sts y dos TXT: servimos la política con un certificado emitido solo para tu nombre, y los informes TLS-RPT van a una dirección de tu dominio. Es opcional.

Entrega a otros dominios

Al entregar un mensaje, comprobamos si el dominio de destino publica una política MTA-STS (RFC 8461). La buscamos en https://mta-sts.<dominio>/.well-known/mta-sts.txt, la guardamos en caché durante el plazo que indica (max_age) y la volvemos a buscar cuando cambia el id del TXT _mta-sts.

• Política en modo enforce: solo entregamos a los MX que lista la política, con STARTTLS obligatorio y certificado válido (cadena de confianza y el nombre del MX). Si no se puede, el mensaje no sale en texto plano: queda en la cola y reintentamos; tras 5 días sin éxito, el remitente recibe el aviso de devolución.
• Política en modo testing: entregamos como si no hubiera política y registramos, internamente, cuándo habría fallado. Aún no enviamos informes TLS-RPT al destino.
• Sin política (la mayoría de los dominios): STARTTLS siempre que el destino lo ofrece, intentando primero verificar el certificado. Si la verificación falla, entregamos cifrado igualmente, sin verificar: es el TLS oportunista, la norma del correo en internet. En texto plano, solo cuando el destino no ofrece STARTTLS.
• DANE (registros TLSA): aún no lo aplicamos.

El registro de cada entrega dice si el TLS fue verificado, no verificado o ausente.

DKIM, con rotación en dos fases

• Cada dominio tiene su propia clave RSA de 2048 bits. La privada está cifrada en la base de datos (XChaCha20-Poly1305) y firma lo que envías por el puerto 587.
• Rotación sin perder correo: al rotar, la clave nueva recibe otro selector, pero la actual sigue firmando. Solo cuando el TXT de la nueva aparece en tu DNS empieza a firmar; el TXT anterior sigue en el panel 7 días más, porque un mensaje ya firmado puede seguir en reintento.

SPF, DMARC, ARC y SRS

• En la entrada comprobamos SPF, DKIM y DMARC de cada mensaje y respetamos p=reject.
• En tu dominio, el SPF incluye nuestro servidor (include:), y puedes publicar DMARC; el lector de informes DMARC es gratis y funciona en tu navegador.
• ARC: sellamos cada mensaje reenviado con la clave de la plataforma, para que el destino vea que la autenticación original pasó.
• SRS: el remitente del sobre se reescribe al reenviar, para que el SPF pase en el destino y las devoluciones vuelvan a quien envió.

Antispam

rspamd funciona en nuestro servidor y da una puntuación a cada mensaje; cada dominio elige el nivel:

El filtro también se puede desactivar. Un mensaje marcado como spam no va a los canales (webhook, Telegram).

Límites por plan

Cada plan tiene un tope de mensajes por día (por mes en el gratis), de destinos por dirección y de resúmenes por hora en los canales (60 por canal). Por encima del límite diario, el correo que llega recibe un aplazamiento temporal y el servidor del remitente reintenta después; el envío por el puerto 587 se rechaza hasta el día siguiente. Los límites existen para que una cuenta comprometida no perjudique a las demás. Las cifras de cada plan están en la página de planes.

Cuentas y aislamiento

• Contraseñas del panel en bcrypt; contraseñas SMTP en argon2, mostradas una sola vez, al crearlas; tokens de API guardados solo como hash. Inicio de sesión en dos pasos opcional.
• Una credencial SMTP solo envía como direcciones de su propio dominio.
• Cada equipo solo ve sus propios datos, comprobado dos veces: en el panel y en el servidor de correo.

Dónde está el servidor

En un servidor dedicado de Hetzner, en Finlandia (Unión Europea): el servidor de correo, la base de datos, la cola y el registro están en él, con copia de seguridad diaria. Las demás empresas que tratan datos (DNS, cobro, correos del panel) están en la lista de subencargados de la Política de privacidad.

Estado e incidentes

La página de estado comprueba cada minuto el MX, el SMTP de envío, el panel y la política MTA-STS, muestra 90 días de disponibilidad y el tiempo de reenvío, y enumera los incidentes. Las comprobaciones se ejecutan en el propio servidor, así que una caída total de este aparece como falta de datos, no en rojo; lo que descubramos de otro modo se convierte en incidente.

Preguntas frecuentes

¿Quieres probarlo con tu dominio? El plan gratis no pide tarjeta. Crear cuenta gratis