Cualquier problema si PHP mail () server de correo no MX de dominio FROM?

Supongamos que tengo este escenario:

Mi server de correo (y por lo tanto MX) para mi dirección de correo electrónico me@company.com está alojado en mi oficina.

Mi website company.com está alojado en una empresa de alojamiento web de terceros.

En mi website creé un <form> con FROM, TO, SUBJECT, BODY y envío usando PHP mail () a los clientes.

Dado que el server web es de terceros, PHP mail () utiliza el server de correo localhost.

Creo que mis correos llegarán al server de correo del cliente y aparecerán como "forjados" o como spam.

¿Qué debo hacer para asegurar que mis correos aparezcan legítimos y los correos entrantes no se enviarán al host de terceros?

3 Solutions collect form web for “Cualquier problema si PHP mail () server de correo no MX de dominio FROM?”

Sus posts estarán sujetos a las políticas de los dominios receptores: las únicas personas que pueden decirle "Lo que [usted] necesita hacer para asegurar que sus correos aparezcan legítimos" son los administradores de correo en esos sitios.

Algunas sugerencias:

  1. Asegúrese de que su formulario de correo es razonablemente seguro – No desea involuntariamente convertirse en un spammer.
  2. Asegúrese de que sus direcciones FROM y REPLY-TO apunten a los lugares que desee rebotes / respuestas / etc. ir
  3. Asegúrese de que su server web aparece en el logging SPF de su dominio
  4. Configure correctamente DKIM , si así lo desea.
  5. Si va a enviar correo masivo hablar con el postmaster / correo masivo de personas en los sitios más grandes (Yahoo, Google, Hotmail, etc)
  6. (Opcionalmente) Configure su server web para que utilice su MX normal como Smart Host / Relay.

Debe agregar un logging SPF Sender Policy Framework a su dominio. El logging SPF es un file txt agregado a su dominio que especifica quién tiene permiso para enviar correo electrónico para ese dominio. En este caso, agregaría su server web.

He aquí un ejemplo: example.com. TXT "v=spf1 a:mail.example.com -all" example.com. TXT "v=spf1 a:mail.example.com -all"
Este logging dice que sólo mail.example.com se le permite enviar correo para el dominio example.com.

La mayoría de las grandes empresas de correo electrónico público tienen pautas para el correo masivo. Aquí está AOL . Siga sus directrices para garantizar la mejor entrega.

Compruebe si su server web está en una list negra de correo electrónico aquí . Las lists negras son por IP, por lo que puede haber obtenido una sin saberlo. Una vez configuré un server de VoIP para un cliente, que entonces quería que las indicaciones de correo de voz se enviaran por correo electrónico. Es en este punto que descubrimos que su IP estaba en una list negra de correo electrónico, y tuvimos que get una nueva IP para el server.

Dado que el server web será el que envía los correos, su reputación es lo que determina cómo el correo es manejado por el destinatario. Cosas como lists negras, DNS inverso correcto, SPF, Domainkeys, etc, todos juegan un papel en esta decisión. No creo que los loggings MX se tengan en count. Depende enteramente del server de correo del destinatario, y sólo puede seguir las mejores prácticas para serveres de correo.

En su lugar, sugeriría retransmitir todos estos posts de correo salientes a través de un server de correo dedicado. Es mucho más fácil asegurar una buena reputación para un solo server de correo, especialmente una vez que tenga varios serveres web que no controla completamente.

Si usted tiene control sobre el mailsoftware en el web server usted debe fijarlo a la relevación vía su propio mailserver. No se olvide de configurar su propio server de correo para permitir la retransmisión de los IP de los serveres web. Si no controla el mailsoftware, puede configurar el command mail () de PHP para enviar correo directamente a su server de correo.

También puede utilizar un service dedicado a este tipo de correos transaccionales. Ellos se encargarán de la reputación, rebotes, lists negras, etc para usted. Entrega de correo electrónico es un trabajo duro, y algunas empresas se especializan en él. Proporcionan varias opciones, como un relé SMTP o una API para enviar directamente desde PHP con seguimiento de entrega avanzado, soporte para cancelar la suscripción, etc.

sendgrid.com es el que usamos, pero otros populares son postmarkapp.com o authsmtp.com . Rackspace proporciona una count gratuita de SendGrid de hasta 40k correos electrónicos al mes. Amazon tiene su service de correo electrónico simple con un nivel gratuito para sus clientes de alojamiento. Pregunte a su proveedor de alojamiento si ofrecen smtp relé, o si tienen una oferta especial con una de estas empresas.

  • En un server de correo secundario, las counts se reflejan
  • Los correos enviados desde otro server de correo dentro de la networking son rechazados (ha sido negado)
  • Una manera para que el logging DNS diga "este dominio no tiene server de correo"?
  • ¿Puede hacer referencia a un registro CNAME en un registro MX?
  • IP dynamic y logging MX
  • Comprobación de un server de correo antes de la migration
  • Proveedor de correo secundario
  • Registro MX para subdominios
  • ¿Existe una manera fácil de configurar los loggings MX de "example.com"?
  • Cambio de host pero no de host de correo
  • Registros MX y CNAME
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.