Analisador de registros SPF, DMARC e DKIM

Cole o registro TXT ou escolha o tipo. A conferência é apenas de texto: sem consulta DNS, sem validar assinaturas e sem testar entrega.

Funciona localmente no seu navegador
Esta ferramenta processa todos os dados localmente no seu navegador.
Registro DNS TXTCole um registro TXT SPF, DMARC ou DKIM. O texto é conferido com o respectivo RFC: sem consulta DNS e sem validação de assinatura.
Resumo

Como ler um registro SPF, DMARC ou DKIM

O analisador lê o registro colado como texto e o compara com as regras da própria especificação: mecanismos e modificadores SPF (RFC 7208), tags DMARC (RFC 7489) e registros de chave DKIM (RFC 6376, atualizado pelo RFC 8301). Cada aviso indica a regra que a linha quebra.

Nada é consultado e nada é verificado: não há consulta DNS, nenhuma assinatura de mensagem é conferida e nenhuma entrega é testada. Um registro aprovado aqui é texto coerente; se ele corresponde ao que o domínio publica precisa ser confirmado no DNS.

  1. Cole o valor do registro TXT ou pressione Carregar exemplo. Mantenha a tag v= e as aspas como foram publicadas.
  2. Deixe o tipo em Detectar automaticamente ou escolha SPF, DMARC ou DKIM quando o registro for ambíguo.
  3. Pressione Analisar localmente. O relatório mostra achados, uma tabela com os termos ou tags do registro e contadores como o orçamento de consultas SPF, escrito x / 10.
  4. Leia a tabela ao lado dos achados: o qualificador e a observação repetem o que foi sinalizado, e a visão JSON leva os mesmos dados para um chamado.
  5. Corrija o registro no editor da zona, aguarde o TTL e cole o texto novamente para confirmar a mudança.

O que cada tipo de registro precisa conter

O que o relatório SPF conta

Os mecanismos são lidos em ordem com seu qualificador (+ pass, - fail, ~ softfail, ? neutral), e o registro não precisa terminar em all: sem ele, ou com redirect=, o resultado de um host sem correspondência depende dos valores que você informou.

O limite de dez termos do RFC 7208 cobre include, a, mx, ptr, exists e redirect. ip4, ip6, all e exp não contam, e termos duplicados contam de novo. Mecanismos escritos depois de all aparecem na tabela, mas nunca são avaliados.

Tags DMARC que mudam o comportamento

v=DMARC1 precisa vir primeiro, e p= (none, quarantine ou reject) é o que os receptores aplicam; sp= define a política dos subdomínios e pct= limita a parcela de mensagens afetada.

rua= e ruf= esperam URIs, normalmente endereços mailto:. adkim e aspf aceitam r ou s, fo só faz sentido junto de ruf=, rf define apenas afrf, e tags que o DMARC não define são ignoradas em vez de invalidar o registro.

Chaves DKIM e o que as torna utilizáveis

A chave é publicada por seletor: v=DKIM1 primeiro, k= com rsa ou ed25519, e p= com a chave pública em base64. Um p= vazio não é erro: revoga a chave.

O RFC 8301 fixa o piso criptográfico: chave abaixo de 1024 bits não gera assinatura válida, 2048 bits é o tamanho recomendado e SHA-1 não deve ser usado. A tag s= precisa incluir email, e t=y declara modo de teste.

O que uma checagem de texto não vê

Cadeias de include do SPF, alinhamento do DMARC e registros de seletor do DKIM são resolvidos por DNS na hora da entrega. O analisador só julga o texto que recebe, então a ausência de avisos não garante que o domínio envie e-mail autenticado.

O registro de chave DKIM também depende do seletor: cole o registro do seletor que realmente assina (por exemplo selector1._domainkey), não o da raiz do domínio.

Ferramentas recentes: