SPF: ¿debo implementarlo?

Un desarrollador web ha realizado una solicitud para que nuestros registros DNS de dominio incluyan registros SPF TXT. Encontré opiniones diferentes sobre esto ...

Cualquier comentario o información que pueda ofrecer será muy apreciada. Sé que esta no es una pregunta empírica per se, pero agradecería sus ofertas subjetivas, sin embargo ... Especialmente si vinieran con referencias que pudiera consultar, como publicaciones web o documentos en línea, etc.

Si. No llamaría esto subjetivo porque hay un claro consenso; use SPF .

La implementación es muy fácil y es algo bueno para Internet en su conjunto.

Probablemente esté viendo referencias fechadas. Según el porcentaje de correo electrónico válido que mi servidor recibe de los servidores que usan SPF, el consenso es usar SPF.

Recomiendo encarecidamente configurar SPF. Configure registros para su MX que le permitan enviar correos electrónicos, así como para el dominio que usa en las direcciones de correo electrónico. Para dominios que no envían SPF de configuración de correo electrónico para indicar que

Encuentro que los registros SPF para el servidor de correo electrónico son más útiles y confiables para bloquear el spam que los de la dirección de correo electrónico del remitente.

Si su servidor admite registros SPF, configúrelos además de los registros TXT. Si cambia su configuración, puede haber un poco de sobrecarga para mantener los registros sincronizados, pero muchos sistemas pueden configurar su SPF para que se ajuste automáticamente a MX y cambios de dirección.

Es posible que desee revisar mi publicación sobre Cómo asegurar su reputación de correo electrónico con SPF . Mi primera implementación de SPF fue bloquear un spammer que estaba falsificando un dominio para el que proporciono servicios de correo electrónico. A pesar de la relativamente baja penetración de SPF, fue muy eficaz para apagarlos. Sin embargo, todavía recibimos spam en la dirección falsificada que crearon. (Es una excelente manera de verificar los spammers ya que solo los spammers usarían esa dirección).

Creo que la penetración de SPF en el lado receptor es probablemente mayor que en el lado editorial.

EDITAR: si utiliza registros SPF, asegúrese de que las personas que envían correos automáticos estén conscientes del requisito de agregar sus servidores. (El servidor debe investigarse por completo, ya que los sistemas automatizados a menudo están mal configurados y pueden tener un perfil similar a un robot de spam. No es tan difícil configurar el servidor correctamente).

Definitivamente configure SPF: no debería haber inconvenientes (siempre que esté configurado correctamente y probado), pero evitará que otros sitios se enmascaren como usted y envíen spam en su nombre. La razón por la que es bueno es que está haciendo una lista blanca explícita de ciertos servidores / IP que pueden enviar correos electrónicos para su dominio.

Creo que la mejor prueba de que es bueno es mirar algunos de los principales servicios de correo electrónico. Simplemente busque los encabezados 'Received-SPF' en el correo electrónico original para ver si SPF está marcado. Por ejemplo:

Correo de yahoo:

Received-SPF: pass (domain of example.com designates xxx.xxx.xxx.xxx as permitted sender)

Gmail

Received-SPF: pass (google.com: domain of [email protected] designates xxx.xx.xx.xx as permitted sender) client-ip=xxx.xx.xx.xx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates xxx.xx.xx.xx as permitted sender) [email protected]

Hotmail también verifica SPF (aunque, creo que lo llaman Id. De remitente). En general, es una adición fácil que puede hacer mucho bien, tanto para su dominio como para Internet en general.

Como los otros encuestados (hasta ahora), recomiendo implementar SPF.

Algunas de las otras publicaciones han mencionado que esto hace que sea más difícil para otras personas hacerse pasar por usted (pero eso no significa que SPF sea la base para el no repudio ). Incluso si el impacto directo de tal evento es muy bajo, ayuda a reducir la dispersión inversa .

Sin embargo, otra razón muy importante es que mejora la capacidad de entrega a los destinatarios cuyos proveedores implementan SPF.

Sin duda me interesaría saber cuáles son las desventajas de SPF. Actualmente todo lo que sé son:

1. los usuarios deben enrutar su correo saliente a través de los servidores designados; aunque controlar el correo saliente tiene beneficios obvios, esto puede agregar algunas complicaciones si tiene usuarios remotos; deberá configurar la autenticación SMTP o una VPN

2. problema con algún reenvío, que IME es muy raro

El gran problema que veo con SPF es que es el reenvío de interrupciones. Hasta el momento, esto se menciona brevemente en la entrada de Wikipedia de SPF . Y también es la razón por la que no configuro SPF en mi servidor de correo.

Considere que A con dirección [email protected](quién MX implementa SPF) envía un correo a B con dirección [email protected]que configuró esta dirección para reenviar correos [email protected]. El MX para reallyb.orgentonces ve el correo de A que se origina en b.orgel MX de 's y, por lo tanto, se le permite tirar el mensaje.

Por lo tanto, si desea continuar pudiendo enviar correos electrónicos a las personas que usan el reenvío como solía funcionar en las décadas anteriores a la aparición del SPF, al menos no lo use -all.

Esto podría solucionarse si el MX para SRSb.org usado o si el MX para listas blancas envía correos . Sin embargo, según mi punto de vista sobre la realidad, la mayoría de los transitarios no hacen ninguno de estos dos. Y como está en la posición de A si piensa implementar SPF en su servidor, esto es algo que no puede controlar en general.reallyb.orgb.org