Comece com a autoridade e a pergunta
Uma biblioteca de autenticação de e-mail deve ajudar o leitor a selecionar o documento primário correto, e não apenas coletar links. Regras de protocolo, registros de parâmetros, requisitos de fornecedores e observações de produtos respondem a diferentes questões. Este guia com curadoria registra o escopo e o status das principais fontes revisadas em 8 de novembro de 2026. Suas entradas têm âncoras de leitura estáveis; eles não estabelecem que um locatário, receptor ou implementação EmailAuth esteja em conformidade com essas fontes.
Para cada requisito operacional, guarde a autoridade emissora, o identificador do documento, a versão ou data de revisão, a população afetada, o proprietário responsável e as evidências de aceitação. Uma data de publicação não é automaticamente uma data de aplicação do fornecedor. Uma biblioteca funcional também precisa de manutenção: links alterados, novas atualizações e conflitos de fontes não resolvidos devem estar visíveis, em vez de escondidos atrás de um emblema antigo revisado.
Núcleo DMARC RFC 9989
RFC 9989 é o núcleo de maio de 2026 DMARC especificação, abrangendo identificadores autenticados, alinhamento, descoberta de políticas e semântica de políticas de avaliação. Isso é Registro de informações do Editor RFC identifica-o como Norma Proposta; o documento é Standards Track e obsoleta as RFCs 7489 e 9091. Use-o para as regras básicas atuais, enquanto testa separadamente as diferenças de implementação legadas. A versão da política permanece DMARC1 , não uma versão inventada a partir do novo número RFC.
Relatórios agregados RFC 9990
RFC 9990 é a especificação separada de relatórios agregados de maio de 2026. O Registro do Editor RFC identifica o status da Norma Proposta. Ele aborda a estrutura do relatório, processamento, destinos externos, duplicatas e considerações de privacidade/segurança. Deve apoiar os casos de aceitação de um analisador de relatório e não ser tratado como evidência de que cada receptor envia relatórios completos ou de que os totais de um painel estão corretos.
Relatório de falhas RFC 9991
RFC 9991 é a especificação de relatório de falhas do Standards Track de maio de 2026, atualiza RFC 6591 e participa com os outros dois documentos na substituição RFC 7489. Seu foco são diagnósticos específicos de mensagens, formato de relatório, destinos externos e privacidade. A leitura da página de informações separada teve taxa limitada durante esta revisão; o texto RFC lido com sucesso suporta a categoria declarada. Não confunda relatórios de falhas com estatísticas agregadas ou presumir que a publicação do ruf garante relatórios.
SPF RFC 7208
RFC 7208, publicado em abril de 2014 no Standards Track, define SPF identidades, seleção de registros de políticas, avaliação e tratamento de resultados. É o principal ponto de partida para explicar uma permerror ou o limite de prazo de consulta de DNS. Leia a seção relevante e suas dependências em vez de reduzir SPF a uma lista de endereços IP permitidos ou assumir que cada operação DNS conta de forma idêntica.
DKIM RFC 6376 e atualizações de algoritmo
RFC 6376, publicado em setembro de 2011 no Standards Track, define DKIM assinaturas, seletores, chaves e verificação. Leia suas disposições criptográficas com RFC 8301, janeiro de 2018, e RFC 8463, setembro de 2018. O primeiro proíbe o RSA-SHA1 e fortalece os principais requisitos do RSA; este último define Ed25519 usar. Um documento base mais antigo permanece útil sem tornar atuais todas as recomendações originais do algoritmo.
DNS SMTP e nenhum email explícito
RFC 5321, outubro de 2008, fornece transporte SMTP e regras de resolução de alvo. RFC 1034 e RFC 1035, novembro de 1987, fornecem conceitos básicos DNS e estrutura de registros. Usar RFC 2308, março de 1998, para distinções de respostas negativas, em vez de um atalho obsoleto de cache negativo. Essas referências são pontos de partida para atualizações posteriores, e não uma especificação completa e moderna de implementação DNS .
RFC 7505, junho de 2015, define MX nulo para um domínio que não aceita explicitamente nenhum email. A orientação do remetente alerta contra o uso de um domínio MX nulo para CORREIO DE ou visível De identidades: os receptores podem recusar esse tráfego. Mantenha a orientação do remetente distinta do SPF e do caminho reverso nulo do SMTP . Um registro deliberado sem e-mail não é um MX ausente ou com defeito.
Procedência do resultado da autenticação RFC 8601
RFC 8601, maio de 2019, define o Cabeçalho Authentication-Results e suas considerações de confiança. Use-o ao avaliar quem fez uma afirmação de autenticação e se essa afirmação pertence ao limite confiável do sistema receptor. Ele não transforma um cabeçalho arbitrário copiado de uma mensagem em evidência autenticada, nem estabelece a colocação de um token de passagem na caixa de entrada.
Registros de parâmetros IANA
O Registro de parâmetros DMARC, atualizado em 22 de maio de 2026 no registro recuperado, conecta tags a referências e status ativo ou histórico. Ele marca histórico de pct, rf e ri e inclui tags ativas como np, psd e t. O Registro de parâmetros DKIM identifica tags de assinatura registradas e definições associadas. O registro é uma referência de vocabulário e não uma prova de que uma implantação dá suporte a um parâmetro corretamente.
Status e implementação são evidências separadas
Um Internet-Draft é um documento de trabalho, não uma RFC publicada apenas porque se assemelha a uma. Seção 2.2 RFC 2026 explica essa distinção; atualizações posteriores do processo significam que sua escada histórica de padrões não deve ser tratada como o processo atual completo. Distinga também o Standards Track dos documentos informativos, experimentais e de melhores práticas atuais. Cite o registro de status real em vez de assumir que cada RFC numerada tem a mesma autoridade.
Para uma regra de provedor, registre o produto, a rota, o ambiente de nuvem, os remetentes afetados, o anúncio e as datas de aplicação separadamente. Um conflito entre páginas oficiais pertence ao registro de requisitos até que uma fonte atual aplicável ou observação controlada o resolva. Um resultado de analisador sintético pode testar a interpretação local, mas não pode provar a adoção remota.
O requisito exato do catálogo permanece aberto: um registro de requisitos com autoridade, escopo, data de vigência, proprietário e evidência de aceitação. O mapa selecionado abaixo fornece entradas de origem e propriedade proposta, não a aceitação específica da organização concluída. A entrada também pede funcionalidade de trabalho e testes. Âncoras estáticas e links primários são fornecidos, mas a aceitação da ferramenta funcional, a aplicabilidade, a revisão técnica e a aprovação da publicação permanecem pendentes.