Utilice esta guía para asegurarse de que su sistema de correo electrónico esté optimizado para una integración perfecta con Zendesk. Si sigue las mejores prácticas que se describen en este artículo, podrá mejorar el nivel de confianza de su servidor de correo electrónico y minimizar el riesgo de problemas al trabajar con Zendesk.

Este artículo incluye las siguientes recomendaciones de configuración y mejores prácticas:

  • Recomendación 1: Configurar un registro PTR para los servidores SMTP que envían correo electrónico a Zendesk
  • Recomendación 2: Configurar nombre de host del mensaje HELO y EHLO
  • Recomendación 3: Registros SPF
  • Recomendación 4: DMARC y DKIM
  • Mejores prácticas para enviar correo electrónico usando scripts y formularios web
  • Mejores prácticas para enviar correos electrónicos confiables

Recomendación 1: Configurar un registro PTR para los servidores SMTP que envían correo electrónico a Zendesk

Asegúrese de que todas las direcciones IP que usa para enviar correos electrónicos al soporte tengan un registro de puntero (PTR). Los registros PTR proporcionan una confianza adicional de que la dirección IP dada tiene una conexión con el dueño del dominio. Por ejemplo, la dirección IP 1.2.3.4 debería resolverse en mail.domain.com si alguien de domain.com envía un correo electrónico a soporte.

Idealmente, un registro PTR debería pertenecer al mismo dominio que envía correos electrónicos a soporte. No debe contener números de dirección IP ni palabras clave que indiquen que una dirección IP pertenece a un ISP residencial.

Ejemplo del registro correcto para domain.com:

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com 

Ejemplo de un registro que falta:

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)

Ejemplo del registro que no debe usarse para enviar un correo electrónico:

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com

Recomendación 2: Configurar nombre de host del mensaje HELO y EHLO

Los servidores SMTP usan el nombre HELO para saludarse unos a otros. El registro HELO que se puede resolver de acuerdo con RFC 5321 (§2.3.5), debe pertenecer al dominio del remitente del correo electrónico y coincidir con un registro MX. Soporte espera que los servidores SMTP que envían correo electrónico a soporte tengan un nombre de host HELO resoluble.

Ejemplo del registro correcto para domain.com:

  • HELO mail.domain.com

Ejemplo de saludos HELO que se consideran de baja confianza:

  • HELO mail.otherdomain.com
  • HELO localhost
  • HELO 1.2.3.4
  • HELO invalid.tld
  • HELO not.existing.domain.com
    Si desea más información, consulte este artículo de Wikipedia: Lista de códigos de retorno del servidor SMTP.

Recomendación 3: Registros SPF

Los dominios que envían correo electrónico a soporte deben tener un registro SPF válido que autorice a las direcciones IP a enviar correos electrónicos en nombre del dominio.

Vea a continuación dos ejemplos del registro SPF correcto para la siguiente situación:

  • domain.com
  • SMTP servers with address 1.2.3.4
  • MX record mail.domain.com pointing on 1.2.3.4.

Ambos ejemplos permitirían que 1.2.3.4 envíe correos electrónicos en nombre de domain.com.

  • domain.com.          3600    IN      TXT     "v=spf1 mx:domain.com ~all”
  • domain.com.          3600    IN      TXT     "v=spf1 ip4:1.2.3.4 ~all” 

Recomendación 4: SPF, DKIM, DMARC y ARC

Para reducir el número de correo electrónico falsificado o spam que recibe, puede agregar una capa de seguridad adicional en los correos electrónicos entrantes. Para ello, puede activar la autenticación por alineación de SPF, DKIM, DMARC y ARC. Para obtener más información, consulte el artículo: Autenticación del correo electrónico entrante.

Recomendación 5: Agregar encabezados ARC

Para el tráfico de reenvío de cuentas a Zendesk, recomendamos agregar encabezados ARC para poder incorporar la evaluación de autenticación del tráfico cuando llegó a los servidores de reenvío.  

Mejores prácticas para enviar correo electrónico usando scripts y formularios web

No se recomienda enviar correo electrónico a soporte usando formularios web o scripts automatizados y no se admite actualmente. Los clientes que todavía desean enviar este tipo de correo electrónico deben seguir las reglas que se describen a continuación.

  • Todos los formularios web de envío deben requerir autenticación o usar CAPTCHA, o ambos. Zendesk no puede evitar los ataques de spam que usted permite y alienta.
  • Cuando se envían mensajes de correo electrónico al soporte usando formularios web, aplicaciones web o scripts de automatización, los mensajes deben tener el formato correcto, de conformidad con RFC 5322.
  • Los mensajes deben contener encabezados Asunto:, De:, A: y Respuesta a: con el formato correcto. 
  • La dirección IP remitente debe tener un registro PTR (resolución DNS inversa). 
  • Soporte recomienda agregar registros SPF válidos, firmar estos correos electrónicos con la clave DKIM publicada en la zona DNS del dominio remitente y publicar una política de DMARC que especifique cómo se deben tratar los correos electrónicos. 
  • El mensaje HELO debe tener un nombre DNS válido que se pueda resolver.
  • Reenviar cualquier correo electrónico desde un formulario web a través de una dirección de soporte externa, con el fin de redundar los datos y reducir la probabilidad de suspensiones o tráfico abandonado.
  • Si está enviando a una dirección nativa de Zendesk Support (Support@subdominio.zendesk.com), su formulario debería poder manejar errores transitorios de red o 4xx respuestas para mejorar la resiliencia.
  • No codifique una retransmisión MX en ninguno de nuestros registros MX. Cada retransmisión debe realizar una búsqueda MX.
  • No utilice la función Marcar como spam para los envíos desde su formulario web. Esto tendrá un impacto negativo en la reputación de envío de su formulario.
  • Zendesk Customer Support no ofrece Support para la funcionalidad de su formulario web.

Mejores prácticas para enviar correos electrónicos confiables

Zendesk no confía en:

  • Correos electrónicos que están suplantando al remitente del correo electrónico sin tener un registro SPF de autorización publicado en la zona DNS del dueño del dominio.
  • Correos electrónicos con una dirección de remitente falsificada, firma DKIM no válida o no alineada, o verificación SPF fallida
    Nota: Zendesk intenta detectar los mensajes de correo electrónico reenviados si está reenviando mensajes de correo electrónico desde su dominio a un subdominio Zendesk Support, por ejemplo, Support@sudominio.com >> Support@subdominio.zendesk.com. En caso de que Zendesk detecte reenvío de correo electrónico, Zendesk adopta enfoques alternativos para autenticar el servidor SMTP remitente. Sin embargo, intente configurar el servidor de reenvío para conservar la firma DKIM y no manipular el cuerpo original del correo electrónico y los encabezados confidenciales, ya que esto puede causar fallas. Además, trate de utilizar encabezados ARC siempre que sea posible. 
  • Los correos electrónicos que usan nombres de dominio no válidos, inexistentes o no resolubles en los encabezados de remitente y destinatario del correo electrónico probablemente serán suspendidos o rechazados. 

Soporte ejerce un bajo nivel de confianza hacia los correos electrónicos que fueron enviados a través de un servidor SMTP con un registro PTR que falta o un mensaje HELO no válido.

Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.

Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.

Tecnología de Zendesk