Principais pontos
- SPF (RFC 7208): Publica a lista de endereços IP e serviços de envio autorizados a enviar e-mails usando o seu domínio no remetente do envelope (Return-Path).
- DKIM (RFC 6376): Usa um par de chaves assimétricas para adicionar uma assinatura criptográfica a cada mensagem, comprovando que ela foi autorizada pelo domínio signatário e não foi alterada no caminho.
- DMARC (RFC 7489): Informa aos servidores de destino como tratar mensagens que falham no alinhamento de SPF e DKIM (none, quarantine ou reject) e para onde enviar os relatórios agregados.
- Desde fevereiro de 2024, Gmail e Yahoo exigem que remetentes em massa (o Gmail define assim quem envia mais de 5.000 mensagens por dia para contas pessoais do Gmail) se autentiquem com SPF e DKIM, publiquem um registro DMARC (no mínimo
p=none) e alinhem o domínio do From com o SPF ou o DKIM.
Quando um servidor de e-mail de destino, como Google Workspace, Microsoft 365 ou Yahoo Mail, recebe uma mensagem de contact@yourcompany.com, seus filtros executam uma série de verificações técnicas para decidir se a mensagem realmente vem do proprietário legítimo daquele domínio ou se é uma tentativa de spoofing ou phishing.
Se o seu domínio não tiver os registros de autenticação necessários no DNS (Domain Name System), a mensagem é tratada como de alto risco. Ela provavelmente vai parar na pasta de spam ou será rejeitada diretamente no nível SMTP, o que a sua plataforma de envio registra como bounce.
1. Os três mecanismos fundamentais de autenticação de e-mail
Para entender como os sistemas de segurança de e-mail trabalham em conjunto, vale observar o papel distinto, mas complementar, de cada protocolo:
SPF (Sender Policy Framework)
O SPF funciona como uma lista pública de remetentes autorizados publicada no seu DNS. O registro declara quais servidores, identificados por endereço IP ou por um mecanismo include que aponta para um provedor como Amazon SES, SendGrid ou Mailgun, têm permissão para enviar e-mails em nome do seu domínio. Os servidores de destino verificam o SPF no domínio do remetente do envelope (MAIL FROM / Return-Path), e não no endereço From visível.
DKIM (DomainKeys Identified Mail)
O DKIM verifica a integridade da mensagem. Quando a mensagem sai do servidor de envio, uma assinatura digital é gerada com uma chave privada e adicionada à mensagem como um cabeçalho DKIM-Signature. O servidor de destino obtém a chave pública correspondente no seu DNS e a usa para verificar a assinatura, confirmando que os cabeçalhos e o corpo assinados não foram falsificados nem modificados no caminho.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
O DMARC é a camada que une SPF e DKIM. Ele exige que o servidor de destino verifique se o domínio do endereço de remetente visível (o Header From) corresponde ao domínio autenticado pelo SPF ou pelo DKIM, uma verificação conhecida como alinhamento. Uma mensagem passa no DMARC se pelo menos um dos dois for aprovado e estiver alinhado. O DMARC também define o que o servidor de destino deve fazer quando a autenticação falha e oferece um canal para relatórios agregados (RUA).
2. Estrutura e sintaxe do registro SPF
O registro SPF é publicado como um registro TXT no domínio usado no remetente do envelope. Para e-mails enviados dos seus próprios servidores ou pelo Google Workspace, normalmente é o domínio raiz:
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all
O que significa cada parte do registro:
v=spf1: Declara a versão do SPF em uso. Deve ser o primeiro termo do registro.include:amazonses.com: Autoriza as faixas de IP de envio do Amazon Simple Email Service (SES) a enviar e-mails pelo domínio. Se você também usa o SendGrid, o equivalente éinclude:sendgrid.net. Observe que, com o Amazon SES, o SPF só fica alinhado para o DMARC quando você configura um subdomínio MAIL FROM personalizado (por exemplo,bounce.yourcompany.com) e publica este registro nesse subdomínio, junto com o registro MX fornecido pelo SES. Com a autenticação de domínio do SendGrid e a segurança automatizada ativadas, o próprio SendGrid gerencia o SPF do subdomínio de return-path por meio de um CNAME, então não é necessário um include no domínio raiz.~all(SoftFail): Indica que e-mails de servidores fora da lista devem ser tratados como suspeitos, mas em geral ainda aceitos. É a opção mais comum, principalmente enquanto você ainda está mapeando suas fontes de envio.-all(HardFail): Indica que e-mails de fontes não autorizadas devem ser tratados como falha definitiva. Os servidores de destino podem rejeitá-los, embora muitos grandes provedores de caixa postal hoje considerem o resultado do DMARC em vez de rejeitar apenas com base no SPF.
include, a, mx, ptr, exists e redirect, incluindo consultas aninhadas). Se vários serviços enviam pelo mesmo domínio (por exemplo, Google Workspace e Amazon SES), combine-os em um único registro: v=spf1 include:_spf.google.com include:amazonses.com ~all.
3. Configurando o DKIM
A configuração do DKIM normalmente envolve gerar um par de chaves RSA, sendo 2048 bits o mínimo recomendado atualmente. Ao conectar um provedor de envio pela eMailBase:
- O provedor gera os registros DNS dos seus seletores DKIM. O Easy DKIM do Amazon SES emite três registros
CNAMEno formato<token>._domainkey.yourcompany.com; o SendGrid emite dois registrosCNAMEde DKIM (s1._domainkeyes2._domainkey) mais um para o subdomínio de return-path; o Mailgun normalmente fornece um registro TXT com a chave pública. - Acesse o painel de controle do seu provedor de DNS e crie cada registro exatamente como foi emitido.
- A eMailBase consulta o DNS automaticamente e confirma a ativação assim que os registros forem propagados.
4. Implantando a política DMARC com segurança
Publicar uma política DMARC rígida logo no primeiro dia pode fazer com que e-mails legítimos sejam rejeitados se alguma fonte de envio ainda não estiver totalmente coberta por SPF ou DKIM. O registro DMARC é publicado como um registro TXT em _dmarc.yourcompany.com, e a implantação padrão tem três fases:
| Fase | Sintaxe da política | Objetivo operacional |
|---|---|---|
| Fase 1: Monitoramento | v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com |
Coletar relatórios agregados e identificar todas as fontes de envio legítimas sem afetar a entrega. |
| Fase 2: Quarentena | v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com |
Aplicar a política de quarentena (normalmente, entrega na pasta de spam) a 25% das mensagens reprovadas e aumentar o percentual à medida que os relatórios confirmarem que os e-mails legítimos estão sendo aprovados. O suporte ao pct varia entre os servidores de destino, e a revisão DMARCbis do padrão o elimina. |
| Fase 3: Rejeição | v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com |
Instruir os servidores de destino a rejeitar todos os e-mails reprovados no DMARC, bloqueando o uso não autorizado do seu domínio. |
5. Verificando e solucionando problemas nos registros DNS
Depois de publicar os registros, você pode verificá-los com ferramentas de linha de comando padrão:
dig +short TXT yourcompany.com
# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com
# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com
Em um workspace da eMailBase, essas verificações são executadas automaticamente pelo DNS & Deliverability Manager, que sinaliza conflitos de sintaxe e registros ausentes assim que surgem.
