Ir al contenido

El cifrado del correo que recibes se puede desactivar sin que lo notes

Aviso Todo el dominio Entrega de emails

Instrucciones generales. Abre este artículo desde tu informe de PageCheck para verlo con los servidores de correo de tu dominio y los pasos exactos de tu proveedor de DNS.

Qué es

El correo entre servidores suele ir cifrado, pero solo si ambos lados lo acuerdan por el camino, y un atacante en medio puede quitar esa oferta: el correo se entrega entonces sin cifrar y nadie se da cuenta. MTA-STS es una pequeña política pública que indica a los servidores remitentes que tus servidores de correo siempre admiten cifrado, así que no deben entregar sin él.

Qué falla

example.com no tiene política MTA-STS, así que el cifrado del correo que se le envía se puede desactivar sin que se note. Su política DMARC ya frena el correo falsificado en su nombre; este es el siguiente paso.

Cómo arreglarlo

Empieza en modo testing: los servidores remitentes solo informan de los problemas y siguen entregando cada mensaje, así que nada puede salir mal mientras compruebas la configuración.

1. Escribe el archivo de política. Guarda esto como un archivo de texto plano llamado mta-sts.txt. Debe incluir cada servidor de correo (MX) del dominio:

mta-sts.txt

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

2. Publícalo en su propia dirección. El archivo debe abrirse en https://mta-sts.example.com/.well-known/mta-sts.txt por HTTPS, con un certificado válido y sin ninguna redirección: una redirección a www o al sitio principal hace que los remitentes lo ignoren.

Si tu DNS está en Cloudflare, lo más sencillo es un Cloudflare Worker (gratis): Workers & Pages → Create → Create Worker, llámalo mta-sts, sustituye su código por el de abajo y pulsa Deploy. Después, en Settings del Worker → Domains & Routes → Add → Custom domain: mta-sts.example.com. Cloudflare crea el registro DNS y el certificado.

Cloudflare Worker

export default {
  async fetch() {
    const policy = [
      'version: STSv1',
      'mode: testing',
      'mx: mail.example.com',
      'max_age: 86400',
    ].join('\r\n') + '\r\n';
    return new Response(policy, { headers: { 'content-type': 'text/plain; charset=utf-8' } });
  },
};

En tu hosting: añade el subdominio mta-sts.example.com con un certificado SSL, crea en él una carpeta llamada .well-known y sube allí mta-sts.txt.

  • Plesk: Websites & Domains → Add Subdomain, luego SSL/TLS Certificates → Let's Encrypt, luego File Manager.
  • cPanel: Domains → Create A New Domain, luego SSL/TLS Status → Run AutoSSL, luego File Manager.

3. Anuncia la política en el DNS.

  • Abre los registros DNS de tu dominio donde se gestiona su DNS: normalmente el registrador del dominio, el proveedor de hosting o Cloudflare.
  • Añade un registro TXT con el nombre _mta-sts y el valor v=STSv1; id=1, y guarda.

4. Pide informes. Los servidores remitentes envían entonces cada día por correo un informe de cualquier entrega cifrada que haya fallado. Crea primero el buzón tls-reports@example.com (o usa otra dirección que leas).

  • Abre los registros DNS de tu dominio donde se gestiona su DNS: normalmente el registrador del dominio, el proveedor de hosting o Cloudflare.
  • Añade un registro TXT con el nombre _smtp._tls y el valor v=TLSRPTv1; rua=mailto:tls-reports@example.com, y guarda.

5. Compruébalo. Abre https://mta-sts.example.com/.well-known/mta-sts.txt: debería mostrar el archivo como texto plano. Después vuelve a ejecutar esta comprobación: lee el archivo y compara sus líneas mx con tus servidores de correo.

6. Unas dos semanas después: aplícala. Cuando los informes no muestren entregas fallidas, cambia el archivo a modo enforce con un max_age de una semana:

mta-sts.txt

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

Después cambia el registro TXT _mta-sts a v=STSv1; id=2, para que los remitentes descarguen el nuevo archivo. Cada cambio posterior del archivo necesita un id nuevo, y cuando cambien tus servidores de correo, actualiza primero las líneas mx. 

Set up MTA-STS (RFC 8461) for the mail domain example.com, starting in testing mode, and TLS-RPT (RFC 8460) reporting.
Its MX hosts (look them up first; this is a placeholder): mail.example.com.

Steps:
1. Serve this policy at https://mta-sts.example.com/.well-known/mta-sts.txt over HTTPS with a valid certificate for mta-sts.example.com, status 200, Content-Type text/plain, no redirect:
   version: STSv1
   mode: testing
   mx: mail.example.com
   max_age: 86400
   Use the web host (a subdomain with its own certificate) or a static host.
2. Add the TXT record _mta-sts.example.com = "v=STSv1; id=1".
3. Add the TXT record _smtp._tls.example.com = "v=TLSRPTv1; rua=mailto:tls-reports@example.com" (make sure that mailbox exists).
4. Verify: curl -sv https://mta-sts.example.com/.well-known/mta-sts.txt (200, no redirect, the policy text) and dig TXT _mta-sts.example.com +short.
5. Tell me to come back in two weeks: if the TLS reports show no failures, switch to mode: enforce with max_age: 604800 and change the TXT record to "v=STSv1; id=2".
Every mx line must match an MX host exactly or by a one-label wildcard (*.example.com); a missing one makes enforcing senders refuse mail.

Resources:
- MTA-STS, RFC 8461 (IETF): https://datatracker.ietf.org/doc/html/rfc8461
- TLS-RPT, RFC 8460 (IETF): https://datatracker.ietf.org/doc/html/rfc8460

Revisa tu sitio para ver si tiene este problema. Revisar un sitio web