Os e-mails da sua loja não chegam: SMTP, SPF, DKIM e DMARC explicados

«Não recebi a confirmação da encomenda.» Se ouve isto com frequência, o problema não é o cliente. Os fornecedores de correio (Gmail, Outlook, Yahoo e os restantes) são cada vez mais exigentes com as mensagens que recebem, e um e-mail que não demonstra bem de onde vem acaba no spam ou é diretamente rejeitado. Para uma loja, isso significa clientes inquietos, chamadas para o apoio ao cliente e palavras-passe que ninguém consegue recuperar.

Vamos ver como o PrestaShop envia os e-mails e o que é preciso configurar para que cheguem.

Como o PrestaShop envia e-mails

Em Parâmetros avançados → E-mail escolhe como sai o correio:

• A função de correio do PHP do servidor. É a opção predefinida e a mais cómoda, mas o e-mail sai a partir do servidor web, que muitas vezes não está autorizado a enviar em nome do seu domínio. É a causa mais frequente de e-mails no spam.
• Um servidor SMTP. A loja liga-se com utilizador e palavra-passe a uma caixa de correio real (a do seu fornecedor de correio ou de um serviço de envio transacional) e envia através dela. É o recomendável.

Nesse mesmo ecrã pode enviar um e-mail de teste. Use-o depois de cada alteração e envie-o para caixas de vários fornecedores.

As três verificações que o destinatário faz

SPF: quem pode enviar em nome do seu domínio

É um registo TXT no DNS do seu domínio que enumera os servidores autorizados a enviar correio com o seu domínio no remetente. Quando chega um e-mail, o destinatário vê de que servidor vem e se está nessa lista.

Erros típicos:

• Ter dois registos SPF no mesmo domínio. Só pode haver um; se houver dois, a verificação falha. Quando acrescenta um serviço novo, amplia-se o registo existente, não se cria outro.
• Não incluir todos os que enviam: o servidor da loja, o fornecedor de correio, a ferramenta de newsletters, o ERP que envia faturas.
• Ultrapassar o limite de consultas. O SPF permite no máximo dez pesquisas DNS ao ser avaliado, e cada include conta (com os que tiver dentro). Com muitos serviços, ultrapassa-se sem dar por isso.

DKIM: a assinatura da mensagem

O servidor que envia assina cada e-mail com uma chave privada e publica a chave pública no DNS do seu domínio. O destinatário verifica a assinatura: se bater certo, a mensagem vem de quem diz e não foi modificada pelo caminho.

Quem o ativa é o fornecedor que envia (o seu serviço de correio ou de envio transacional), que lhe dá o registo a acrescentar ao DNS. Se usar a função de correio do PHP do servidor web, normalmente não há assinatura DKIM, ou há com o domínio do alojamento, não com o seu.

DMARC: o que fazer se falhar, e que lho comuniquem

É outro registo TXT, em _dmarc.tudominio, que diz aos destinatários o que fazer com um e-mail que diz ser do seu domínio mas não passa no SPF ou no DKIM de forma alinhada (ou seja, com o mesmo domínio do remetente visível). Tem três políticas:

• p=none: não faça nada de especial, apenas me informe.
• p=quarantine: trate-o como suspeito (normalmente, para o spam).
• p=reject: rejeite-o.

E pode pedir relatórios para um endereço seu, nos quais os fornecedores lhe dizem que e-mails com o seu domínio receberam e se passavam nas verificações. É a forma de descobrir serviços que enviam em seu nome e de que se tinha esquecido, ou alguém que usurpa o seu domínio.

O prudente é começar com p=none, rever os relatórios durante algumas semanas até que tudo o que é legítimo passe, e endurecer depois.

Porque é que agora importa mais

Os grandes fornecedores de correio têm vindo a endurecer os requisitos. Desde 2024, o Gmail e o Yahoo exigem a quem envia grandes volumes ter SPF, DKIM e DMARC e, aos restantes, pelo menos uma autenticação correta. Mesmo que a sua loja não envie milhares de e-mails por dia, se a sua ferramenta de newsletters o fizer com o seu domínio, o domínio inteiro fica afetado. E sem autenticação é cada vez mais provável que um e-mail de encomenda não chegue à caixa de entrada.

Outras causas para não chegarem

• Reputação do servidor ou do IP: se partilha o IP com outros que enviam spam, pagam todos.
• Conteúdo: e-mails só com uma imagem, ligações encurtadas, muito texto em maiúsculas ou assuntos agressivos. Os e-mails de encomenda devem ser sóbrios e ter versão em texto simples.
• Misturar e-mails de encomenda e promoções no mesmo envio e com o mesmo remetente. Se as newsletters geram queixas, arrastam os transacionais.
• Caixa cheia ou endereço mal escrito pelo cliente. Aqui ajuda validar o e-mail no registo e rever as devoluções.
• Limites do SMTP: muitas caixas de correio normais limitam quantos e-mails se podem enviar por hora ou por dia. Em campanhas fortes, a loja pode bater nesse teto.

Como verificar

1. Envie um e-mail de teste a partir da loja para uma caixa do Gmail e abra a mensagem original: verá se SPF, DKIM e DMARC aparecem como PASS e com que domínio.
2. Consulte os registos TXT do seu domínio com qualquer ferramenta de DNS e confirme que há um só SPF e um DMARC.
3. Faça a lista de tudo o que envia correio com o seu domínio e confirme que cada um assina com DKIM e está no SPF.
4. Reveja os relatórios de DMARC durante algumas semanas antes de passar para quarantine ou reject.

Como resolver no PrestaShop

A entrega depende do DNS e do servidor de correio; o conteúdo, dos templates. O RKR Mail Editor inclui um editor visual dos e-mails do PrestaShop com o qual edita o assunto, o HTML e a versão em texto simples de cada template em cada idioma, e acrescenta aos e-mails de encomenda produtos recomendados, um cupão único para a compra seguinte e banners por campanha, com uma ligação de cancelamento da subscrição em cada e-mail que leva blocos comerciais. Se o que precisa é de configurar o SMTP da loja, rever o seu SPF, ativar o DKIM com o seu fornecedor ou pôr o DMARC a funcionar sem perder e-mails, com um pacote de horas de suporte da Rekire revemos tudo e deixamo-lo a funcionar.