distintos servidores de correo y alojamiento web con múltiples dominios; Registros para evitar spam, PTR y SPF

Question

Contexto.

Tengo servicios web de varios dominios alojados en una gota de Digital Ocean (Ubuntu y Nginx en pila). Aparentemente, DO configura automáticamente un registro PTR. Sin embargo, cuando pregunto

host <IP_ADDRESS>
[...] not found: 3(NXDOMAIN)

El droplet utiliza postfix, configurado como donde inet_interfaces = all inet_protocols=ipv4, mientras que mydestinationincluye los dominios de servicios web alojados (con y sin prefijo www). Estos dominios emiten correos electrónicos a través de sendmailun host definido comoscheduler.sending.ws

El servicio de correo y DNS se ejecuta a través de un segundo proveedor (que NO es el registrador registrado para el dominio de segundo nivel). En primer lugar, noté que un registro A apunta a la dirección IP adecuada pero con un error tipográfico schedule.sending.wsque se puede corregir, aunque no estoy seguro de que esto sea del todo pertinente.

El registro MX apunta correctamente al segundo proveedor. mail.sending.ws También hay dos registros TXT para @y adminque apuntan a v=spf1 a mx ptr include:someserver.net ~all.

Esto lleva a que se generen correos electrónicos con el siguiente encabezado con unaleatoriodominio definido en mydestinationel archivo postfix main.cf:

Received: from www.other.ws ([IP_ADDRESS]:46818)

Se trata, pues, de dos referencias emisoras diferentes, situación que fácilmente puede dar lugar a que se marque como spam.

Por favor, disculpe mi total confusión y romper el protocolo de hacer múltiples preguntas.
Mi suposición actual es que:
a) ¿es necesario configurar una nueva entrada DNS TXT para el dominio emisor, como por ejemplo v=spf1 a mx include:scheduler.sending.ws include:someserver.net ~all:?
b) si a) es correcto, naturalmente el registro A debe corregirse
c) la falta de coincidencia en los encabezados aún debe resolverse. Pero esto ciertamente debe ser especificado por la aplicación (y por lo tanto el dominio específico) que prepara el correo electrónico con uno de los dominios definidos por Postfix... ¿Postfix seguirá el juego?

¿Falta algún dato para abordar adecuadamente este problema?

Answer 1

Para la situación general, debería seguir algunos tutoriales para realizar una configuración básica que funcione en lugar de probar configuraciones aleatorias sin una comprensión adecuada de cómo funciona el correo electrónico. Después de todo, administrar un sistema de correo electrónico es una tarea complicada y desafiante en la actualidad. Para cualquier persona sin una gran experiencia y con necesidades especiales de un servidor de correo electrónico propio, se recomienda utilizar un servicio externo que tenga todos los sistemas de prevención de spam necesarios y manejo de la reputación del remitente listo para usar.

Responder a sus preguntas separadas y brindar orientación para aprender las tecnologías detrás. En esta respuesta, lo usaremos www.example.com. A 192.0.2.1como servidor web y mail.example.com. A 192.0.2.2como servidor de correo para el correo entrante. Ambos necesitan enviar correo, pero solo mail.example.comlo reciben, ¿verdad?

• a) No. El SPFincludemecanismono es para ese propósito. include:scheduler.example.comsignifica que hay más reglas, es decir, otros registros SPF en scheduler.example.com. TXT. Como probablemente no exista tal registro, se produciría un PermError, lo que posiblemente provocaría el rechazo del mensaje.

  El registro SPF debe permitir que todos los servidores envíen correo para el nombre de host correspondiente. Si usas example.com, lo tienes encendido example.com. TXT, para www.example.com.encendido www.example.com. TXT. Se recomienda utilizar elip4yip6mecanismos siempre que sea posible, ya que requiere menos consultas de DNS al verificar SPF. Esto daría como resultado:

  example.com.      IN TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
  www.example.com.  IN TXT  "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ~all"
  

• b) Para la entrega de correo entrante,scheduler.example.com. A es irrelevante a menos que se haya utilizado comointercambiador de correopor ejemplo example.com. MX scheduler.example.com., pero probablemente solo lo haya mail.example.com.si lo usas como HELOnombre de host, deberías tener elA registro para evitarlo.El banner SMTP no coincide.

• c) El HELOnombre de host coincide con el parámetro de configuración de Postfixsmtpd_banner. Por defecto, tiene lamyhostnamecomo variable, es decir, es la misma que tienes myhostname. No tiene mydestinationnada que ver con esto, y nada elige un nombre de host aleatorio de esa configuración: es para entregar correo, no para enviarlo.

  Se requiere que el HELOnombre de host tenga un Aregistro coincidente y se recomienda que sea el mismo que elPTR de la dirección IP. No es necesario que coincida con elremitente del sobredominio ni la From:dirección del encabezado. En un servidor de correo electrónico multidominio eso también sería imposible.

Para problemas de buen estado del dominio de correo, se recomienda utilizar el dominio real para que podamos comprobar qué está pasando. Esta pregunta es amplia y no especificada: es imposible dar una respuesta precisa o general.