Ferramentas de Diagnóstico de Rede
Valide seu registro Sender Policy Framework
DNS e Registros
Consulta DNS Todos os registros DNS de qualquer domínio Consulta de Registro A Endereços IPv4 de um domínio Consulta de Registro AAAA Endereços IPv6 de um domínio Consulta MX Servidores de e-mail de um domínio Consulta NS Servidores de nomes autoritativos Consulta TXT Registros TXT, SPF, verificação Consulta CNAME Registros de nome canônico (alias) Consulta SOA Registro Start of Authority Consulta SRV Registros de localização de serviço Consulta CAA Quais ACs podem emitir certificados DNS Reverso (PTR) Endereço IP para hostname Verificação DNSSEC O domínio está assinado e validado? Diagnóstico de DNS Um relatório completo de delegação e DNSEntregabilidade de E-mail
Verificação SPF Valide seu registro Sender Policy Framework Verificação DMARC Inspecione e avalie sua política DMARC Verificação DKIM Encontre e valide sua chave pública DKIM Verificação de Blacklist Verifique um IP em listas de bloqueio de e-mail (DNSBLs) Teste SMTP Conecte-se a um servidor de e-mail e verifique o STARTTLS Verificação MTA-STS Política de TLS obrigatório para e-mail de entrada Verificação BIMI Registro de logotipo da marca para e-mail Verificação TLS-RPT Política de relatórios de TLS do SMTPRede e Web
Verificação de Certificado SSL Inspecione o certificado TLS e a validade de um site Verificação de Cabeçalhos HTTP Inspecione cabeçalhos de resposta, redirecionamentos e segurança Ping (TCP) Acessibilidade e latência por TCP Verificação de Portas Quais portas comuns estão abertasDomínio
Consulta WHOIS Dados de registro de domínios, IPs e ASNsO SPF (Sender Policy Framework) informa aos servidores de e-mail de destino quais hosts podem enviar e-mail em nome do seu domínio. Um registro SPF quebrado — duplicado, com excesso de consultas DNS ou sem o mecanismo 'all' — faz com que e-mails legítimos caiam no spam. O IPeek localiza seu registro SPF, analisa cada mecanismo e sinaliza os problemas que prejudicam a entregabilidade.
O SPF fica em um registro TXT no domínio raiz, começando com v=spf1. Quando um servidor recebe um e-mail que diz ser seu, ele consulta esse registro e verifica se o IP de envio está autorizado. Um registro como v=spf1 include:_spf.google.com ip4:198.51.100.10 -all significa "permitir os hosts do Google e este único IP, rejeitar todo o resto". Os mecanismos são avaliados da esquerda para a direita; o primeiro que corresponder vence. O mecanismo all no final é o curinga que define o resultado padrão para qualquer host não listado explicitamente.
O mecanismo all define sua política: -all é um hardfail (rejeita remetentes não listados), ~all é um softfail (aceita, mas marca como suspeito) e +all permite qualquer um — nunca use. O SPF também limita os mecanismos que fazem consulta DNS (include, a, mx, ptr, exists, redirect) a 10 consultas no total; ultrapassar esse limite gera um permerror, tratado como falha. Includes aninhados também contam, então adicionar vários fornecedores consome esse orçamento sem que você perceba. O IPeek conta cada consulta e avisa antes de você atingir o teto.
O SPF sozinho não basta. Ele autentica o remetente do envelope (o return-path), e não o endereço From visível que os usuários veem, então quem faz spoofing pode passar no SPF enquanto falsifica sua marca. O DMARC fecha essa brecha exigindo o alinhamento entre o domínio do SPF e o domínio From, e combinando o SPF com o DKIM para que qualquer um deles possa autenticar uma mensagem. Trate o SPF como uma de três camadas: o SPF autoriza hosts, o DKIM assina o conteúdo e o DMARC os vincula ao seu domínio From e aplica a política.
O SPF permite no máximo 10 mecanismos que fazem consulta DNS por avaliação. Os mecanismos include, a, mx, ptr, exists e redirect consomem consultas, e includes aninhados contam para o mesmo limite. Ultrapassar 10 produz um permerror, que os destinatários tratam como falha de autenticação. Achate ou consolide os includes para ficar abaixo do limite.
A diferença está na aplicação. -all é um hardfail que diz aos destinatários para rejeitar e-mails de qualquer host não listado no seu registro, enquanto ~all é um softfail que diz para aceitar, mas tratar como suspeito. Use ~all durante os testes e passe para -all depois de confirmar que todos os remetentes legítimos estão autorizados. Evite +all, que autoriza qualquer um.
Um registro SPF sozinho não garante a entrega na caixa de entrada. Causas comuns incluem ultrapassar o limite de 10 consultas (permerror), um mecanismo all ausente ou permissivo demais, um host de envio que na verdade não está autorizado ou registros SPF duplicados no mesmo domínio. O SPF também não protege seu endereço From visível — você precisa de DKIM e DMARC junto dele para uma boa entregabilidade.
Não. Um domínio deve publicar exatamente um registro TXT de SPF (v=spf1). Dois ou mais registros SPF causam um permerror, e os destinatários podem rejeitar ou falhar a autenticação do seu e-mail. Se você precisa autorizar vários remetentes, combine-os em um único registro usando mecanismos include ou ip4/ip6 adicionais, em vez de criar um segundo registro.
Não. O SPF autentica o remetente do envelope (o return-path ou MAIL FROM), e não o cabeçalho From que seus destinatários realmente veem. É por isso que o SPF sozinho não consegue impedir o spoofing da sua marca. O DMARC adiciona o alinhamento de SPF, exigindo que o domínio do SPF corresponda ao domínio From visível, o que fecha a lacuna entre as verificações de protocolo e o que os usuários leem.