¿Cuáles son las mejores prácticas para garantizar que los sistemas de correo electrónico funcionen en Support?

Pregunta

¿Cómo puedo asegurarme de que mi sistema de correo electrónico funciona bien con Zendesk?

Respuesta

Zendesk se esfuerza por mantener su bandeja de entrada libre de spam, pero hay ciertas medidas que puede tomar para ayudar a proteger los canales que usa para interactuar con los clientes. Este artículo ofrece información general sobre cómo aumentar el nivel de confianza de su servidor de correo electrónico.

Este artículo contiene las siguientes secciones:

• Registro PTR para servidores SMTP que envían correo electrónico a Zendesk
• Nombre de host del saludo HELO y EHLO
• Registros SPF
• DMARC y DKIM
• Envío de correo electrónico usando scripts y formularios web
• Correos electrónicos no de confianza

Registro PTR para servidores SMTP que envían correo electrónico a Zendesk

Asegúrese de que todas las direcciones IP que usa para enviar mensajes de correo electrónico a Support tengan un registro de puntero (PTR). Los registros PTR proporcionan una seguridad 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 debe resolverse en mail.domain.com si alguien de domain.com envía un correo electrónico a Support.

Lo ideal es que un registro PTR pertenezca al mismo dominio que envía los 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 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 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

Nombre de host del saludo HELO y EHLO

Los servidores SMTP usan el nombre HELO para saludarse entre sí. Si el registro HELO se puede resolver de acuerdo conRFC 5321 (Sección 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 mensajes de correo electrónico a Support tengan un nombre de host HELO que se puede resolver.

Ejemplo del registro correcto para domain.com:

• HELO mail.domain.com

Ejemplo de mensajes de 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.

Registros SPF

Los dominios que envían mensajes de correo electrónico a Support deben tener un registro SPF válido que autorice a las direcciones IP a enviar mensajes de 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 correo electrónico 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”

DMARC y DKIM

Para reducir el número de correos electrónicos falsos 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: Autenticar el correo electrónico entrante (SPF, DKIM, DMARC).

Envío de correo electrónico usando scripts y formularios web

No se recomienda enviar correo electrónico a Support usando formularios web o scripts automatizados. 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 que se envían deben requerir autenticación o usar CAPTCHA, o ambos. No podemos evitar los ataques de spam que están permitiendo y alentando.
• Cuando envía mensajes de correo electrónico a Soporte 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 con el formato Asunto:, De:, Para: y Responder a : .
• La dirección IP de envío debe tener un registro PTR (resolución DNS inversa).
• Support lo alienta a agregar registros SPF válidos, firmar estos correos electrónicos con la clave DKIM publicada en la zona DNS del dominio remitente y hacer que se publique una política de DMARC que especifique la forma en que deben tratarse los correos electrónicos.
• El mensaje HELO debe tener un nombre DNS válido y que se pueda resolver.
• Reenviar correo electrónico desde un formulario web a través de una dirección de soporte externa, con el propósito de redundancia de datos y para disminuir la probabilidad de suspensiones.
• Si está enviando un mensaje a una dirección de soporte nativa de Zendesk (soporte @subdominio.zendesk.com) el formulario debería poder manejar errores transitorios de la red y, o 4xx respuestas de resiliencia.
• No codifique una retransmisión MX en ninguno de nuestros registros MX. Cada relé debe realizar una búsqueda de MX.
• No use la función Marcar como spampara los envíos desde su formulario web. Esto tendrá un impacto negativo en la reputación de envío de su formulario.
• Atención al cliente de Zendesk no proporciona soporte para la funcionalidad de su formulario web.

Correos electrónicos no de confianza

Zendesk no confía en:

• Correos electrónicos que suplantan al remitente del correo electrónico sin tener un registro SPF de autorización publicado en la zona DNS del dueño del dominio.
• Mensajes de correo electrónico con una dirección de remitente falsificada, una firma DKIM no válida o una verificación del SPF fallida.
• 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.

Soporte muestra un nivel de confianza bajo con los mensajes de correo electrónico enviados a través de un servidor SMTP con un registro PTR que falta o un mensaje de HELO no válido.

* Zendesk intenta detectar los mensajes de correo electrónico reenviados si está reenviando mensajes de su dominio a un subdominio de soporte de Zendesk, por ejemplo, [e-mail] >> [e-mail]. En caso de que Zendesk detecte un reenvío de correo electrónico, Zendesk adopta métodos alternativos para autenticar el servidor SMTP remitente. 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.

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.