¿Cuál es el mejor método para enviar correos electrónicos en nombre de los dominios de mis clientes?

Quería saber la mejor manera de hacer que mi servidor de correo envíe correos electrónicos en nombre de los dominios de mis clientes, sin estar en la lista gris y también evitando problemas de rebote.

He estado leyendo algunas otras preguntas aquí , aquí y aquí, pero ninguna explora todas las soluciones posibles. Aquí hay algunas posibilidades que me gustaría comparar:

A.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Pregunta : Esto es lo que hace gmail. Es el encabezado msg "De:" que tiene un dominio diferente, no el remitente del sobre.
los clientes de correo electrónico mostrarán "De: res@client.com a través de do-not-reply@myapp.com" o "De: do-not-reply@myapp.com en nombre de res@client.com" , lo cual no es un problema para mi.
Ahora, ¿afectará esto mal la reputación de mi dominio, el hecho de que el encabezado "De:" tiene un dominio diferente? (y si no es Google quien lo está haciendo ..)

SI.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Parece que Google hizo esto una vez y lo llamó un error http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + de% 22 & pli = 1
Un error eliminó el "Remitente:" de sus mensajes y la "vía" no apareció en el cliente de correo electrónico. (El RFC dice que DEBE estar presente si no es lo mismo que "De:")

C.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

Es como si client.com estuviera enviando el mensaje (el CORREO DE "también es falso"). Pero si el dominio client.com es conocido o tiene una entrada SPF en su DNS, tendría que alterar su DNS, permitiendo que mymailserver.com envíe un mensaje en su nombre. (Esto es imposible para mí debido a la nb . de clientes, y también algunos de mis clientes no tienen control sobre sus dominios, es decir, están utilizando @ gmail.com ellos mismos)

RE.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Pregunta : Esta es la más simple, solo agregaría un encabezado "Responder a:". ¿Es esto realmente tenido en cuenta TODO EL TIEMPO por los clientes de correo electrónico? ¿Se puede percibir esto también como una suplantación de identidad, agregando diferentes dominios al encabezado "Responder a" y ser una mala influencia para la reputación de mi dominio?
- El RFC solo dice que "si existe el campo Responder a, la respuesta DEBE ir a las direcciones indicadas en ese campo y no a las direcciones indicadas en el campo De".
- Solo la etiqueta del encabezado "De:" sería "falsificada":
"De: myclient.com (a través de myapp.com) <do-not-reply@myapp.com>".

Excelente pregunta Acabo de pasar varias horas investigando lo mismo.

Anteriormente había implementado numerosos sitios web que usan la Opción C para formularios de correo electrónico (principalmente por ingenuidad), pero estamos experimentando un número creciente de problemas de entrega. Los proveedores de correo electrónico están apretando gradualmente las cosas. Por ejemplo, Yahoo cambió recientemente su política de DMARC para solicitar a los receptores que rechacen todos los correos electrónicos From: ____@yahoo.comsin una firma DKIM válida . Recibir servidores SMTP que sigan DMARC (que incluye Gmail, y probablemente Hotmail / Outlook.com y Yahoo) rechazarán estos mensajes. eBay y Paypal tienen políticas estrictas similares, creo, en un intento de reducir el phishing. Desafortunadamente, especificar un encabezado "Remitente" no ayuda.

(¡Me pregunto cómo funciona Gmail para solucionar esto al enviar "De" un alias de Yahoo ?!)

La opción A sería una mejor opción si sabe que el correo electrónico "De" no tiene una política estricta de DMARC (posiblemente podría confirmar esto mediante una simple consulta DNS).

A pesar de ser la menos atractiva visualmente, la Opción D es realmente la más segura y es lo que recomendaré para la mayoría de nuestros proyectos futuros. Vale la pena señalar que PayPal utilizado previamente la opción A, pero ahora han cambiado a la opción D .

Para obtener credibilidad adicional y una mayor probabilidad de entrega, me gustaría implementar SPF y / o DKIM. Estas y otras cosas se mencionan en las Pautas de remitentes masivos de Google que encontré útiles.

No estoy seguro de lo que quieres. No hay una forma "segura" o "insegura" de hacer lo que desea.

Siempre preferiría D). Además, agregaría registros SPF. Pero como dije, esto no es más seguro o más inseguro que los demás (lo que sea que quieras decir con eso).

El encabezado Reply-To no influye en la reputación de ninguna manera. Solo le aconseja al cliente que use esa dirección para las respuestas (Duh, ¡¿quizás de aquí viene el nombre ?!). Si el cliente sigue esta recomendación no está garantizada.

Dos soluciones confiables:

1. solicite a los clientes que agreguen su servidor de correo en su registro de dominio SPF
2. solicite a los clientes que le proporcionen las credenciales de una cuenta de correo electrónico (su IP del servidor de correo, nombre de usuario, contraseña) y utilícelas dentro de su aplicación para conectarse a su servidor de correo y enviar correos electrónicos (en realidad, crea un cliente de correo electrónico dentro de su aplicación).