Agregar un registro SPF para un tercero, pero no tengo uno para mi propio dominio

Tenemos un servicio de terceros que envía un correo electrónico en nuestro nombre. Están utilizando nuestro nombre de dominio en sus correos electrónicos salientes. Han solicitado que configuremos un registro SPF para ellos.

Actualmente no tenemos un registro SPF definido para nuestro propio dominio, que es el mismo que el tercero está "falsificando".

Mi preocupación es que si agregamos un registro para un tercero sin definir también el nuestro, ese correo procedente de nuestros servidores podría ser rechazado.

¿Es válida mi preocupación?

email spf

— k1DBLITZ
fuente

¿Qué tan difícil será para ti crear uno?

— Michael Hampton

No es difícil. El problema potencial, tal como lo veo, es que hay varios servicios de terceros que estamos utilizando que actualmente están falsificando nuestro dominio y si no agrego registros SPF para todos ellos, que al agregar solo 1 podría invalidar los otros cuando los servidores de correo de recepción aleatoria buscan el registro SPF de nuestro dominio y ven que los nombres / IP no coinciden.

— k1DBLITZ

Respuestas:

Si no tiene un registro SPF, los receptores generalmente fallarán y aceptarán su correo electrónico (aunque eso está comenzando a cambiar). Tan pronto como proporcione un registro SPF, debe incluir a todos los remitentes de correo legítimos, porque de lo contrario, los que no figuran en la lista podrían tratarse como posibles fuentes de falsificación.

Estrictamente hablando, puede incluir ~allo ?allevitar la lista de todos sus remitentes de correo, pero si lo hace, no obtendrá ningún beneficio del registro SPF que no sea para probar que, de lo contrario, es correcto.

Idealmente, sus terceros ya tendrán un registro SPF genérico y puede agregar el include:spf.thirdparty.domelemento a su registro. Si no lo hacen, es posible que desee crear su propio registro para ellos y encadenarlo de todos modos, de modo que sea fácil para usted administrarlo administrativamente.

Por ejemplo, si eres contoso.com:

thirdparty1.spf.contoso.com txt 'v=spf1 ... -all' # list their mail senders for you
thirdparty2.spf.contoso.com txt 'v=spf1 ... -all' # list their mail senders for you
spf.contoso.com txt 'v=spf1 ... -all'             # list your mail senders
contoso.com txt 'v=spf1 include:spf.contoso.com include:thirdpart1.spf.contoso.com include:thirdparty2.spf.contoso.com -all'

Algunos recursos útiles:

DMARC está sumando SPF y DKIM, y vale la pena considerarlo. Google, Yahoo y otros lo utilizan activamente para validar el correo electrónico entrante, https://dmarc.org/overview/
Una lista de las mejores prácticas al configurar un registro SPF, http://www.openspf.org/Best_Practices
A pesar del nombre, una receta útil para configurar un registro SPF, http://www.openspf.org/FAQ/Common_mistakes

— roaima
fuente

¿Tienes una fuente de esto?

— Aaron Hall el

@AaronHall, ¿son suficientes esos enlaces de recursos? Si no, ¿puedes aclarar lo que estás buscando

— Roaima

Puede poner su servicio de terceros en un registro SPF con una regla neutral para otros servidores:

?all

E incluya al menos sus propios servidores de correo con:

+mx

Es bueno tener un registro SPF en su dominio. Comience a agregar una lista blanca y neutral para los demás, y cuando tenga un registro SPF actualizado con todos sus servidores, puede cambiar el valor predeterminado para que falle (-todos) o softfail (~ todos).

Aquí hay una buena documentación y muchas otras informaciones útiles en openspf.org

— mick
fuente

Parte del problema al que me enfrento es que no tengo una lista actualizada de todas las otras compañías que envían correos electrónicos en nuestro nombre. ¿Está diciendo que si uso su enfoque puedo agregarlos a los registros SPF a medida que se descubren sin afectar nuestro flujo de correo de producción? ¿Puede proporcionar una sintaxis de ejemplo específica con dominios ficticios? He estado revisando la información que vinculó y es muy útil, pero no puedo darme el lujo de equivocarme.

— k1DBLITZ

Puede hacerlo paso a paso: primero agregue su servicio de terceros, su mx y neutral para todos los demás: "a: your3rppart mx? All". Luego actualice su SPF con otros servidores. Creemos que los tiene a todos cambiar la política predeterminada a falla suave o falla

— mick

En serio, el SPF externo -allno solo es completamente inútil, sino que algunos administradores lo usan como un signo activo de spammers. No lo hagas

— MadHatter

"todo es mejor entonces -todos si no sabes lo que estás haciendo, las políticas de DMARC todavía se aplican a -todos como -todos y muchos ESP grandes ya no se preocupan -todos por la primera declaración"

— Jacob Evans

En serio, SPF sin -todos no solo es completamente inútil, sino que algunos administradores lo usan como un signo activo de spammers. No lo hagas , entonces deberían corregir sus sistemas dañados que no siguen la especificación SPF; " Si los propietarios de dominios eligen publicar registros SPF, se RECOMIENDA que terminen en" -todos " " - ietf.org/rfc/rfc4408.txt - No es obligatorio. SoftFail es un estado distinto.

— TessellatingHeckler