Verificação de entregabilidade de e-mail
Antes da reputação, antes do conteúdo, os recetores fazem uma única pergunta: este domínio consegue provar que o correio é realmente seu? Esta verificação lê a prova — registos MX, a lista de remetentes SPF (expandida e contada como um recetor a conta), a política DMARC em _dmarc e as chaves DKIM sob os seletores comuns — e devolve conclusões em linguagem simples, ordenadas como um operador as corrigiria.
Quer manter isto vigiado continuamente? Vigie isto grátis com o myeventwatch — alertas de expiração e indisponibilidade, sem cartão.
O que a verificação mede
A filtragem de spam começa pela identidade porque a identidade pode ser verificada em milissegundos. Quando chega correio a dizer que é de um domínio, o servidor recetor consulta as regras publicadas desse domínio. O SPF nomeia os servidores autorizados a enviar. O DKIM oferece uma assinatura para verificar contra uma chave publicada. O DMARC exige que o domínio From visível se alinhe com uma dessas duas provas e estabelece a penalização — nenhuma, quarentena, rejeição — para o correio que não tenha nenhuma. A página chama GET /api/check/email-auth no servidor da sysosx, que lê os mesmos registos através dos analisadores DNS que a verificação de saúde usa, e traduz-os em conclusões: cada protocolo, cada problema, uma gravidade, na ordem em que vale a pena corrigi-los.
Duas das conclusões merecem uma palavra sobre honestidade, porque ambas são sítios onde os verificadores costumam fingir precisão. A contagem de consultas SPF é real: o verificador expande as cadeias de include e redirect termo a termo com as mesmas regras que um recetor aplica, por isso o número que reporta é o que um recetor rigoroso calcularia — incluindo quando o registo se desviou em silêncio acima do limite de dez consultas à medida que os fornecedores mudavam os seus próprios registos. E o resultado DKIM é uma sondagem, não um censo: as chaves são publicadas sob nomes de seletor que o proprietário escolhe, a verificação experimenta os comuns, e não encontrar nenhum não prova que o DKIM está ausente — uma chave sob qualquer outro seletor é invisível do exterior, e o resultado diz isso claramente em vez de declarar um domínio sem assinatura. O único teste DKIM completo continua a ser uma mensagem real e o seu cabeçalho Authentication-Results.
Como ler um resultado
Comece pelas falhas; são as causas favoritas da pasta de spam. Sem MX significa que o domínio não consegue receber correio de todo. Sem SPF, ou um registo SPF a terminar em +all, significa que qualquer pessoa pode dizer que é você — o segundo é pior, porque a afirmação é oficialmente permitida. Vários registos SPF anulam em silêncio a avaliação de SPF por completo. Um registo DMARC em falta significa que o correio que falha não tem penalização declarada e, igualmente custoso, ninguém está a recolher os relatórios agregados que mostram quem envia como o seu domínio — esses relatórios são a forma como as campanhas de falsificação costumam ser descobertas. Quando os relatórios chegam, vêm como XML em bruto; o analisador de relatórios DMARC abre os ficheiros .xml, .gz e .zip localmente e transforma-os numa tabela por origem de quem passou, quem falhou e o que corrigir. Os avisos são o estado intermédio: p=none é um bom sítio para começar o DMARC e um mau sítio para parar; ~all é modo de teste, não um destino. Depois tome a outra metade do quadro: a autenticação prova a identidade, enquanto o verificador de listas negras DNS mede a reputação — execute ambos, porque um domínio perfeitamente autenticado num IP listado continua a cair em spam, e um IP limpo com SPF partido também. O guia que une tudo é porque é que o seu e-mail cai em spam.
Perguntas frequentes
O que são SPF, DKIM e DMARC, e como se encaixam?
São três respostas publicadas em DNS à pergunta «este correio é realmente do domínio que diz ser?». O SPF lista os servidores autorizados a enviar por um domínio. O DKIM permite que um domínio assine criptograficamente as mensagens, para que um recetor possa verificar a assinatura contra uma chave publicada em DNS. O DMARC une-os: exige que o domínio remetente no cabeçalho From visível se alinhe com o resultado de SPF ou de DKIM, e diz aos recetores o que fazer — monitorizar, pôr em quarentena ou rejeitar — quando nenhum se alinha. SPF sem DMARC é uma sugestão sem assinatura; o DMARC é o que transforma os outros dois numa política.
O meu correio continua a cair em spam mesmo com os três a passar. Porquê?
Porque a autenticação é o bilhete de entrada, não a atribuição de lugares. Passar SPF, DKIM e DMARC significa que os recetores acreditam que o correio é genuinamente seu — depois disso, a colocação depende da reputação e do conteúdo: listagens em listas negras (verifique-as com o verificador de listas negras deste site), envolvimento dos destinatários, taxas de queixa, padrões de volume de envio e a própria mensagem. As falhas de autenticação são a causa reparável mais comum da colocação em spam, e é por isso que esta verificação vem primeiro, mas um resultado limpo aqui mais uma colocação persistente em spam significa que o problema vive na reputação ou no conteúdo, não na identidade.
A verificação diz que não foi encontrada nenhuma chave DKIM. Isso significa que o meu domínio não assina?
Não — e o resultado diz isso mesmo, com essas palavras. As chaves DKIM vivem sob nomes de seletor que o proprietário do domínio escolhe, e não há forma de enumerar os seletores de um domínio a partir do exterior. Esta verificação sonda os seletores comuns usados pelos grandes fornecedores (default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill e mais alguns). Uma chave sob qualquer outro nome é invisível para a sondagem. O teste definitivo é uma mensagem real: envie correio para uma caixa que controla e inspecione o cabeçalho Authentication-Results, que reporta o seletor usado e se a assinatura foi verificada.
Porque é que a verificação conta as consultas SPF, e porque é que o limite é 10?
Avaliar um registo SPF pode exigir mais consultas DNS — cada termo include, a, mx, ptr, exists e redirect custa uma. A RFC 7208 limita o total a 10; acima disso, os recetores devolvem um erro permanente e o resultado SPF fica anulado, o que pode ser pior do que um registo modesto que se avalia limpidamente. Os registos acumulam consultas em silêncio à medida que se adicionam fornecedores (cada include traz os seus próprios termos), por isso um registo que era legal na configuração pode desviar-se acima do limite à medida que os fornecedores mudam os seus registos. Esta verificação expande o registo como um recetor faria e reporta a contagem real, para que o desvio seja visível antes de anular a sua autenticação.
O que devo corrigir primeiro se várias conclusões forem falhas?
Por ordem: vários registos SPF (funda-os num só — tudo o resto é pouco fiável até isso estar corrigido), um registo SPF em falta ou com +all (publique a lista real de remetentes, terminada em -all), um registo DMARC em falta (comece em p=none com um endereço de relatórios, para poder ver quem envia como você antes de aplicar), e depois elevar o DMARC de p=none para p=reject à medida que os relatórios chegam limpos. Listagens em listas negras, se existirem, são trabalho paralelo — corrija a sua causa e peça a remoção enquanto os registos são reparados. O nosso guia percorre a ordem com o raciocínio: porque é que o seu e-mail cai em spam.