A autenticação de remetente tem um modo de falha incomum: os registros estão certos, os verificadores online concordam que estão certos, e a mensagem continua sendo tratada como não autenticada. Isso acontece porque os verificadores conferem aquilo que você publicou e o destinatário confere a relação entre aquilo que você publicou e a mensagem. São perguntas diferentes. Abaixo estão quatro maneiras pelas quais já vimos a segunda ser respondida com não enquanto a primeira era respondida com sim, tiradas de configurar isso em domínios que não são nossos.
01O que é conferido é o alinhamento, não o registro
Um registro SPF publicado prova que algum servidor pode enviar por algum domínio. Uma assinatura DKIM válida prova que alguma chave assinou a mensagem. Nenhum dos dois diz que o domínio em questão é aquele que o destinatário vê no cabeçalho From, e essa é a única coisa que o DMARC avalia.
Existem portanto dois domínios em toda mensagem e a maior parte das ferramentas mostra apenas um. O domínio From visível é o que o destinatário lê. O domínio do Return-Path, contra o qual o SPF é de fato conferido, é definido por quem envia, e por padrão isso é o seu provedor. Uma mensagem pode passar no SPF de forma impecável contra um host do provedor enquanto o DMARC registra falha, porque o SPF passou para um domínio que não é o seu.
O DMARC precisa de apenas um dos dois alinhamentos, e essa é a parte que vale internalizar. Alinhamento de SPF por um Return-Path próprio, ou alinhamento de DKIM por uma assinatura que carregue o seu domínio: qualquer um dos dois basta. É por isso que um domínio pode exibir SPF verde e mesmo assim falhar, e por isso que corrigir o DKIM resolve muitas vezes um problema que parecia ser de SPF.
02O CNAME com proxy que responde o endereço errado
Essa é a que mais tempo nos custou e produz o falso sucesso mais convincente das quatro. Registros de autenticação costumam ser CNAME para a zona de um provedor. Em um DNS com proxy, um CNAME pode ser marcado para levar o tráfego pelo proxy, e um registro com proxy não responde o alvo. Ele responde os endereços da borda, porque essa é exatamente a função dele.
Para um site esse é o comportamento correto e a razão de as pessoas usarem isso. Para um seletor DKIM é fatal de um jeito bem específico: a consulta tem sucesso. O nome resolve, alguma coisa responde, nada acusa erro. O que volta é um registro de endereço onde se esperava uma chave, então o verificador não encontra chave nenhuma e trata a mensagem como não assinada. Nada nessa sequência parece configuração errada visto de fora.
Isso continua acontecendo porque o padrão foi pensado para o caso comum. Quase todo registro que se adiciona a uma zona é para um site, e a interface oferece o proxy porque em geral é o que se quer. Registros de autenticação são a exceção, e são adicionados por alguém seguindo instruções que nada dizem sobre uma opção inventada pelo provedor de DNS.
03O seletor que te deram já está em uso
Um seletor DKIM é um rótulo que permite a um mesmo domínio manter várias chaves ao mesmo tempo. Provedores escolhem um padrão e o reutilizam em toda conta que já abriram, o que não é problema até o dia em que um domínio tem duas relações com o mesmo provedor.
Um dos domínios que autenticamos é um exemplo vivo. O provedor dele atribui s1 e s2 por padrão, e os dois já estão publicados ali por uma conta anterior à nossa. Se tivéssemos aceitado o padrão, nossos registros teriam colidido com registros em funcionamento num domínio que não controlamos, e a falha teria chegado na forma de correio quebrado para outra pessoa. Usamos um seletor distinto exatamente por isso.
Existe uma segunda armadilha dentro da primeira, e ela só aparece quando a segunda chave é emitida. É comum o provedor derivar o segundo seletor acrescentando um dígito ao primeiro. Escolha um seletor que já termina em dígito e o par que você recebe não é o par que esperava. Escolhemos um nome sem dígito final depois de confirmar esse comportamento contra a API real, e não contra a documentação.
- Consulte os seletores padrão do provedor no domínio antes de adicionar qualquer coisa. Registros existentes indicam uma relação existente sobre a qual ninguém te avisou.
- Nunca suponha que um domínio tem um só provedor de e-mail. Marketing, transacional, suporte e um contrato herdado são quatro relações e frequentemente quatro fornecedores.
- Escolha um seletor que identifique o remetente, não o ano nem o número de ordem. Ele fica legível no DNS para quem for auditar aquela zona depois.
04Apontar para o host do fornecedor torna o registro dele, não seu
Essa não é uma falha do dia, é uma falha dezoito meses depois, e é a razão de nossos registros não se parecerem com os que a maioria dos serviços distribui.
Um provedor te dá CNAME para a zona dele, e o movimento óbvio é repassar isso ao cliente sem alterar. Funciona na hora. Também coloca um host do fornecedor dentro de uma zona que você não controla, uma vez por cliente. Trocar de provedor passa então a significar pedir a cada cliente que edite o DNS, o que na prática significa que uma parte deles nunca vai fazer isso e vai parar de autenticar em silêncio.
Por isso apontamos os registros do cliente para hosts nossos, e esses apontam para o provedor. O salto extra custa uma consulta e transforma uma migração em três registros de uma zona que é nossa, em vez de um e-mail em massa. Uma cadeia real se lê como o seletor do cliente, depois nosso alias, depois o alvo do provedor, que é o mesmo que qualquer CNAME de fornecedor faz, com uma indireção acrescentada no único ponto em que ela ajuda.
O preço desse desenho é uma forma nova de errar, e é melhor nomeá-la do que escondê-la. Os alvos do provedor contêm identificadores atribuídos e não garantidos, entre eles um identificador de pool que pode mudar. Se mudar, nossos alias apontam para algo inútil e todos os clientes param de autenticar de uma vez, sem barulho, porque os registros continuam resolvendo. Verificamos esse desvio de forma periódica pela mesma razão que verificamos tudo: a falha é invisível por dentro.
05Um clique é decisão do provedor, não um padrão da indústria
Pedir ao cliente que adicione três registros é onde a integração empaca, e a resposta padrão é o Domain Connect: o cliente é levado ao próprio provedor de DNS, esse provedor o autentica, mostra os registros e os escreve se ele concordar. Ninguém entrega credencial a ninguém.
O que é fácil de ler errado é o que publicar um modelo de fato garante. Ter o modelo aceito no repositório público é necessário e não é suficiente, porque os provedores adotam modelos um a um. Um modelo pode ser público e correto por anos sem que um determinado provedor de DNS jamais o tenha servido.
O modelo de um provedor de envio bastante conhecido está aceito desde 2022. Consultá-lo hoje em um grande provedor de DNS devolve 404, o que significa que todos os clientes daquele provedor continuam adicionando esses registros à mão. Conferimos antes de supor, porque supor teria significado mostrar aos clientes um botão que não leva a lugar nenhum.
Essa é a forma geral de tudo o que veio acima. Pergunte ao provedor se ele serve o modelo antes de oferecer o botão. Resolva o registro e leia o tipo dele antes de acreditar na interface. Consulte o seletor no domínio antes de aceitar um padrão. Em todos os casos a checagem é uma consulta, e pular essa checagem produz um sistema que informa sucesso sem entregar nada.
O resumo é que autenticação é uma relação entre uma mensagem e um domínio, e toda falha acima é uma quebra dessa relação, não um erro num registro. É por isso que os registros parecem certos. Eles estão certos. Só não estão ligados àquilo que está sendo conferido, e o único jeito confiável de descobrir isso é resolver o que você publicou e ler o que volta de verdade.