SPF, DMARC e DKIM: o guia completo de autenticação de e-mail

Seu domínio passa em todas as verificações de segurança. Seu certificado SSL é válido, seus cabeçalhos são rígidos, seu O CSP está bloqueado. Em seguida, um e-mail de phishing chega à caixa de entrada de um cliente, do seu domínio, com o nome da sua empresa no campo "De". O e-mail é falso, mas o dano é real.

Isso acontece porque o e-mail foi projetado em 1982 sem verificação de remetente integrada. Qualquer um pode definir qualquer endereço "De" em um e-mail e sem registros SPF, DMARC e DKIM em seu domínio, os servidores receptores não têm como detectar a falsificação. Mais de 90% dos ataques de phishing usam falsificação de domínio e autenticação de e-mail mal configurada são a porta aberta.

Este guia aborda o que cada registro faz, como funcionam juntos e como auditar todos os três em qualquer domínio com um único script usando o API de segurança DNS botoi.

Como funciona a autenticação de e-mail

Três registros DNS funcionam como camadas de defesa. Cada um resolve um problema diferente:

1. FPS respostas: "Este servidor tem permissão para enviar e-mail para este domínio?"
2. DKIM responde: "Esta mensagem foi alterada depois de sair do servidor do remetente?"
3. DMARC responde: "O que devo fazer se o SPF ou DKIM falhar e para onde envio os relatórios?"

Quando alguém envia um e-mail alegando ser de you@example.com, o recebimento o servidor verifica esses registros em sequência. Se SPF e DKIM falharem e o DMARC disser p=reject, a mensagem será descartada antes de chegar à caixa de entrada. Sem tudo terceiro, existem lacunas que os invasores exploram.

SPF: quem pode enviar em seu nome

SPF (Sender Policy Framework) é um registro DNS TXT na raiz do seu domínio. Ele lista cada Endereço IP e servidor de e-mail autorizado a enviar e-mails para o seu domínio. Quando um servidor receptor recebe um e-mail de example.com, ele verifica o registro SPF para ver se o envio servidor está na lista de aprovados.

Verifique o registro SPF de qualquer domínio com uma única chamada de API:

curl -s -X POST https://api.botoi.com/v1/dns-security/spf-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Resposta:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_spf": true,
    "record": "v=spf1 include:_spf.google.com ~all",
    "mechanisms": ["include:_spf.google.com", "~all"],
    "all_policy": "~all",
    "includes": ["_spf.google.com"],
    "valid": true
  }
}

Os principais campos a serem verificados:

• has_spf: Faz um registro TXT começando com v=spf1 existe? Se for falso, qualquer servidor pode falsificar e-mails do seu domínio.
• valid: O registro é analisado sem erros? Os registros SPF quebram silenciosamente quando eles excedem o limite de pesquisa de 10 DNS.
• all_policy: o mecanismo de rastreamento que define o que acontece com remetentes não listados. -all (falha difícil) os rejeita. ~all (falha suave) os marca como suspeitos. +all permite a todos, o que anula todo o propósito.

O limite de 10 pesquisas

Os registros SPF permitem no máximo 10 pesquisas de DNS. Cada include:, a:, mx:, e redirect: mecanismo conta como uma pesquisa. Inclusões aninhadas conte também. Depois de adicionar o Google Workspace, sua ferramenta de marketing, seu serviço de e-mail transacional, e um CRM, você atinge esse limite rapidamente.

Quando você excede 10 pesquisas, todo o registro SPF se torna inválido. As APIs valid campo captura isso. Corrija-o nivelando inclusões aninhadas em intervalos de IP ou consolidando fornecedores.

DMARC: o que fazer quando as verificações falham

DMARC (Autenticação, Relatórios e Conformidade de Mensagens Baseadas em Domínio) une SPF e DKIM juntos. Ele mora em _dmarc.example.com como um registro TXT e informa ao recebimento servidores duas coisas: o que fazer com mensagens que falham na autenticação e para onde enviar relatórios sobre essas falhas.

Verifique seu registro DMARC:

curl -s -X POST https://api.botoi.com/v1/dns-security/dmarc-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Resposta:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_dmarc": true,
    "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
    "policy": "reject",
    "subdomain_policy": null,
    "reporting": {
      "rua": ["mailto:dmarc@example.com"],
      "ruf": []
    },
    "pct": 100,
    "alignment": {
      "dkim": "r",
      "spf": "r"
    }
  }
}

Políticas DMARC

O policy campo determina o que acontece com mensagens com falha:

• none: Não tome nenhuma ação. Apenas monitorar. Você recebe relatórios, mas e-mails falsificados ainda chegar às caixas de entrada.
• quarantine: mova mensagens com falha para spam. O destinatário ainda pode encontrá-los se eles olharem.
• reject: Elimine completamente as mensagens com falha. A proteção mais forte, mas configuração incorreta significa perda de e-mail legítimo.

Estratégia segura de implementação do DMARC

Indo direto para p=reject é arriscado. Siga este caminho:

1. Comece com p=none; rua=mailto:dmarc@example.com para coletar relatórios por 2 a 4 semanas
2. Revise os relatórios. Identifique quaisquer remetentes legítimos que falhem na autenticação. Corrija suas inclusões SPF e chaves DKIM.
3. Mover para p=quarantine; pct=10 colocar em quarentena 10% das mensagens com falha
4. Aumentar pct para 25, 50 e depois 100 nas próximas semanas, conforme você confirma que nenhum e-mail legítimo foi afetado
5. Mudar para p=reject; pct=100 depois de ter confiança em sua configuração

O pct O campo na resposta da API mostra onde você está nesta implementação. Um domínio em pct=100 com policy=reject tem proteção total.

DKIM: assinaturas criptográficas em todos os e-mails

DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica aos cabeçalhos de cada mensagem de saída. O servidor remetente assina a mensagem com uma chave privada; o servidor receptor verifica-o em relação a uma chave pública publicada em seu DNS. Se a mensagem foi alterada em trânsito (cabeçalhos alterados, corpo modificado, encaminhado através de uma lista de discussão que reescreve o conteúdo), o a assinatura falha.

Registros DKIM ao vivo em [selector]._domainkey.example.com. O seletor é um rótulo seu provedor de e-mail atribui, como google para o Google Workspace ou selector1 para Microsoft 365.

Verifique um registro DKIM:

curl -s -X POST https://api.botoi.com/v1/dns-security/dkim-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com", "selector": "google"}'

Resposta:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "selector": "google",
    "has_dkim": true,
    "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkq...",
    "key_type": "rsa",
    "public_key_length": 2048
  }
}

Campos principais:

• has_dkim: Uma chave pública foi publicada para este seletor? Se for falso, DKIM a verificação falha para todas as mensagens assinadas com este seletor.
• public_key_length: o NIST recomenda um mínimo de 2.048 bits. Chaves abaixo de 1024 os bits são fracos o suficiente para serem fatorados.
• key_type: RSA é o padrão. Ed25519 é mais rápido e usa teclas mais curtas, mas tem suporte limitado ao provedor de e-mail.

DKIM e encaminhamento de e-mail

É por isso que o DKIM é importante mesmo quando o SPF está configurado. Quando alguém encaminha seu e-mail, o IP do servidor de encaminhamento não está no seu registro SPF, portanto o SPF falha. Mas a assinatura DKIM sobrevive ao encaminhamento (desde que o conteúdo não seja modificado). DMARC passa se SPF ou DKIM se alinha, então DKIM é sua rede de segurança para mensagens encaminhadas.

Como os três trabalham juntos

Ameaça	FPS	DKIM	DMARC
E-mail falsificado de servidor não autorizado	Detecta	Detecta (sem assinatura válida)	Aplica a política
Corpo da mensagem adulterado em trânsito	Não detecta	Detecta	Aplica a política
E-mail encaminhado de remetente legítimo	Falha (IP de servidor diferente)	Passes (assinatura intacta)	Aprovado se o DKIM estiver alinhado
Falsificação de subdomínio (user@fake.example.com)	Sem proteção	Sem proteção	Bloqueios via sp=reject
Visibilidade em falhas de autenticação	Nenhum	Nenhum	Envia relatórios agregados

Nenhum registro fornece cobertura completa. SPF sem DMARC significa que as falhas não são aplicadas. DKIM sem SPF significa que qualquer pessoa com uma chave válida pode enviar do seu domínio. DMARC sem ambos SPF e DKIM não têm nada contra o que aplicar.

Audite seu domínio em 30 segundos

Este script de shell verifica todos os três registros e imprime um resumo de aprovação/reprovação. Ele usa o botoi API de segurança DNS; nenhuma chave de API é necessária para até 5 solicitações por minuto.

#!/bin/bash
# Audit SPF, DMARC, and DKIM for a domain in 30 seconds
DOMAIN=\${1:-"example.com"}
DKIM_SELECTOR=\${2:-"google"}
API="https://api.botoi.com/v1/dns-security"
PASS=0
FAIL=0

echo "Auditing email authentication for \$DOMAIN"
echo "==========================================="

# SPF check
SPF=\$(curl -s -X POST "\$API/spf-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_SPF=\$(echo "\$SPF" | jq -r '.data.has_spf')
SPF_VALID=\$(echo "\$SPF" | jq -r '.data.valid')
SPF_RECORD=\$(echo "\$SPF" | jq -r '.data.record // "not found"')
ALL_POLICY=\$(echo "\$SPF" | jq -r '.data.all_policy // "none"')

if [ "\$HAS_SPF" = "true" ] && [ "\$SPF_VALID" = "true" ]; then
  echo "[PASS] SPF: \$SPF_RECORD"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] SPF: \$SPF_RECORD"
  FAIL=\$((FAIL + 1))
fi

if [ "\$ALL_POLICY" = "+all" ]; then
  echo "  WARNING: +all allows any server to send as your domain"
fi

