O PrestaShop deixou de enviar e-mails: diagnóstico completo

Uma avaria silenciosa e cara

Quando o PrestaShop deixa de enviar e-mails, não se parte nada de visível. As encomendas passam, o back-office funciona. Mas o cliente não recebe a confirmação, telefona para o apoio ao cliente e a confiança esboroa-se. Muitos comerciantes só descobrem o problema várias semanas depois de ele ter começado.

O diagnóstico faz-se em quatro níveis, do mais simples ao mais técnico. Não salte etapas: a causa está muitas vezes no nível 1.

Nível 1: a configuração do PrestaShop

Vá a Parâmetros avançados > E-mail.

A armadilha número um lê-se diretamente na base de dados:

SELECT name, value FROM ps_configuration WHERE name LIKE 'PS_MAIL%';

O parâmetro PS_MAIL_METHOD assume três valores: 1 para a função mail do PHP, 2 para SMTP e 3 para desativado. O valor 3 é a causa mais frequente dos «não sai nenhum e-mail». Às vezes é definido por um módulo, ou durante uma fase de testes, e depois fica esquecido.

Confirme a seguir o endereço de expedição. Tem de pertencer ao seu domínio. Uma loja que envia a partir de um endereço Gmail ou Yahoo vê as mensagens rejeitadas pela maioria dos servidores de receção.

Por fim, use o botão de teste de envio que existe nessa página: dá uma mensagem de erro em bruto muito mais útil do que um teste feito a partir do processo de compra.

Nível 2: a regressão de SMTP do PrestaShop 9

Este caso merece uma secção só para si, porque afeta lojas cuja configuração não mudou.

O PrestaShop 9 substituiu o Swift Mailer pelo Symfony Mailer, e a cifra SSL foi retirada da camada de abstração: só restam TLS ou nenhuma cifra. Consequência observada: a cadeia de ligação é construída como ssl://servidor:587 onde a versão 8 usava tcp://servidor:587.

Ora, a porta 587 espera STARTTLS, ou seja, uma ligação em claro que passa depois a cifrada, e não SSL implícito. O servidor responde então com um erro do género:

SSL operation failed with code 1
error:0A00010B:SSL routines::wrong version number

Esta mensagem, muito desconcertante, não assinala um problema de certificado, mas uma incompatibilidade de protocolo.

A solução imediata passa por mudar para a porta 465 em SSL, que funciona corretamente. Se o seu fornecedor não disponibilizar a 465, a alternativa é usar um serviço de envio transacional com módulo dedicado.

Se os seus e-mails deixaram de sair exatamente no momento de uma subida para a versão 9, é a primeira pista a seguir.

Nível 3: a autenticação do domínio

Os e-mails saem, mas não chegam. É outro problema e, hoje em dia, o mais comum.

Os fornecedores de correio eletrónico exigem três registos DNS:

• SPF: autoriza o servidor que envia em nome do seu domínio. Atenção ao limite de dez resoluções DNS, depressa atingido quando se acumulam vários serviços.
• DKIM: assina criptograficamente as mensagens. Configura-se do lado do serviço de envio, que fornece a chave pública a publicar.
• DMARC: indica o que fazer quando os dois anteriores falham. Comece com a política none para observar e aperte depois.

Um domínio sem DKIM vê uma parte importante das mensagens classificada como lixo eletrónico, sem qualquer erro do lado do servidor. Verifique o estado dos registos com uma ferramenta de teste e leia os cabeçalhos de uma mensagem recebida: indicam o resultado de cada controlo.

Nível 4: a fila de envio e os registos

O PrestaShop guarda um historial das mensagens enviadas:

SELECT recipient, subject, date_add FROM ps_mail ORDER BY date_add DESC LIMIT 20;

Se aparecerem linhas recentes, o PrestaShop tentou mesmo enviar: o problema está a jusante, do lado do servidor de envio ou de receção. Se a tabela estiver vazia, o problema está a montante, na configuração ou no disparo do hook.

Consulte também var/logs/ e o registo de erros do PHP do alojamento. Um erro de ligação SMTP costuma aparecer aí em claro.

Caso particular: os e-mails desencadeados por uma tarefa agendada (lembretes, relatórios) falham por vezes enquanto os e-mails transacionais funcionam. A causa está quase sempre na própria tarefa agendada e não no envio. Veja o nosso artigo sobre os crons que não são executados.

A configuração recomendada

Numa loja em produção, a função mail do PHP deve ser posta de parte: envia a partir do IP partilhado do alojamento, cuja reputação não depende de si.

A configuração robusta consiste em usar um serviço de envio transacional dedicado, em SMTP autenticado, com SPF e DKIM corretamente publicados e uma monitorização da taxa de entrega. O custo é marginal; a diferença de fiabilidade é enorme.

Os seus clientes já não recebem nada?

Diagnosticamos toda a cadeia de envio, da configuração do PrestaShop à autenticação do domínio. Diagnóstico gratuito, resposta em 1 h — veja o suporte urgente PrestaShop.