☰

¿El formato de registro PTR afecta la reputación del servidor de correo?

tag-icon • tag-icon linux domain-name-system bind
¿El formato de registro PTR afecta la reputación del servidor de correo?

Quería saber si el formato del registro PTR afecta la reputación del servidor de correo, por ejemplo:

Ejemplo: -1

dig -X 162.254.148.198  (this ip belongs to mail.setopati.com)

;; ANSWER SECTION:
198.148.254.162.in-addr.arpa. 21577 IN  PTR 162-254-148-198.static.hvvc.us.

Ejemplo:-2 (este ejemplo hipotético)

dig -X 162.254.148.198
;; ANSWER SECTION:
198.148.254.162.in-addr.arpa. 21577 IN  PTR 162-254-148-198.mail.setopati.com.

Aquí hay algunos registros inversos de Googlemail, pero la respuesta no coincide con algo como "mail.google.com" dig -x 216.58.220.37

;; ANSWER SECTION:
37.220.58.216.in-addr.arpa. 21599 IN    PTR maa03s18-in-f37.1e100.net.
37.220.58.216.in-addr.arpa. 21599 IN    PTR maa03s18-in-f37.1e100.net.
37.220.58.216.in-addr.arpa. 21599 IN    PTR maa03s18-in-f5.1e100.net.

Respuesta1

Hay digamos... 4 factores... el único detrimento directo a la reputación es el PTR dinámico de IPv4 y FCrDNS para IPv6.

  1. PTR dinámico vs estático, si tienes un PTR estático que es mejor que uno dinámico, eso te dará algunos puntos positivos en sistemas comoasesino de spamo rbl es como ignorante de rfc.

  2. FCrDNS, beneficioso para cosas como TLS oportunista, registros, flujos de red, etc.

    correo.ejemplo.com. EN A 162.254.148.198 198.148.254.162.in-addr.arpa. 21599 EN PTR correo.ejemplo.com.

  3. ¿Qué pasa con el SPF? ¿Utiliza PTR en su registro SPF? Si lo haces, NO LO HAGAS.

5.5. "ptr" (no usar)

Este mecanismo prueba si existe la asignación inversa de DNS y apunta correctamente a un nombre de dominio dentro de un dominio en particular. Este mecanismo NO DEBE publicarse. Consulte la nota al final de esta sección para obtener más información. -RFC7208 Sección 5.5

  1. IPv6!!!! Ahora nadie ha tocado esto para el correo electrónico, debes tener FCrDNS para IPv6.

La IP de envío debe tener un registro PTR (es decir, un DNS inverso de la IP de envío) y debe coincidir con la IP obtenida mediante la resolución DNS directa del nombre de host especificado en el registro PTR. De lo contrario, el correo será marcado como spam o posiblemente rechazado. -google.com

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1h IN PTR mail.example.com.
mail.example.com. IN AAA 2001:db8::1

Respuesta2

Repito mi afirmación anterior: a nadie (*) le importa cuál PTRes el formato de texto de una cadena de registro.

Lo que elloshacerLo que más te importa es que tútenerun PTRregistro asociado con la dirección IP de su servidor, y que cualquier PTRregistro que devuelva para esa dirección, a su vez puede resolverse para proporcionar un Aregistro que apunte a la dirección IP original.

(*) En realidad, a cualquiera le puede interesar. Depende del administrador del servidor de correo en qué factores basa la decisión de aceptar/rechazar/archivar erróneamente tomada para cada correo electrónico entrante, y supongo que podría decidir que los PTRregistros que no incluían (por ejemplo) nombres de flores eran los signo de un remitente no válido. No se podría hacer nada al respecto, si se hiciera, pero sería una elección poco común (por decir lo menos) y encontraría poco apoyo en la comunidad si se pidiera al administrador del servidor que lo justificara ante el público. propietarios del servidor. En mi experiencia, también lo serían las restricciones en el formato de texto de un PTRregistro.

Respuesta3

La reputación del servidor de correo no es algo estándar (aunque existen algunos RFC comoRFC7073 que apuntan a estandarizarlo pero ni siquiera menciona el registro PTR)

Por lo tanto, no es posible responder a esta pregunta, ya que cada sistema de protección contra spam tendrá su propio conjunto de reglas para evaluar la reputación de un sistema de correo.

Como dijo MadHatter, lo único "oficial" es que el registro devuelto por la búsqueda inversa debe resolverse a la IP original.

información relacionada