Como garantir a entrega de correspondência para nosso aplicativo?

Como garantir a entrega de correspondência para nosso aplicativo?

Temos um aplicativo Rails usado para tickets de suporte e ajuda.

Ele envia aos clientes um e-mail de confirmação quando eles enviam uma solicitação. Ele também envia um e-mail quando respondemos à sua solicitação. Não recebe correspondência.

Na última semana, mais de 25% dos nossos clientes pararam de receber respostas. Eles acham que não estamos respondendo ao seu ticket (quando na verdade estamos).

Fiz um teste com minha conta @yahoo.com e encontrei isto no arquivo mail.log:

Jul  9 16:11:45 bighelp postfix/smtp[9051]: BF673324365: host b.mx.mail.yahoo.com[66.196.97.250] said: 451 Message temporarily deferred - [140] (in reply to end of DATA command)
Jul  9 16:11:45 bighelp postfix/smtp[9051]: BF673324365: to=<[email protected]>, relay=d.mx.mail.yahoo.com[68.142.202.247]:25, delay=0.73, delays=0.02/0.02/0.64/0.05, dsn=4.0.$

Outros endereços que não são do Google também estão passando por isso.

O aplicativo Rails está rodando no Ubuntu e estamos enviando via:

ActionMailer::Base.delivery_method = :sendmail

Certifiquei-me de que o servidor não é um retransmissor aberto.

O que mais posso fazer para garantir que a maioria dos nossos e-mails seja enviada?

Responder1

Esta mensagem geralmente tem a ver com a lista cinza (especialmente com o Google, que parece fazer isso com todos em alguns momentos). Basicamente, o servidor de e-mail adia temporariamente seu primeiro e-mail, um servidor de e-mail legítimo verá esta mensagem, aguardará um período e tentará novamente. Os servidores que enviam spam geralmente são configurados para enviar apenas grandes quantidades de e-mails e esquecê-los, nunca mais tentarão novamente e, portanto, o spam será descartado.

Para garantir que você possa passar pela lista cinza, certifique-se de que seu servidor de e-mail esteja configurado para tentar novamente após um adiamento e forneça janelas de tempo razoáveis, 10 a 20 minutos geralmente são suficientes.

Responder2

Obter falha temporária de algum outro servidor de e-mail não é totalmente incomum; você deve esperar que isso aconteça de vez em quando.

Imagino que a maioria dos provedores de e-mail (isenção de responsabilidade: trabalho apenas para UM) falhará temporariamente com mais frequência para remetentes de "má reputação". Fazemos isso para priorizar seletivamente os recursos para correspondência mais limpa. Se o seu servidor conseguiu obter uma má reputação para o seu endereço IP, isso provavelmente significa que as mensagens estão sendo classificadas como spam enviadas pelo seu aplicativo ou por outra coisa do mesmo endereço IP.

Você DEFINITIVAMENTE deve monitorar suas filas de e-mail. Você possivelmente deve realizar alguma auditoria em entregas individuais para poder rastreá-las.

Se você vir um grande número de mensagens na fila para entrega, isso indica algum tipo de falha, seja no servidor de e-mail do destinatário, ou que eles estão colocando seu e-mail na lista negra/despriorizando de alguma forma.

Exatamente como você faz essas coisas é específico do aplicativo.

Nesse caso específico, você deve entrar em contato com o suporte do Yahoo, presumindo que você definitivamente não está enviando spam (nem qualquer outra pessoa do mesmo IP).

Responder3

Você parece ter dois problemas aqui:

  1. O que está acontecendo atualmente com seu sistema de e-mail
  2. Como garantir que o problema não aconteça novamente no futuro

WRT #1, eu faria as seguintes verificações:

  1. Eu configuraria seu servidor para receber e-mails. Sistemas que não podem receber rejeições e parecem ser apenas transmitidos muitas vezes podem ser sinalizados como spam.
  2. verifique seus registros MX e também se você está em uma lista negra -mxtoolbox. com
  3. verifique seus registros RDNS emwww.dnscolos.com.
  4. Eu adicionaria DomainKeys ao seu servidor de e-mail.
  5. Eu recomendo ADICIONAR um registro SPF. Isso pode diminuir sua pontuação de spam e impedir que hosts de spam finjam enviar e-mails do seu domínio.
  6. Envie um email para[e-mail protegido]. Eles responderão com um relatório com várias verificações de spam.

WRT # 2, eu sugeriria incluir um gif transparente ou um logotipo especialmente marcado em seu e-mail que 'ligará para casa' de volta ao seu servidor. Sim, isso significa que você precisa enviar e-mail em HTML e, sim, alguns clientes bloquearão a recuperação de imagens por e-mail por padrão; no entanto, você verá rapidamente suas taxas de resposta normais e será capaz de detectar se isso caiu. Se você tem clientes de alto valor e percebe que eles podem não ter recebido sua resposta, você pode ligar para eles de forma proativa.

Responder4

Você também deve certificar-se de que seu servidor de e-mail esteja se identificando corretamente (como mail.yourapp.com ou qualquer outro) e que exista um registro PTR vinculando esse IP a esse nome.

Além disso, você pode adicionar um registro SPF permitindo que esse IP/servidor envie e-mails para o seu domínio, para que pelo menos ele também obtenha um SPF:Pass.

informação relacionada