¿Qué tan importantes son los registros PTR para los servidores de correo electrónico?

¿Alguien sabe de algún estudio realizado para mostrar cuánto correo electrónico será rechazado si no hay un registro ptr para el nombre del banner SMTP de un servidor de correo electrónico?

¿Las verificaciones inversas siempre se realizan cuando están habilitadas, o a veces se configuran de modo que si un programa de spam considera un correo electrónico 'dudoso', se realiza la verificación inversa?

Me esforzaría al máximo para que la búsqueda inversa de la dirección IP de mi servidor de correo electrónico resuelva el nombre que está usando en las conversaciones SMTP. Hace la vida más fácil.

No tengo ninguna evidencia estadística para apoyar esto, pero ha sido mi experiencia que, de vez en cuando, los mensajes serán rechazadas por algunos programas de correo remoto para no tener una búsqueda inversa que concuerde con el nombre utilizado en conversaciones SMTP. En lugar de tener que lidiar con este problema, es más fácil comenzar con la configuración de búsqueda inversa. Durante los últimos años, he tratado de tener una búsqueda constante hacia adelante / atrás como un requisito para no tener que lidiar con el problema de no tenerla.

Si no lo tiene configurado, recibirá un correo electrónico legítimo marcado. Depende del dispositivo de filtrado de spam cómo hacen sus comprobaciones y no hay estándares claros definidos, por lo que es impredecible. Pero en la mayoría de los casos con un puntaje de spam, eliminarán sus correos electrónicos cuando no tenga una búsqueda directa e inversa coincidente. Ese ding por sí mismo a menudo no obtendrá los bloqueos de correo electrónico (pero no promesas), pero alguna otra preocupación leve en el correo electrónico puede llevarlo a la cima.

No solíamos tener un registro PTR específico para nuestro servidor de correo y recibíamos rebotes de craigslist.org y algunos de nuestros socios comerciales.
También debe tener un registro A específico para su entrada MX. No se permiten * o CNAMES para algunos servidores de correo estrictos.

Cuando dices "nombre de banner", es algo engañoso. El banner es el nombre en el lado del servidor, que es el lado que decide qué rechazar. :) Creo que te refieres al nombre que da el lado emisor en el comando HELO / EHLO?

La mayoría de los lugares solo hacen verificaciones de sintaxis y rechazan HELO / EHLO obviamente malos, porque hay demasiada basura rota por ahí. Pero si está ejecutando un servidor de correo legítimo, solo debe dar el nombre de host público de su propio servidor de correo en la HELO que envía. Hay algunos que sí comprueban. Y dado que ese nombre de host debe tener un DNS inverso en funcionamiento, para que su conexión TCP no sea rechazada de inmediato por muchos MTA, en efecto, debería tener un DNS inverso en funcionamiento para el nombre dado.

Por lo tanto, no hay dificultades de configuración para obtener un DNS que funcione para el nombre de host HELO más allá de la clasificación del DNS inverso para la accesibilidad general de todos modos.

Como dijo Evan, su mejor opción es que su entrada PTR se resuelva de nuevo a la dirección IP de su servidor.

Sin embargo, si por alguna razón esto no es posible, el PTR debería sugerirle que está utilizando una dirección IP asignada estáticamente, no una línea DSL doméstica (no comercial). Como parte de su estrategia anti-spam, muchas organizaciones usan servicios de reputación (por ejemplo, SORBS), que monitorean los rangos de direcciones IP para detectar actividad de botnet y mantienen listas negras de rangos de IP. Sin embargo, no importa si hay actividad sospechosa o no, generalmente incluyen sus Listas de usuarios dinámicos (DUL) en su lista negra. Para crear estos DUL, utilizan registros PTR y expresiones regulares, específicamente diseñados para los esquemas de nombres de muchos ISP grandes.

Por ejemplo, un PTR similar cable-66-103-40-69.clarenville.dyn.personainc.netprobablemente se incluirá automáticamente en una lista negra (coincide con "dyn", por lo que debe ser dinámico). Hay algunos esfuerzos de estandarización en la denominación inversa de DNS en el IETF, con un éxito mixto:

http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes

http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations

Un poco fuera del tema, otra fuente de información para las listas negras / blancas son los registros SWIP de WHOIS .