SPF, DKIM e DMARC: os registos DNS que protegem o seu e-mail
O e-mail foi desenhado numa era em que a confiança era assumida: qualquer servidor podia enviar um e-mail alegando ser de qualquer domínio. O SPF, DKIM e DMARC são registos DNS que resolvem este problema, autenticando quem pode enviar e-mails em nome do seu domínio e o que fazer com e-mails não autorizados.
SPF: Sender Policy Framework
O SPF define quais servidores estão autorizados a enviar e-mail em nome do seu domínio. É um registo TXT no DNS que lista os IPs ou hostnames permitidos. Quando o servidor do destinatário recebe um e-mail do seu domínio, verifica o SPF: se o servidor de envio não está na lista, o e-mail é marcado como suspeito ou rejeitado.
Exemplo de registo SPF:
Este exemplo é ilustrativo. Adapte domínio, caminhos e valores ao ambiente e teste numa cópia antes de aplicar. Não repita constantes já definidas nem regras geridas por outra ferramenta.
v=spf1 ip4:192.0.2.10 ~allO endereço 192.0.2.10 é reservado a exemplos e não é o seu servidor. Publique apenas uma política SPF adequada aos emissores reais. ~all indica softfail; o destinatário decide como usar esse resultado.
DKIM: DomainKeys Identified Mail
O DKIM adiciona uma assinatura digital a cada e-mail enviado. O servidor de envio assina o e-mail com uma chave privada, e o servidor de receção verifica a assinatura com a chave pública publicada no DNS. Se a assinatura é válida, o e-mail é autêntico e não foi alterado em trânsito.
Connosco, o DKIM é gerado automaticamente pelo cPanel. Pode verificar e ativar em cPanel → E-mail → Email Deliverability.
DMARC: Domain-based Message Authentication, Reporting and Conformance
O DMARC junta SPF e DKIM e define a política do que fazer com e-mails que falham a autenticação: none (apenas reportar), quarantine (enviar para spam) ou reject (rejeitar). Também define para onde enviar relatórios de autenticação.
Exemplo de registo DMARC mínimo:
v=DMARC1; p=none; rua=mailto:[email protected]Recomendação: comece com p=none para monitorizar durante 2-4 semanas. Analise os relatórios para garantir que e-mails legítimos passam. Depois avance para p=quarantine e eventualmente p=reject.
Porque é importante
Sem estes registos, qualquer pessoa pode enviar e-mails fingindo ser do seu domínio (spoofing). Clientes podem receber e-mails de phishing que parecem vir da sua empresa. Os seus e-mails legítimos podem ir para spam porque não estão autenticados. Desde 2024, o Google e o Yahoo exigem SPF, DKIM e DMARC para remetentes de volume.
Como verificar
No cPanel, vá a E-mail → Email Deliverability. A ferramenta analisa automaticamente os registos SPF e DKIM de cada domínio e indica problemas. O botão Repair corrige automaticamente os registos quando o DNS é gerido pelo cPanel.
Inventariar todos os serviços que enviam pelo domínio
Liste o alojamento, a plataforma de marketing, a faturação e outras aplicações. SPF deve ser uma política única por domínio; DKIM permite assinaturas com seletores próprios; DMARC verifica alinhamento e aplica a política definida pelo titular.
Comece a mudança com conhecimento dos fluxos legítimos e acompanhe relatórios. Não aplique reject às cegas, pois pode bloquear mensagens da própria empresa. A configuração correta ajuda a autenticar o remetente, mas reputação, qualidade das listas e conteúdo continuam a influenciar a entrega.
Como validar o envio antes de considerar o problema resolvido
Uma verificação útil começa por identificar todos os serviços que enviam mensagens com o domínio da empresa: caixas dos colaboradores, site WordPress, plataforma de faturação, formulários e campanhas. Cada origem tem de ser analisada separadamente. Um registo SPF aparentemente correto não substitui a assinatura DKIM, e uma política DMARC não deve ser endurecida sem consultar os relatórios e confirmar os remetentes legítimos.
Depois de uma alteração, envie mensagens de teste para destinatários externos e consulte os cabeçalhos completos quando existirem rejeições. Procure os resultados de autenticação e a identificação do servidor que enviou a mensagem. Se um e-mail chegar à pasta de spam, isso não significa necessariamente que o servidor esteja indisponível; pode haver uma questão de reputação, conteúdo, alinhamento dos domínios ou regras do destinatário. Registe exemplos com data e destinatário antes de pedir assistência.
Evite interromper serviços ligados ao domínio
O nome de domínio costuma estar associado a mais serviços do que o site. Antes de alterar nameservers ou registos, guarde a zona DNS e identifique entradas A, AAAA, CNAME, MX e TXT que estejam em utilização. Verifique também subdomínios, plataformas de envio de correio e serviços de validação. Uma alteração pensada apenas para a página pública pode interromper o e-mail empresarial.
Depois da mudança, teste separadamente o endereço principal, a versão com www, o envio e a receção de mensagens e eventuais aplicações externas. A propagação de alterações depende de caches e valores TTL, pelo que os resultados podem variar temporariamente entre redes. Documentar a configuração anterior facilita a resolução de uma falha e reduz o risco de voltar a mexer em parâmetros sem diagnóstico.
O domínio deve permanecer sob controlo da empresa
O domínio identifica o site e as contas de correio, podendo também ser usado para autenticar serviços externos. Conserve informação sobre o titular, os contactos de recuperação, a renovação e a gestão do DNS. Quando uma agência administra o serviço, documente como a empresa pode recuperar o controlo se a relação terminar.
Não concentre os acessos numa única pessoa. Utilize credenciais individuais ou um gestor adequado e defina quem pode autorizar alterações aos nameservers. Uma mudança de DNS pode afetar mais serviços do que a página pública.
Autenticar o envio que a empresa realmente utiliza
Inventarie os serviços que enviam com o domínio antes de alterar os registos de autenticação.
Compare os nossos planos de e-mail profissional tendo em conta o trabalho e o crescimento das caixas. Fale connosco se precisa de ajuda a escolher.