# DMARC check
DMARC=\$(curl -s -X POST "\$API/dmarc-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_DMARC=\$(echo "\$DMARC" | jq -r '.data.has_dmarc')
POLICY=\$(echo "\$DMARC" | jq -r '.data.policy // "not set"')
PCT=\$(echo "\$DMARC" | jq -r '.data.pct // 0')

if [ "\$HAS_DMARC" = "true" ]; then
  echo "[PASS] DMARC: policy=\$POLICY pct=\$PCT%"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DMARC: no record found"
  FAIL=\$((FAIL + 1))
fi

if [ "\$POLICY" = "none" ]; then
  echo "  WARNING: policy=none only monitors, does not enforce"
fi

# DKIM check
DKIM=\$(curl -s -X POST "\$API/dkim-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\", \\"selector\\": \\"\$DKIM_SELECTOR\\"}")

HAS_DKIM=\$(echo "\$DKIM" | jq -r '.data.has_dkim')
KEY_TYPE=\$(echo "\$DKIM" | jq -r '.data.key_type // "unknown"')
KEY_LEN=\$(echo "\$DKIM" | jq -r '.data.public_key_length // 0')

if [ "\$HAS_DKIM" = "true" ]; then
  echo "[PASS] DKIM: selector=\$DKIM_SELECTOR key_type=\$KEY_TYPE key_length=\$KEY_LEN"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DKIM: no record for selector '\$DKIM_SELECTOR'"
  FAIL=\$((FAIL + 1))
fi

if [ "\$HAS_DKIM" = "true" ] && [ "\$KEY_LEN" -lt 2048 ] 2>/dev/null; then
  echo "  WARNING: DKIM key is \$KEY_LEN bits (2048 recommended)"
fi

# Summary
echo ""
echo "Results: \$PASS passed, \$FAIL failed"
[ "\$FAIL" -eq 0 ] && echo "All checks passed." || exit 1

Execute:

bash audit.sh example.com google

O primeiro argumento é o seu domínio; o segundo é o seu seletor DKIM. O script faz 3 API chamadas (dentro do limite do nível gratuito), verifica cada registro, sinaliza avisos para configurações fracas, e sai com um código diferente de zero se alguma verificação falhar. Solte-o em um cron job ou pipeline de CI para monitoramento contínuo.

Se você preferir JavaScript, aqui está a mesma auditoria de uma função assíncrona:

async function auditEmailAuth(domain, dkimSelector = "google") {
  const api = "https://api.botoi.com/v1/dns-security";
  const headers = { "Content-Type": "application/json" };

  const [spf, dmarc, dkim] = await Promise.all([
    fetch(\`\${api}/spf-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dmarc-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dkim-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain, selector: dkimSelector }),
    }).then((r) => r.json()),
  ]);

  return {
    domain,
    spf: {
      exists: spf.data.has_spf,
      valid: spf.data.valid,
      record: spf.data.record,
      allPolicy: spf.data.all_policy,
    },
    dmarc: {
      exists: dmarc.data.has_dmarc,
      policy: dmarc.data.policy,
      pct: dmarc.data.pct,
      reporting: dmarc.data.reporting?.rua || [],
    },
    dkim: {
      exists: dkim.data.has_dkim,
      selector: dkimSelector,
      keyType: dkim.data.key_type,
      keyLength: dkim.data.public_key_length,
    },
  };
}

// Usage
const report = await auditEmailAuth("example.com", "google");
console.log(JSON.stringify(report, null, 2));

Configurações comuns do provedor

Cada provedor de e-mail tem seu próprio domínio SPF e seletor DKIM. Aqui estão os valores para os provedores mais comuns:

Provedor	FPS inclui	Seletor(es) DKIM
Google Workspace	include:_spf.google.com	google
Microsoft 365	include:spf.protection.outlook.com	selector1, selector2
Amazon SES	include:amazonses.com	Baseado em UUID (verifique o console SES)
SendGrid	include:sendgrid.net	s1, s2
Carimbo postal	include:spf.mtasv.net	Por domínio (verifique as configurações de DNS do carimbo postal)
Mailchimp / Mandril	include:servers.mcsv.net	k1

Se você usa vários provedores, seu registro SPF inclui todos eles em uma única entrada TXT. Por exemplo: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Assistir o limite de 10 pesquisas à medida que você adiciona provedores.

Pontos-chave

• FPS controla quais servidores podem enviar e-mails para seu domínio. Verifique com o /v1/dns-security/spf-check ponto final. Fique atento ao limite de 10 pesquisas e evitar +all.
• DMARC define o que acontece quando o SPF ou DKIM falha. Distribua gradualmente a partir p=none para p=reject usando o pct campo. Sempre definido um rua endereço para receber relatórios.
• DKIM prova a integridade da mensagem com assinaturas criptográficas. Usar 2048 bits mínimo de chaves e verifique se seu seletor está publicado com /v1/dns-security/dkim-check.
• Todos os três registros funcionam juntos. O SPF sozinho não impede a falsificação de e-mails encaminhados. DKIM sozinho não informa aos receptores o que fazer em caso de falha. DMARC sem SPF e DKIM não tem nada a impor.
• Automatize suas verificações. Execute o script de auditoria em um agendamento ou em CI para detectar desvios de DNS, provedor migrações e exclusões acidentais de registros antes que afetem a capacidade de entrega.