Correo

Cómo dejé el correo de mi dominio en 10/10 en mail-tester

El correo de oscarcopado.com llevaba tiempo sin llegar. Así lo arreglé: recibir sin romper el remitente, enviar autenticado y firmado, y un servidor que dice quién es.

El reto
El MX apuntaba a un servidor que ya no existía y los correos a @oscarcopado.com se perdían sin avisar.
La solución
Recepción con un reenviador que respeta el remitente, envío por SMTP propio con DKIM, SPF y DMARC, y el nombre del servidor alineado en PTR, HELO y certificado.
El resultado
10/10 en mail-tester enviando desde el servidor.

El punto de partida

El registro MX de oscarcopado.com apuntaba a un servidor antiguo que ya no estaba en marcha. No había rebotes que yo viera: el correo, simplemente, no llegaba. Es el fallo más traicionero, porque no avisa. Y era la dirección que pongo en la web y en mi firma.

El objetivo era doble: recibir en mi Gmail lo que llegue a @oscarcopado.com, y enviar desde Gmail con esa dirección sin acabar en la carpeta de spam de nadie.

Recibir sin romper el remitente

La primera opción fue la redirección de correo que ofrece el proveedor de DNS. Funciona, pero reescribe el remitente: todos los mensajes llegan como si los enviara la misma dirección técnica. Lo hace a propósito, porque reenviar el correo tal cual haría fallar DMARC a muchos mensajes, pero en la práctica pierdes de vista quién te escribe.

La cambié por un reenviador que usa SRS (Sender Rewriting Scheme). SRS cambia solo el remitente del sobre, el que usan los servidores entre sí, para que el reenvío sea legítimo. El remitente que ves y la firma DKIM original llegan intactos: DMARC sigue pasando y contestas como a cualquier otro correo.

Enviar autenticado y firmado

Para escribir desde Gmail con mi dirección uso «Enviar como» a través del SMTP de mi propio servidor, por el puerto 587 y con TLS obligatorio antes de autenticarse.

En el servidor hay un único usuario para esto, aislado del resto: no es una cuenta del sistema y solo puede enviar con mi dirección. Aunque alguien consiguiera la contraseña, no podría usarlo para hacerse pasar por otra dirección.

Cada mensaje sale firmado con DKIM, y el DNS del dominio publica las tres piezas que miran Gmail y Outlook:

@                    TXT "v=spf1 ip4:<IP> include:spf.improvmx.com ~all"
server02._domainkey  TXT "v=DKIM1; k=rsa; p=…"
_dmarc               TXT "v=DMARC1; p=none; …"
  • SPF dice qué servidores pueden enviar en nombre del dominio: el mío y el reenviador.
  • DKIM firma cada mensaje para demostrar que nadie lo ha alterado por el camino.
  • DMARC indica qué hacer con lo que no pase esas comprobaciones. Lo dejé en p=none, que solo observa; se endurece cuando hay historial.

El servidor dice quién es

Un detalle que se pasa por alto a menudo: el nombre con el que se presenta el servidor. Al entregar un correo saluda con un nombre (el HELO); el receptor pregunta a qué nombre corresponde su IP (la resolución inversa, o PTR), y el certificado TLS lleva otro. Si no coinciden, suma puntos de spam.

Lo dejé todo alineado en mail.oscarcopado.com: el PTR de la IP, que se cambia en el panel del proveedor del servidor y no en el DNS del dominio; el saludo de Postfix, y el certificado de Let’s Encrypt.

Los errores que no repetiría

Cambiar el MX y retirar lo antiguo a la vez. Durante la hora que dura la caché del DNS (el TTL), Gmail siguió entregando al destino anterior, que ya no aceptaba el correo, y los mensajes rebotaron con «554 Relay access denied». El orden bueno: cambiar el MX, esperar a que caduque el TTL y solo entonces retirar lo antiguo.

Hubo también una falsa alarma: un correo de prueba enviado de mí a mí mismo, y reenviado, acabó en spam en Gmail. No era la configuración, sino el camino de reenvío más la falta de historial del remitente. Para medir, mejor una herramienta como mail-tester, enviando directo desde el servidor.

Y una lección del mismo servidor: un contenedor Docker con su propio Postfix interno sacó un correo de prueba con un nombre de servidor falso. Bastó una conexión para que Spamhaus listara la IP. Se resolvió cortando la salida al puerto 25 desde los contenedores y pidiendo la retirada, que llegó esa misma noche. Los contenedores también envían correo, aunque no lo parezca.

Resultado

10/10

  • SPF, DKIM y DMARC correctos
  • PTR, HELO y certificado con el mismo nombre
  • Fuera de listas negras

Enviando desde el servidor, mail-tester dio 10 sobre 10. Y lo más importante: el correo que llega a @oscarcopado.com vuelve a llegar, con su remitente de verdad.

Cuando los correos no llegan casi siempre hay una causa concreta: un SPF que no incluye a quien envía, una firma DKIM que no coincide, un PTR genérico o una IP en una lista negra. Se mide, se corrige y se vuelve a medir.

¿Te pasa algo parecido?

Cuéntamelo y te digo cómo lo haría, cuánto tardaría y cuánto costaría, sin compromiso.

Sigue leyendo

Integraciones Un ERP de transporte que habla con el puerto de Valencia Desarrollo web Sala de espera virtual: que la web aguante el día de la venta
Contacto

¿Hablamos?

¿Tienes una idea por construir, una plataforma que se ha quedado corta o una red que da sustos? Cuéntamelo. Te digo cómo lo haría, cuánto tardaría y cuánto costaría, sin compromiso.

O escríbeme directamente: