Email a partir do seu site e formulários

Módulo 7: Newsletters e email a partir do seu site · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: Depois desta lição, saberá configurar o email do seu site (formulários de contacto, confirmações de encomenda, notificações do WordPress) de forma a que chegue ao destino, não cause problemas de DMARC e não permita que o seu pacote seja usado indevidamente.

Conceitos-chave: PHP mail(), SMTP com autenticação, remetente de envelope, From vs. Reply-To, nunca usar o endereço do visitante como From, plugin SMTP, email transacional, spam em formulários, captcha, honeypot, limite de envio, entrega local quando o MX aponta para outro local

O seu site também é um programa de correio eletrónico

O seu site envia mais correio do que pensa. Um formulário de contacto envia-lhe uma mensagem por cada submissão. Uma loja online envia confirmações de encomenda, faturas e avisos de envio. O WordPress envia mensagens quando há um novo comentário, uma atualização ou uma redefinição de palavra-passe. Para o destinatário, trata-se simplesmente de correio do seu domínio, e é verificado com o mesmo rigor que o correio da sua caixa de correio: SPF, DKIM, DMARC, reputação.

No entanto, o correio enviado pelo site falha com mais frequência do que o correio normal. Isto deve-se geralmente a um de três fatores: a forma de envio, o endereço de remetente ou o uso indevido do formulário.

Forma 1: PHP mail()

A forma mais simples de um site enviar correio é através da função PHP mail(). O site entrega então a mensagem diretamente ao programa de correio do servidor web, sem autenticação. Normalmente funciona, mas tem desvantagens:

• O remetente de envelope (Return-Path) torna-se muitas vezes a conta de sistema do seu pacote, como utilizador@server.hosting.example, e não o seu endereço. O SPF é então verificado para o domínio do servidor, e não está, portanto, alinhado com o seu domínio From (lição 7.1).
• Se é adicionada uma assinatura DKIM do seu domínio depende do servidor. Em alguns servidores sim, noutros não.
• Não vê nada em troca. Se a mensagem não chegar ou receber um bounce, este vai para a conta de sistema, que ninguém consulta.
• Sem limite por formulário. Se o formulário for usado indevidamente, o servidor envia mensagens em seu nome até atingir o limite do seu pacote.

Forma 2: SMTP com autenticação (melhor)

Faça com que o seu site envie correio da mesma forma que o seu programa de correio o faz: autenticando-se no servidor de envio com uma caixa de correio real, através da porta 587 (STARTTLS) ou 465 (SSL/TLS), usando o endereço de email completo como nome de utilizador (lições 1.4 e 2.1). Assim:

• o remetente de envelope é o seu endereço e a mensagem é assinada da mesma forma que o correio normal do seu domínio;
• os bounces chegam a uma caixa de correio que pode consultar;
• a mensagem enviada fica, se assim o desejar, na pasta Enviados;
• pode definir um limite de envio próprio por caixa de correio.

No WordPress, isto faz-se com um plugin SMTP. Este substitui a função de correio predefinida do WordPress pelo envio através de SMTP. Preenche os mesmos dados que num programa de correio: servidor, porta, segurança, nome de utilizador e palavra-passe. Para isso, crie de preferência uma caixa de correio separada, por exemplo website@example.com. Se a palavra-passe alguma vez for roubada, a sua própria caixa de correio fica protegida, e consegue ver de imediato que mensagens vêm do site.

Para um site PHP próprio, existem bibliotecas que enviam correio através de SMTP, como o PHPMailer. Guarde a palavra-passe num ficheiro de configuração fora da pasta web, nunca no código de uma página.

No WebOké, os dados para SMTP estão no manual do DirectAdmin 8.1, com o nome do servidor do seu pacote; noutros fornecedores encontram-se no manual ou no email de boas-vindas, e funciona da mesma forma.

Muito email transacional? Use um serviço especializado

Se enviar centenas de confirmações de encomenda por dia, compensa usar um serviço transacional: um serviço de envio dedicado a correio automático. Este tem boa reputação e mostra o que aconteceu com cada mensagem. Associa o domínio da mesma forma que num serviço de newsletter (DKIM através de CNAME, lição 7.1). Mantenha o email transacional e as newsletters separados: uma campanha falhada não pode afetar o email de confirmação das suas encomendas.

A regra de ouro: o endereço do visitante nunca é o remetente

Num formulário de contacto, é tentador fazer com que a mensagem seja enviada "em nome" do visitante. Assim, pode clicar diretamente em Responder no seu programa de correio. Isto teria o seguinte aspeto:

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Mas o seu servidor não tem autorização para enviar correio em nome de example.net. Suponha que example.net tem uma política DMARC p=reject. O servidor recetor (o seu, ou o do Gmail se redirecionar o correio) vê uma mensagem com From example.net que não passa pelo SPF ou DKIM de example.net, e recusa-a. Muitos domínios de correio grandes têm uma política rigorosa: numa verificação feita a 8 de novembro de 2026, domínios como yahoo.com, aol.com, ziggo.nl e kpnmail.nl tinham uma política DMARC p=reject, e icloud.com, gmx.de e web.de tinham p=quarantine. Um visitante com um endereço desses preenche o seu formulário, e você nunca recebe a mensagem, ou recebe-a na pasta de spam. Domínios com p=none (como, nesse momento, gmail.com e hotmail.com) podem reforçar a sua política a qualquer momento, e a Google refere explicitamente nas suas diretrizes que não é permitido imitar endereços Gmail no From. Portanto, nunca conte que vai correr bem.

