O site pode funcionar perfeitamente enquanto sua configuração de e-mail facilita falsificação ou impede redefinições de senha. O problema está em registros e serviços de envio, invisível numa revisão visual. Proteja o domínio sem rejeitar correspondência legítima.
O módulo DNS consulta MX, TXT, DMARC, CAA e descoberta MTA-STS do nome alvo. Relata sinais e preserva erros. Avalie o domínio que realmente envia: www.example.com não equivale automaticamente a auditar toda a configuração de correio de example.com.
Escopo desta auditoria
O que pode ser medido
- MX, SPF TXT, _dmarc TXT, CAA e descoberta _mta-sts observados no nome consultado.
- Terminações SPF permissivas ou neutras, contagem direta de mecanismos com consultas DNS e política DMARC de monitoramento.
- Verificações bem-sucedidas compatíveis e erros DNS como evidência.
O que ela não comprova
- O módulo nativo não envia mensagens, inspeciona caixa de entrada nem verifica todos os seletores DKIM.
- A contagem SPF não expande includes recursivamente; número baixo não prova cumprimento do limite.
- TXT MTA-STS presente não prova arquivo HTTPS funcional ou TLS dos servidores de correio.
Analise alvo autorizado e verificado e confira módulos efetivos do plano e perfil. Estes controles avaliam configuração pública; conexão com provedor e prova de entrega são trabalhos separados.
Inventarie remetentes antes de alterar DNS
Liste e-mail interno, suporte, transacional, faturamento, marketing e serviços legados ativos. Registre domínio From visível, remetente do envelope, domínio de assinatura DKIM e responsável. Peça registros atuais a cada fornecedor; não adivinhe include copiando outra empresa.
Guarde nome consultado, resultado e horário. Timeout DNS não é resposta autoritativa afirmando ausência. Revise surpresas com o provedor e considere cache. MX descreve recebimento; domínios podem enviar sem MX. Portanto, ausência de aviso nessa situação não prova envio seguro.
Interprete políticas proporcionalmente
| Observação | Prioridade habitual | Importância |
|---|---|---|
| SPF termina com +all | Alta | Autoriza qualquer remetente |
| SPF ou DMARC não observado em domínio de e-mail | Geralmente média; verificar consulta e domínio | Falta política contra falsificação |
| Aviso de limite SPF | Média | A avaliação pode falhar |
| DMARC p=none | Baixa; pode ser fase intencional | Monitora sem solicitar quarentena ou rejeição |
| Sem CAA ou descoberta MTA-STS | Geralmente baixa | Investigar reforço adicional |
Fraqueza de política não prova entrega de mensagem falsificada. Presença de registro também não garante entrega. Priorize domínios de login, faturas e suporte, cujo abuso prejudica confiança diretamente.
Corrija SPF sem perder remetentes válidos
SPF avalia o emissor conectado contra o domínio do envelope, não autentica diretamente o From visível. Publique uma política coerente com os provedores realmente usados. Evite +all; escolha a política final após testar fontes legítimas.
O protocolo limita a dez os termos que consultam DNS durante avaliação, incluindo includes aninhados e redirects. A contagem textual da Sitelemetry é aviso inicial, não avaliação recursiva. Confira a cadeia inteira com orientação dos provedores. Retire emissores antigos e mecanismos desnecessários primeiro. Substituir includes cegamente por IPs fixos cria manutenção quando a infraestrutura muda.
Leve DMARC do monitoramento à aplicação gradual
DMARC relaciona o From visível à autenticação SPF ou DKIM alinhada. Um mecanismo alinhado pode bastar; ambos não são sempre necessários. DKIM usa seletores específicos do fornecedor, e uma análise pública não pode adivinhar todas as chaves.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comÉ exemplo de monitoramento. Troque o endereço por caixa controlada cujos relatórios possa processar; destinos externos podem exigir autorização DNS. Examine relatórios e teste todos os fluxos, inclusive efeitos de encaminhamento. Corrija alinhamento antes de quarantine ou reject. Uma implantação gradual evita perder faturas e redefinições de senha por inventário incompleto.
CAA e MTA-STS respondem a questões distintas
CAA define autoridades autorizadas a emitir certificados. Compatibilize restrições com fornecedores reais, certificados da CDN e curingas. Uma restrição descuidada pode interromper renovação. CAA ausente é oportunidade de melhoria, não prova de certificado nas mãos de atacante.
MTA-STS permite a remetentes participantes aplicar política TLS à entrega recebida. TXT é só uma parte: arquivo HTTPS, padrões MX e certificados devem concordar. Teste tudo antes de impor. Isso não é HTTPS do site; ausência de TXT não prova que todo e-mail trafega sem criptografia.
Valide registros e entrega real
- Salve valores DNS atuais e responsáveis por serviços.
- Publique a mudança revisada no provedor autoritativo e confirme o nome consultado.
- Confira após prazos de cache e repita o mesmo escopo.
- Envie mensagens controladas de cada serviço para contas próprias.
- Inspecione autenticação do destinatário e relatórios DMARC; confirme senhas, faturas e respostas de suporte.
Separe política de monitoramento de entrega. Reputação, filtros e conteúdo influenciam mesmo com autenticação aprovada. Documente erros DNS, seletores não avaliados e serviços não testados para o resumo verde não ocultar lacunas.
Perguntas frequentes
A Sitelemetry confirma que todos os e-mails chegam à caixa de entrada?
Não. DNS público avalia sinais de configuração. Entrega exige mensagens controladas, resultados de autenticação no destinatário e dados do provedor ou caixa.
DMARC p=none é configuração errada?
Pode ser uma etapa intencional de monitoramento. Não solicita aplicação; revise relatórios e complete alinhamento antes de endurecer.
SPF aprovado ainda pode exceder o limite?
Sim. O controle conta mecanismos visíveis, sem avaliar todos os includes recursivamente. Confira políticas aninhadas antes de afirmar cumprimento completo.
Fontes e leituras
- RFC 7208: Sender Policy Frameworkwww.rfc-editor.org
- RFC 9989: DMARCwww.rfc-editor.org
- RFC 8659: autorização DNS de autoridades certificadoraswww.rfc-editor.org
- RFC 8461: segurança estrita SMTP MTAwww.rfc-editor.org
- RFC 9990: relatórios agregados DMARCwww.rfc-editor.org
Preparado pela equipe Sitelemetry e conferido com o escopo do produto e as fontes primárias citadas. Os exemplos são ilustrativos, salvo quando um caso observado é identificado.
