Quais são as práticas recomendadas para garantir que os sistemas de e-mail funcionem no Support?

Pergunta

Como posso assegurar que meu sistema de email funcione bem com o Zendesk?

Resposta

A Zendesk se esforça para manter sua caixa de entrada livre de spam, mas há algumas medidas que você pode tomar para ajudar a proteger os canais que você usa para interagir com os clientes. Esse artigo apresenta uma visão geral de como aumentar o nível de confiança do seu servidor de email.

Este artigo inclui as seções a seguir:

• Registro PTR para servidores SMTP que enviam emails para a Zendesk
• Nome do host de saudação HELO e EHLO
• Registros SPF
• DMARC e DKIM
• Envio de emails usando scripts e formulários web
• Emails que o Zendesk não confia

Registro PTR para servidores SMTP que enviam emails para a Zendesk

Verifique se todos os endereços IP usados para enviar emails para o Support têm um registro de ponteiro (PTR). Os registros PTR aumentam a confiança de que o endereço IP fornecido tem uma conexão com o proprietário do domínio. Por exemplo, o endereço IP 1.2.3.4 deve ser resolvido para mail.dominio.com se alguém de domínio.com enviar um email para o suporte.

O ideal é que um registro PTR deve pertencer ao mesmo domínio que envia emails para o Support. Ele não deve conter números de endereço IP ou palavras-chave que indiquem que um endereço IP pertence a um ISP doméstico.

Exemplo de registro correto para domínio.com:

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

Exemplo de registro ausente:

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

Exemplo do registro que não deve ser usado para enviar um email:

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

Nome do host de saudação HELO e EHLO

O nome HELO é usado por servidores SMTP para cumprimentar uns aos outros. O registro HELO que pode ser resolvido de acordo com aRFC 5321 (§2.3.5), deve pertencer ao domínio do remetente do email e corresponder a um registro MX. O Support espera que os servidores SMTP que enviam emails para o Support tenham um nome de host HELO resolvível.

Exemplo de registro correto para domínio.com:

• HELO mail.domain.com

Exemplo de saudações HELO que são consideradas baixa confiança:

• HELO mail.otherdomain.com
• HELO localhost
• HELO 1.2.3.4
• HELO invalid.tld
• HELO not.existing.domain.com
  Para obter mais informações, consulte este artigo da Wikipedia: Lista de códigos de retorno do servidor SMTP.

Registros SPF

Os domínios que enviam emails para o Support devem ter um registro SPF válido que autorizar endereços IP a enviar emails em nome do domínio.

Encontre abaixo dois exemplos do registro SPF correto para a seguinte situação:

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

Ambos os exemplos permitiriam que 1.2.3.4 enviasse emails em nome 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 e DKIM

Para diminuir a quantidade de emails falsos e spam recebidos, adicione outra camada de segurança em seus emails recebidos ativando a autenticação para remetentes com alinhamento para SPF, DKIM e DMARC. Para obter mais informações, consulte o artigo: Autenticação dos emails recebidos (SPF, DKIM, DMARC).

Envio de emails usando scripts e formulários web

Não é recomendável enviar e-mails para o Support usando formulários web ou scripts automatizados, o que não é recomendável, até o momento. Os clientes que ainda quiserem enviar esses tipos de email devem seguir as regras descritas abaixo.

• Todos os formulários web enviados devem requerer autenticação ou usar CAPTCHA, ou ambos. Não podemos impedir ataques de spam que você está permitindo e incentivando.
• Quando você envia emails para o Support usando formulários web, aplicativos web ou scripts de automação, os emails devem ser formatados corretamente, de acordo com RFC 5322.
• As mensagens devem conter cabeçalhos Assuntos :, De:, Para: e Responder para:.
• O endereço IP de envio deve ter um registro PTR (resolução DNS inversa).
• O Support recomenda que você adicione registros SPF válidos, assine esses emails com a chave DKIM publicada na zona DNS de envio e tenha uma política DMARC publicada especificando o modo como os emails devem ser tratados.
• A saudação HELO deve ter um nome DNS resolvível válido.
• Encaminhe qualquer email de um formulário web para um endereço de suporte externo, para evitar redundância de dados e diminuir a probabilidade de suspensões.
• Se você estiver enviando o envio para um endereço de suporte nativo do Zendesk (support@subdomínio.zendesk.com), seu formulário deverá ser capaz de lidar com erros temporários de rede e/ou 4xx respostas para aumentar a resiliência.
• Não faça uma codificação rígida de um retransmissor de mensagens MX para nenhum de nossos registros MX. Cada retransmissão deve realizar uma pesquisa de MX.
• Não use o recurso Marcar como spampara envios do seu formulário web. Isso terá um impacto negativo na reputação de envio do seu formulário.
• O Suporte ao cliente Zendesk não fornece suporte para a funcionalidade do seu formulário web.

Emails que o Zendesk não confia

O Zendesk não confia em:

• Emails que falsificam o remetente do email sem ter um registro SPF autorizado e publicado na zona DNS do responsável pelo domínio.
• Emails com um endereço de remetente falsificado, assinatura DKIM inválida ou verificação SPF malsucedida.*
• Emails que usam nomes de domínio inválidos, não existentes ou que não podem ser resolvidos nos cabeçalhos do remetente e do destinatário do email.

O Support exerce um baixo nível de confiança em relação aos emails enviados por um servidor SMTP com um registro PTR ausente ou uma saudação HELO inválida.

*O Zendesk tenta detectar emails encaminhados se você estiver encaminhando emails do seu domínio para um subdomínio de suporte do Zendesk, por exemplo, suporte@seudomínio.com >> support@subdomínio.zendesk.com. Caso a Zendesk detecte o encaminhamento de email, ela adota abordagens alternativas de autenticação do servidor SMTP de envio. No entanto, configure o encaminhamento para o servidor SMTP para preservar a assinatura DKIM e não alterar o corpo do email original e os cabeçalhos confidenciais.

Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.

Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.