Email Profissional: SPF, DKIM e DMARC Explicados sem Jargão

O cliente diz que não recebe os emails da empresa. A newsletter vai para o spam. As confirmações de compra do WooCommerce nunca chegam. Na maioria dos casos, a causa é a mesma: SPF, DKIM ou DMARC mal configurados — ou simplesmente inexistentes. Este guia explica o que são, porque importam, e como configurar correctamente.

O problema: porque é que os emails chegam ao spam?

Os servidores de email de destino (Gmail, Outlook, etc.) usam dezenas de factores para decidir se um email é legítimo ou spam. Três dos mais importantes são registos DNS que provam que o servidor que enviou o email tem autorização do dono do domínio. Sem eles, o email parece suspeito — mesmo sendo completamente legítimo.

Desde Fevereiro de 2024, o Google e o Yahoo exigem SPF e DKIM configurados para qualquer domínio que envie mais de 5.000 emails por dia. Para volumes menores, continuam a ser fortemente recomendados para evitar que os emails caiam no spam.

SPF — Sender Policy Framework

O que faz: lista quais os servidores que têm autorização para enviar email em nome do seu domínio.

Analogia: é como uma lista de aprovados na portaria — só estes servidores podem entrar em nome da sua empresa.

Formato: um registo TXT no DNS do domínio. Exemplo:

v=spf1 include:_spf.google.com include:mailgun.org ~all

Este exemplo autoriza os servidores do Google Workspace e do Mailgun a enviarem email em nome do domínio. O ~all no final diz "rejeitar softly" (marcar como suspeito) emails de servidores não listados.

Erro comum: ter mais de um registo SPF no DNS — isso invalida o SPF completamente. Deve existir apenas um registo v=spf1 que inclui todos os servidores.

DKIM — DomainKeys Identified Mail

O que faz: assina criptograficamente cada email enviado, provando que não foi alterado em trânsito e que o remetente é legítimo.

Analogia: é como um selo de cera num envelope — prova que foi a sua empresa a fechar o envelope e que ninguém o abriu no caminho.

Como funciona: o servidor de email usa uma chave privada para assinar o email. O destinatário verifica a assinatura usando a chave pública publicada no DNS do domínio. Se a assinatura for válida, o email é autêntico.

Configuração: o fornecedor de email (Google Workspace, Microsoft 365, Mailgun) gera um par de chaves e fornece um registo TXT para adicionar ao DNS. O selector é geralmente algo como:

google._domainkey.exemplo.pt TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DMARC — Domain-based Message Authentication, Reporting and Conformance

O que faz: define o que deve acontecer quando um email falha as verificações SPF ou DKIM — e pede relatórios sobre esses casos.

Analogia: é a política da portaria — "se alguém tentar entrar sem estar na lista aprovada, o que faço? Deixo entrar mesmo assim? Bloqueo? E aviso alguém?"

As três políticas DMARC:

• p=none — monitorizar apenas, não tomar acção. Ideal para começar (recolher dados sem arriscar bloquear email legítimo).
• p=quarantine — enviar para spam os emails que falham. Passo intermédio.
• p=reject — rejeitar completamente emails que falham. Máxima protecção, mas requer confiança total na configuração SPF e DKIM antes de activar.

Exemplo de registo DMARC básico:

_dmarc.exemplo.pt TXT "v=DMARC1; p=none; rua=mailto:dmarc@exemplo.pt"

O campo rua recebe relatórios XML diários dos servidores de email de todo o mundo sobre emails enviados em nome do seu domínio. Ferramentas como DMARC Analyzer ou MXToolbox interpretam esses relatórios de forma legível.

A sequência correcta de implementação

Implementar na ordem errada (ex: activar DMARC reject antes de DKIM estar correcto) pode bloquear email legítimo. A ordem correcta:

• 1. Configurar SPF — listar todos os servidores que enviam email em nome do domínio
• 2. Configurar DKIM — para cada serviço de email usado (Google Workspace, Mailgun, SMTP do WooCommerce)
• 3. Adicionar DMARC com p=none e endereço de relatórios
• 4. Monitorizar relatórios DMARC durante 2-4 semanas — identificar servidores legítimos não listados no SPF
• 5. Corrigir SPF se necessário
• 6. Mudar DMARC para p=quarantine e aguardar 2 semanas
• 7. Mudar para p=reject quando confiante que toda a configuração está correcta

Email transacional do WordPress: o passo que toda a gente esquece

O WordPress envia emails (confirmações de encomenda, reset de password, notificações de formulários) usando a função wp_mail(). Por defeito, usa o servidor PHP do hosting para enviar — que frequentemente não está na lista SPF do domínio e não tem DKIM configurado.

Solução: plugin SMTP (WP Mail SMTP, Fluent SMTP) que envia email transacional via um serviço dedicado (Mailgun, SendGrid, Brevo, ou o próprio Gmail/Outlook). O serviço tem SPF e DKIM correctamente configurados, e os emails chegam ao destino.

Como verificar se está tudo configurado

Ferramentas gratuitas para verificação:

• MXToolbox → Email Health — verifica SPF, DKIM, DMARC e blacklists num só lugar
• mail-tester.com — envia um email de teste e recebe pontuação detalhada com o que está correcto e errado
• Google Admin Toolbox → Check MX — diagnóstico específico para Google Workspace