«Pagámos uma encomenda e o cliente não recebe a confirmação.» É provavelmente o ticket de apoio mais frequente nas lojas PrestaShop em 2026, e é quase sempre um problema de entregabilidade, não um bug aplicacional. Desde fevereiro de 2024, o Gmail e o Yahoo endureceram as exigências para os remetentes em massa, e o ecossistema segue-os. Hotmail, Outlook, Apple iCloud e, em Portugal, o SAPO Mail aplicam agora controlos equivalentes.
Para uma loja online, o que está em jogo não é marginal: um e-mail de confirmação que acaba no spam é um cliente que liga, um agente de apoio que trata, um risco de litígio e uma despromoção da reputação do domínio que degrada todos os e-mails seguintes. Aqui fica o ponto completo sobre as regras de 2026, as verificações a fazer na sua loja e as correções concretas.
As regras aplicáveis em 2026: síntese operacional
Três mecanismos de autenticação são hoje exigidos ou exigíveis consoante o volume:
- SPF (Sender Policy Framework): registo DNS que lista os servidores autorizados a enviar correio para o domínio. Soft fail (~all) tolerado, hard fail (-all) recomendado depois de validada a migração.
- DKIM (DomainKeys Identified Mail): assinatura criptográfica de cada e-mail com uma chave privada, verificável através de uma chave pública publicada em DNS. Indispensável.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): política publicada em DNS que diz aos servidores destinatários o que fazer com os e-mails que falham o SPF ou o DKIM. p=none é monitorização, p=quarantine é spam, p=reject é rejeição pura.
Desde fevereiro de 2024, o Gmail e o Yahoo exigem DMARC publicado (no mínimo p=none) a qualquer remetente que ultrapasse 5000 e-mails por dia. O Outlook e o iCloud seguiram em 2025. A partir de abril de 2025, o Gmail começou a filtrar mais agressivamente os remetentes em p=none que não progridem para uma política estrita ao fim de vários meses.
Em 2026, a trajetória é clara: DMARC p=quarantine ou p=reject está a tornar-se o padrão de facto, mesmo para os remetentes abaixo do limiar de 5000 e-mails por dia. As lojas que ficam em p=none verão a entregabilidade degradar-se progressivamente.
BIMI: o bónus visual que se torna sinal de reputação
O BIMI (Brand Indicators for Message Identification) permite mostrar o logótipo da marca na caixa de entrada (círculo azul no Gmail, vinheta no Apple Mail). Para o ativar, é preciso:
- Uma política DMARC em p=quarantine ou p=reject (não p=none).
- Um logótipo SVG quadrado no formato SVG Tiny Portable/Secure (.svg).
- Idealmente um certificado VMC (Verified Mark Certificate) emitido pela DigiCert ou pela Entrust, pago, à volta de 1200 a 1800 € sem IVA por ano, para ativar a exibição no Gmail e no Apple Mail.
Para além do aspeto cosmético, o BIMI envia aos filtros antispam um sinal de seriedade e de continuidade de identidade. As lojas com BIMI ganham em média 2 a 4 pontos de taxa de abertura nas newsletters, e marginalmente no transacional (onde a taxa de abertura já é muito alta).
Porque é que os e-mails do PrestaShop acabam no spam: as seis causas principais
1. Envio pelo servidor web por omissão (PHP mail)
PHP mail() a partir de um alojamento partilhado com cPanel ou Plesk: IP partilhado com centenas de domínios, sem assinatura DKIM por omissão, sem ciclo de retorno. Causa número um de quarentena imediata pelo Gmail.
A regra sã em 2026: todos os e-mails passam por um SMTP autenticado, seja no Brevo, Mailjet, Sendgrid, Postmark, AWS SES, Scaleway TEM, ou num SMTP próprio bem configurado. Isso obriga o PrestaShop a usar o módulo Symfony Mailer em modo SMTP.
2. SPF não alinhado
SPF correto no domínio de envio, mas o endereço Return-Path aponta para um subdomínio não coberto. Resultado: o SPF passa mas não se alinha com o From visível. O DMARC falha. O diagnóstico faz-se com um relatório DMARC agregado (RUA): vê-se de imediato o desfasamento.
3. DKIM caducado ou rotação esquecida
A chave DKIM publicada em DNS deve ter rotação periódica (semestral ou anual). Muitas lojas instalam-na no lançamento e depois esquecem-na. Ao fim de alguns anos, a chave está estatisticamente comprometida (comprimentos de 1024 bits historicamente) e o Gmail começa a penalizar. É preciso uma rotação limpa, geralmente gerida pelo fornecedor de SMTP.
4. Conteúdo HTML mal concebido
E-mail com demasiadas ligações para domínios de terceiros, rácio texto/imagem invertido (imagem em faixa que cobre 80 % do conteúdo, pouco texto), URL encurtados (bit.ly e afins), ausência de versão em texto simples. Estes sinais são individualmente fracos; acumulados, disparam os filtros bayesianos.
5. Volume errático e listas mal mantidas
Loja que envia um e-mail transacional por dia durante três meses e depois 50 000 newsletters de uma vez. Pico atípico, suspeita. E se a lista contém endereços inativos ou hard bounces não limpos, a taxa de queixas sobe. Acima de 0,3 %, o Gmail começa a filtrar.
6. Listas envenenadas
Endereços spam-trap (endereços antigos reciclados pelos fornecedores de e-mail para apanhar os spammers). Um único endereço spam-trap atingido arrasa a reputação do domínio durante várias semanas. A prevenção: duplo opt-in obrigatório, limpeza regular, validação no momento da introdução (verificar que o endereço responde antes da inscrição).
A checklist de saneamento em 2026: sequência em 6 etapas
Etapa 1: auditoria do existente
Verificar os registos DNS com o dmarcian, o MXToolbox ou o DNS checker do Postmark: SPF correto, DKIM publicado, DMARC publicado e legível. Testar um envio para um endereço Gmail pessoal e inspecionar os cabeçalhos (Authentication-Results) para verificar o pass/fail.
Etapa 2: implementação de um SMTP transacional autenticado
Brevo, Mailjet, Postmark ou AWS SES consoante o volume. Configurar o PrestaShop através do módulo Symfony Mailer (PS 8.1+) ou de um módulo SMTP de terceiros. Validar o envio de um e-mail de teste da loja: confirmação de encomenda, reposição de palavra-passe, alerta de preço.
Etapa 3: ativação do DMARC em p=none com relatórios
Publicar o registo DMARC com p=none e o atributo rua a apontar para um endereço dedicado (dmarc-rua@dominio.pt) ou para um serviço de monitorização (dmarcian, Postmark DMARC, OnDMARC). Deixar correr 2 a 4 semanas para recolher os relatórios agregados.
Etapa 4: análise dos relatórios DMARC e correção das fugas
Os relatórios identificam todos os serviços de terceiros que enviam pelo domínio: SMTP transacional, plataforma de newsletter, ferramenta de apoio (Zendesk, Crisp), CRM, software de faturação certificado que envia as faturas. Cada um tem de estar autorizado no SPF e assinar em DKIM alinhado. É a etapa que na prática mais tempo leva.
Etapa 5: passagem a p=quarantine e depois a p=reject
Depois de os relatórios DMARC estarem limpos (mais de 95 % de alinhamento), subir para p=quarantine durante 4 a 8 semanas, e depois p=reject. A cada patamar, vigiar os bounces e os tickets de clientes.
Etapa 6: BIMI e certificado VMC (opcional mas útil)
Uma vez em p=quarantine ou p=reject estável, publicar um registo BIMI com o logótipo SVG. Comprar um VMC se a marca estiver registada e o volume justificar o investimento.
Menos e-mails, melhor reputação: um tema muitas vezes esquecido
O PrestaShop envia por omissão dezenas de e-mails transacionais, alguns dos quais não servem para nada na sua organização (notificações internas duplicadas, estados de encomenda intermédios, mensagens que o cliente recebe já pelo software de faturação). Cada envio inútil é volume a mais, bounces a mais e risco a mais para a reputação do domínio.
Do lado da DataFirefly, o módulo dfemailfilter permite bloquear seletivamente o envio de certos e-mails transacionais do PrestaShop, por modelo, por estado de encomenda ou por destinatário, sem tocar no código. Útil para manter só os envios que contam e proteger a reputação construída nas etapas anteriores.
Conclusão: a entregabilidade como métrica de e-commerce de primeira ordem
Muitos comerciantes tratam o e-mail como um tema «informático» a delegar. É um erro em 2026. A entregabilidade condiciona agora: a conversão (carrinho abandonado não recuperado se o e-mail não chega), o apoio (tickets «não recebi a minha fatura»), a retenção (newsletters que acabam no spam equivalem a uma relação com o cliente partida) e a conformidade (RGPD e Lei n.º 41/2004: a prova de consentimento por duplo opt-in só é válida se o e-mail chegar).
Uma atualização limpa de SPF, DKIM e DMARC leva 4 a 8 semanas de trabalho concentrado e traz geralmente 5 a 15 pontos de taxa de abertura do lado do marketing, sem tocar no conteúdo. É um dos melhores retornos técnicos do ano.
Para passar à ação: a nossa seleção de módulos para reduzir o abandono de carrinho, cujas recuperações dependem diretamente da sua entregabilidade.
