Mejores prácticas para evitar que parezca un spammer

Question

Me gustaría sentirme más seguro al configurar el correo para mis clientes con respecto a los falsos positivos. Esto es lo que sé:

1. Los registros SPF son buenos, pero no todos los servicios/software de filtro de spam (SFSS) los utilizan.

2. Los registros DNS inversos (PTR) son prácticamente una necesidad.

3. Los relés abiertos son malos.

   (Aquí hay "otros consejos" que he leído):

4. la búsqueda inversa de la dirección IP de su servidor de correo debería resolverse en el dominio desde el que envía el correo.

5. su servidor debería decir HELO FQDN.of.your.mail.server.com cuando hable con otros servidores de correo.

6. los registros del host A en los registros MX deben ser (o resolverse en la dirección IP) su FQDN.of.your.mail.server.com

Me siento bastante bien con 1 y 3. Aquí es donde me gustaría algunas aclaraciones/sugerencias:

2 y 4: Investigué mucho y esto parece ser incorrecto ya que la mayoría de los filtros de spam buscan un PTR engeneraly uno que no esté asignado genéricamente por el ISP; no parece que el dominio al que envía el correo tenga algo que ver con esto (es decir, si tuviera dos dominios que usara para el correo, ¿necesitaría enviar desde dos direcciones IP con PTR para cada una?)

5. Esto tiene sentido, pero ¿le importa a qué se resuelve ese FQDN? ¿Debería resolverse en la dirección IP que actualmente envía dicho HELO?

6. De nuevo, otro de varias búsquedas en Google; No veo cómo funcionaría esto si usara Postini como servicio de puerta de enlace (o cualquier otro host inteligente).

¿Y qué pasa con el envío en nombre de otro dominio para el que no tienes autoridad? Tengo algunos clientes (some.branchdomain.tld) ​​que deben enviar correo como @some.corporatedomain.tld, aunque dicha sede corporativa no configurará un relé/host inteligente para que lo utilicen. Corporatedomain.tld puede crear registros SPF para mostrar que some.branchdomain.tld tiene permiso para enviar correo, pero ¿seguiría considerando eso una "suplantación de identidad", especialmente si dicho SFSS no verifica los registros SPF? ¿Debería preocuparme por esto?

Answer 1

Puedo dar fe de que el n.º 2 (PTR inverso) es importante, pero no el n.º 4 (el dominio del servidor de correo coincide con "de"). Configuramos servidores de correo todo el tiempo, y a la mayoría de los servidores de correo ni siquiera les importa el número 2.

La espina principal siempre es AOL, y enumeranestándarespuedes marcar.

Answer 2

Aparte de su cadena HELO y los registros DNS PTR como se mencionó, la mayor parte de las cosas que ayudarán estarán relacionadas con el contenido, no con el servidor de envío.

• No envíe correos electrónicos HTML si puede evitarlo.
• No incluya frases sospechosas ("haga clic para cancelar la suscripción", "la privacidad es importante" y similares)
• No utilice encabezados de "respuesta a", envíe desde la dirección a la que desea que lleguen las respuestas
• ...y más. Lea el conjunto de reglas de SpamAssassin para obtener más buenos ejemplos.

En cuanto a su pregunta de "¿le importa en qué se resuelve ese FQDN?", esto depende completamente de lo que haga el servidor de correo receptor y, por supuesto, puede variar, pero normalmente no encontrará demasiados servidores de correo que dependan del La búsqueda de FQDN es una regla estricta y rápida, ya que es posible tener varias máquinas configuradas en una configuración por turnos.

Answer 3

¿Qué tal las pautas de contenido? Mantener el correo electrónico sensato le ayudará a evitar que varios sistemas le marquen como productor de spam. Capacite a sus clientes para que eviten reenviar "cosas divertidas" a todos los que están en su lista de contactos, no se registren para recibir resúmenes de correo electrónico o boletines informativos y utilicen mecanismos sensatos de protección contra malware para evitar convertirse en parte de una botnet de spam...

Answer 4

4 es en realidad totalmente falso. Quizás estés pensando más en la línea deMarco de políticas del remitente, en el que el DNS de un dominio contiene un registro que indica qué servidores SMTP pueden enviar correo con un encabezado De: con ese nombre de dominio. Pero el quid de la cuestión es que los dominios alojados suelen tener servidores de correo saliente que sonnoLo mismo que el nombre de dominio, pero el ISP del remitente. Por ejemplo, si tiene myvanitydomain.com y la dirección de correo electrónico[correo electrónico protegido], pero usas Sprint para tu proveedor de Internet, generalmente tendrás que usar el servidor de correo saliente de Sprint para enviar correo electrónico. Hay formas de evitar esto (como el correo web o la autenticación POP y luego SMTP), pero ese es un buen ejemplo.

En cuanto a "cómo hacer que el correo electrónico no parezca spam", bueno... no haces que parezca spam, por supuesto. El hecho de que siquiera consideres usar un relé abierto suena... sospechoso. No puedo pensar en una sola razón legítima por la que siquieradeseara, cuando cada ISP tiene un servidor SMTP. Si paga por el alojamiento del servidor desde el que envía correo, la forma de evitar que varias autoridades incluyan su dirección IP es no enviando spam.