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, puede mejorar el nivel de confianza de su servidor de correo electrónico y minimizar el riesgo de problemas al trabajar con Zendesk.

En este artículo se incluyen las siguientes recomendaciones y mejores prácticas de configuración:

  • Recomendación 1: Configurar un registro PTR para los servidores SMTP que envían correo electrónico a Zendesk
  • Recomendación 2: Configurar el 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 use para enviar correos electrónicos a Support 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 correo.dominio.com si alguien de dominio.com envía un correo electrónico a Support.

Lo ideal es que un registro PTR pertenezca al mismo dominio que envía mensajes de correo electrónico a Support. 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 dominio.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 se debe usar 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 el nombre de host del mensaje HELO y EHLO

Los servidores SMTP usan el nombre HELO para saludarse entre sí. 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. Support espera que los servidores SMTP que envían correo electrónico a Support tengan un nombre de host HELO que se pueda resolver.

Ejemplo del registro correcto para dominio.com:

  • HELO mail.domain.com

Ejemplo de mensajes 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 Support deben tener un registro SPF válido que autorice a las direcciones IP a enviar correo electrónico en nombre del dominio.

A continuación encontrará 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 dominio.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: DMARC y DKIM

Para disminuir el número de correos electrónicos falsificados y spam que recibe, agregue una capa adicional de seguridad en sus correos electrónicos entrantes activando la autenticación del remitente con alineación SPF, DKIM y DMARC. Para obtener más información, consulte el artículo: Autenticación del correo electrónico entrante (SPF, DKIM, DMARC).

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

No se recomienda enviar correos electrónicos a Support usando formularios web o scripts automatizados y actualmente no se admite. Los clientes que aún deseen 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 ambas cosas. Zendesk no puede evitar los ataques de spam que usted permite y fomenta.
  • Cuando se envían mensajes de correo electrónico a Support usando formularios web, aplicaciones web o scripts de automatización, los mensajes de correo electrónico deben tener el formato correcto, de acuerdo con RFC 5322.
  • Los mensajes deben contener encabezados Asunto:, De:, Para:y Responder a: con el formato correcto. 
  • La dirección IP de envío debe tener un registro PTR (resolución de DNS inversa). 
  • Support recomienda agregar registros SPF válidos, firmar estos correos electrónicos con la clave DKIM publicada en la zona DNS del dominio de envío 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 de DNS válido que se pueda resolver.
  • Reenvíe cualquier correo electrónico desde un formulario web a través de una dirección de soporte externa, con el fin de redundancia de datos y para disminuir la probabilidad de suspensiones.
  • Si está enviando a una dirección de soporte nativa de Zendesk (soporte@subdominio.zendesk.com), el formulario debería poder manejar errores de red transitorios y, o 4xx respuestas para la resiliencia.
  • No codifique un relevo MX en ninguno de nuestros registros MX. Cada retransmisión debe realizar una búsqueda de MX.
  • No use la función Marcar como spam para los envíos de su formulario web. Esto tendrá un impacto negativo en la reputación de envío de su formulario.
  • El servicio de atención al cliente de Zendesk no proporciona soporte para la funcionalidad del formulario web.

Mejores prácticas para enviar correos electrónicos confiables

Zendesk no confía en:

  • Correos electrónicos que están falsificando al remitente 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, una firma DKIM no válida o una verificación de SPF fallida
    Nota: Zendesk intenta detectar los correos electrónicos reenviados si está reenviando correos electrónicos de su dominio a un subdominio de soporte de Zendesk, por ejemplo, soporte@sudominio.com >> soporte@subdominio.zendesk.com. En caso de que Zendesk detecte el reenvío de correo electrónico, Zendesk adopta enfoques alternativos para autenticar el servidor SMTP de envío. Sin embargo, configure el servidor SMTP de reenvío para conservar la firma DKIM y no alterar el cuerpo original del correo electrónico y los encabezados confidenciales.
  • Correos electrónicos que usan nombres de dominio no válidos, inexistentes o que no se pueden resolver en los encabezados del remitente y el destinatario del correo electrónico

Support ejerce un nivel de confianza bajo hacia los correos electrónicos que se enviaron a través de un servidor SMTP en los que falta un registro PTR 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