A forma correta:

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

O remetente é o seu próprio endereço, pelo que o SPF, o DKIM e o DMARC ficam corretos. O endereço do visitante fica em Reply-To. Se clicar em Responder, a sua resposta vai para o Pieter. Na maioria dos plugins de formulários, encontra isto nas definições de correio: coloque em Remetente (From) um endereço fixo do seu próprio domínio, e em Reply-To o campo onde o visitante introduz o seu endereço.

Proteger os formulários contra uso indevido

Um formulário sem proteção acaba, mais cedo ou mais tarde, por ser encontrado por bots. No melhor dos casos, recebe spam. No pior dos casos, usam-no para enviar spam a terceiros: se o seu formulário enviar uma confirmação para "o endereço que o visitante preenche", um bot pode introduzir aí qualquer endereço do mundo, com texto próprio na mensagem. Nesse caso, o seu domínio envia spam, com todas as consequências para a sua reputação (lição 5.2).

Proteção em camadas:

• Captcha ou uma verificação invisível (como reCAPTCHA ou Turnstile) impede a maioria dos bots.
• Honeypot: um campo oculto que as pessoas não veem mas os bots preenchem. Se for preenchido, a mensagem não é enviada.
• Sem texto livre numa confirmação ao visitante, ou nenhuma confirmação enviada para o endereço indicado. Uma simples mensagem "Obrigado, recebemos a sua mensagem" na página é suficiente.
• Um limite de envio por caixa de correio para a caixa de correio do site, inferior ao do seu pacote.
• Manter o software atualizado. Plugins desatualizados são uma via conhecida de uso indevido.

Reparou que o seu pacote envia de repente muito correio ou recebeu um aviso de que o limite diário foi atingido quando você próprio envia pouco correio? Altere imediatamente as palavras-passe e verifique qual o formulário ou script que está a enviar o correio (lição 3.4).

O correio está noutro local, o site está aqui

Uma armadilha comum: o seu site está alojado numa empresa, e o seu correio noutra (por exemplo, Microsoft 365 ou Google Workspace). O seu MX aponta para essa outra empresa. Mas o servidor web ainda pensa que é ele próprio a tratar o correio do seu domínio, porque o domínio também está configurado no seu próprio pacote. O correio do formulário para info@example.com é então entregue localmente, numa caixa de correio no servidor web que ninguém consulta, ou é devolvido um erro como 550 ... mailbox unavailable.

A solução é indicar no painel do servidor web que o correio é tratado noutro local. No DirectAdmin do WebOké, isto corresponde à opção "Usar este servidor para tratar o meu email" em Registos MX (DNS) (desativar). Outros painéis têm definições semelhantes, como "encaminhamento de email: externo" no cPanel. Melhor ainda: faça o site enviar correio através de SMTP com uma caixa de correio na empresa onde o seu correio realmente está.

Resumo

• O correio do site é verificado com o mesmo rigor que o correio normal. Faça com que o site envie correio através de SMTP com autenticação, não através de mail().
• Use uma caixa de correio separada para o site, com um limite de envio próprio.
• O endereço do visitante pertence ao Reply-To, nunca ao From. Caso contrário, o DMARC falha, e em domínios com p=reject (como yahoo.com, ziggo.nl, kpnmail.nl) a mensagem é recusada.
• Proteja os formulários com captcha, honeypot e sem confirmações de texto livre enviadas para endereços indicados.
• Se o seu correio estiver noutra empresa, desative a entrega local no servidor web ou envie correio através de SMTP dessa empresa.

Quiz

Exercício

Exercício O7.3: Rever o correio do sítio web. Preencha um formulário no seu próprio site com um endereço Gmail ou Outlook.com como remetente e consulte as cabeçalhos da mensagem que lhe chega. Responda à lista de verificação: que endereço consta no From, está o endereço do visitante no Reply-To, o que indicam spf=, dkim= e dmarc= em Authentication-Results, o seu site envia correio através de SMTP ou de mail(), e o formulário tem captcha ou honeypot? Se não tiver um site próprio, responda às perguntas com base no exemplo desta lição. Receberá depois a resposta modelo.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis do WebOké; noutros fornecedores o funcionamento é semelhante.

• Um formulário de contacto no seu website: enviar os campos por e-mail e evitar spam
• Como obtenho o remetente correto com mail() em PHP? SMTP
• Não consigo enviar e-mail via PHP: os registos MX apontam para outro lado
• Limite para o envio de correio eletrónico
• Limite diário de e-mails atingido
• Manual DirectAdmin 8.1: Todas as definições num relance: servidores, portas e segurança
• Manual DirectAdmin 5.10: E-mail no Microsoft 365 ou Google Workspace, website na WebOké