Explicação de SPF, DKIM, DMARC e MX

Quatro famílias de registos DNS transportam grande parte da política operacional de um domínio de e-mail personalizado. O MX encaminha o e-mail recebido. O SPF autoriza a infraestrutura de envio. O DKIM associa às mensagens uma assinatura de domínio verificável. O DMARC verifica se o SPF ou o DKIM está alinhado com o domínio visível para o destinatário e publica uma política de aplicação.

Funcionam em conjunto, mas cada um resolve um problema diferente. Um administrador de domínios deve compreender esses limites antes de ligar um fornecedor ou migrar o e-mail.

O serviço de e-mail privado com domínio personalizado da Thelemail gera e verifica os registos necessários. Este guia explica o significado dos registos para que possa analisar com confiança a configuração resultante.

O MX seleciona os servidores de e-mail recebido

Um registo MX indica que anfitrião aceita e-mail para um domínio. Cada registo tem um valor de preferência e um nome de anfitrião de destino. Os números de preferência mais baixos são tentados primeiro. Vários registos com a mesma preferência podem distribuir tentativas entre servidores equivalentes, enquanto os registos com números mais altos fornecem normalmente percursos alternativos de entrega.

O destino é um nome de anfitrião que é resolvido num endereço. Introduza os valores exatamente como o fornecedor de e-mail os fornece. Os painéis de DNS tratam o nome da zona e o ponto final de formas diferentes, pelo que deve considerar o resultado publicado como a autoridade final.

O MX afeta o encaminhamento recebido. Nada diz sobre os sistemas que podem enviar em nome do domínio. Essa autorização provém do SPF e do DKIM, sendo o alinhamento das identidades avaliado pelo DMARC.

Durante uma migração de fornecedor, prepare o novo serviço antes de substituir o MX. Crie primeiro todas as caixas de correio, aliases e endereços partilhados. O guia de transição faseada do MX abrange o planeamento do TTL, a monitorização da sobreposição e a reversão.

O SPF autoriza o remetente do envelope

O Sender Policy Framework, ou SPF, publica uma política TXT que identifica os sistemas autorizados a enviar utilizando um domínio no envelope SMTP. Os servidores recetores comparam o IP que estabelece a ligação com os mecanismos dessa política.

A identidade do envelope é frequentemente designada por caminho de retorno ou endereço MAIL FROM. Recebe as mensagens devolvidas e pode ser diferente do endereço From visível num cliente de e-mail. Por conseguinte, uma aprovação SPF isolada pode utilizar um domínio não relacionado com o remetente visível.

Uma política SPF pode autorizar intervalos de IP diretos e políticas mantidas pelo fornecedor. Os mecanismos comuns incluem ip4, ip6, a, mx e include. O qualificador final abrange as origens sem correspondência. O seu fornecedor deve indicar os elementos de política necessários.

Mantenha uma política SPF por domínio

Um domínio deve publicar um registo SPF que comece por v=spf1. Vários registos SPF separados geram um erro permanente de avaliação. Quando uma plataforma de sites, um sistema de faturação e um fornecedor de caixas de correio enviam e-mail para o domínio, combine os respetivos mecanismos autorizados numa única política.

A avaliação SPF permite, no máximo, dez mecanismos e modificadores que consultem o DNS. As políticas include aninhadas contam para esse limite. Ultrapassá-lo gera um erro permanente. Remova os remetentes desativados e considere subdomínios específicos para diferentes finalidades de e-mail.

O reencaminhamento pode afetar o SPF porque o servidor de reencaminhamento estabelece a ligação a partir de um novo IP, mantendo um domínio de envelope anterior. O Sender Rewriting Scheme pode fornecer uma nova identidade de envelope autorizada. O DKIM pode sobreviver ao reencaminhamento quando o conteúdo assinado permanece intacto.

O DKIM assina a mensagem com uma chave do domínio

O DomainKeys Identified Mail, ou DKIM, atribui a um sistema de envio uma chave privada de assinatura. O respetivo cabeçalho DKIM-Signature contém o domínio de assinatura, o seletor, os cabeçalhos assinados e um hash do corpo. O destinatário obtém a chave pública através do DNS e verifica a assinatura.

O nome DNS combina o seletor com _domainkey e o domínio de assinatura. Um fornecedor disponibiliza o registo da chave pública ou um CNAME que aponta para o mesmo. Podem coexistir vários seletores para a rotação de chaves e vários serviços de envio.

Uma verificação DKIM bem-sucedida mostra que o conteúdo assinado sobreviveu ao trânsito e que um detentor da chave privada criou a assinatura. Depois, o DMARC verifica o alinhamento entre o domínio de assinatura e o domínio From visível.

As listas de distribuição, gateways e produtos de segurança podem alterar o conteúdo assinado e invalidar uma assinatura DKIM. Inspecione o cabeçalho Authentication-Results e o percurso da mensagem antes de alterar a chave DNS.

Rode os seletores de forma deliberada

Para uma rotação DKIM segura, publique a nova chave, assine com o novo seletor, verifique os resultados e mantenha a antiga chave pública durante o período de transição. Restrinja as chaves privadas aos sistemas de envio autorizados.

O DMARC liga a autenticação ao domínio From visível

O Domain-based Message Authentication, Reporting and Conformance, ou DMARC, é publicado em _dmarc sob o domínio. Avalia o domínio no cabeçalho From visível em relação aos resultados SPF e DKIM.

O DMARC é aprovado quando, pelo menos, um destes percursos tem êxito:

• O SPF é aprovado e o respetivo domínio de envelope autenticado está alinhado com o domínio From visível.
• O DKIM é aprovado e o respetivo domínio de assinatura está alinhado com o domínio From visível.

O alinhamento flexível permite subdomínios relacionados ao nível da organização, enquanto o alinhamento estrito exige uma correspondência exata do domínio. O alinhamento flexível é o predefinido. A política também descreve o tratamento solicitado das falhas.

Os principais modos de política são:

• p=none solicita monitorização enquanto são recolhidos relatórios.
• p=quarantine pede aos destinatários que tratem o e-mail com falhas como suspeito.
• p=reject pede aos destinatários que rejeitem o e-mail com falhas.

Os destinatários mantêm o controlo final sobre o tratamento local, pelo que a política é um pedido publicado. Os relatórios agregados enviados para destinos rua resumem os resultados por origem e expõem problemas de alinhamento antes de uma aplicação mais rigorosa.

Passe da monitorização para a aplicação depois de contabilizar todos os remetentes legítimos. Uma ferramenta de faturação ou formulário de site esquecido pode perder capacidade de entrega sob uma política estrita, mesmo quando o e-mail do fornecedor de caixas de correio está configurado corretamente.

A autenticação e a cifragem protegem coisas diferentes

O SPF, o DKIM e o DMARC ajudam os sistemas recetores a avaliar a identidade do domínio e a falsificação, enquanto o MX encaminha o e-mail recebido. A cifragem do conteúdo exige controlos noutros pontos do percurso da mensagem.

O TLS protege o tráfego SMTP entre servidores compatíveis. A cifragem ponto a ponto protege o conteúdo legível ao longo de todo o percurso quando ambos os lados utilizam chaves compatíveis. A cifragem do armazenamento protege os dados das caixas de correio detidos pelo serviço.

A Thelemail fornece cifragem sem acesso ao conteúdo armazenado das caixas de correio e cifragem ponto a ponto entre contas Thelemail. Para e-mail externo, o cliente Web utiliza WKD/OpenPGP quando está disponível uma chave de destinatário compatível, e a Thelemail publica as chaves dos utilizadores através de WKD para permitir e-mail recebido com cifragem compatível. As outras entregas externas utilizam SMTP normal com TLS quando suportado. Os cabeçalhos de assunto externos e os metadados do envelope permanecem visíveis para o encaminhamento. O modelo de segurança e de ameaças descreve estas garantias com precisão.

Utilize uma ordem de configuração faseada

Uma nova configuração de domínio personalizado é mais fácil de analisar nesta sequência:

1. Confirmar a propriedade do domínio com o registo TXT do fornecedor.
2. Publicar o DKIM do novo serviço de envio.
3. Criar uma política SPF que abranja todos os remetentes legítimos.
4. Publicar o DMARC com relatórios e uma política inicial adequada.
5. Criar todas as caixas de correio, aliases e endereços partilhados.
6. Testar a autenticação de saída de cada serviço de envio.
7. Alterar o MX depois de todos os destinatários de entrada estarem prontos.
8. Analisar os relatórios e avançar a aplicação do DMARC de acordo com as provas.

Esta é a ordem utilizada no guia de configuração do domínio da Thelemail. Os planos e capacidades atuais determinam os limites das caixas de correio, do armazenamento e dos domínios. Os planos pagos incluem aliases ilimitados, sujeitos a uma salvaguarda contra abusos por espaço de trabalho; os aliases não estão incluídos no plano Free.

Uma pessoa pode utilizar um endereço @temail.org sem administrar o DNS. Um agregado familiar ou uma equipa liderada pelos fundadores obtém a portabilidade dos endereços com domínio personalizado quando um administrador técnico assume este processo de configuração.

Diagnostique falhas a partir do cabeçalho da mensagem

Comece pelo cabeçalho Authentication-Results do sistema recetor. Normalmente, regista os resultados SPF, DKIM e DMARC, juntamente com os domínios avaliados.

O SPF é aprovado, mas o DMARC falha

Compare o domínio do envelope autenticado com o domínio From visível. Configure um caminho de retorno alinhado ou utilize uma assinatura DKIM alinhada.

O DKIM comunica uma chave em falta

Consulte o seletor e o domínio de assinatura no cabeçalho DKIM-Signature. Verifique os campos de anfitrião copiados, a configuração expirada do fornecedor e a remoção prematura da chave.

A verificação DKIM falha com uma chave publicada

Confirme a chave DNS atual e verifique se um serviço de reencaminhamento, lista de distribuição ou gateway alterou o conteúdo assinado. Teste um percurso direto para isolar a alteração.

O SPF devolve um erro permanente

Verifique se existem vários registos SPF, problemas de sintaxe, inclusões recursivas e mais de dez termos que consultem o DNS. Desative os serviços não utilizados ou separe os fluxos de e-mail.

Alguns remetentes ainda chegam ao antigo fornecedor

Consulte o DNS autoritativo e inspecione o TTL do MX. Mantenha ambos os fornecedores disponíveis durante a sobreposição planeada e reconcilie as mensagens do serviço antigo.

Mantenha os registos após o lançamento

O DNS de e-mail precisa de uma análise periódica. Remova a autorização de plataformas desativadas, rode os seletores DKIM, leia os relatórios agregados DMARC e verifique o MX após alterações ao fornecedor de DNS. Adicione cada novo serviço de envio ao inventário antes de este enviar e-mail em produção.

Utilize os painéis dos fornecedores como um sinal e consultas DNS independentes como outro. As mensagens de teste para sistemas externos revelam os resultados de autenticação que os destinatários realmente veem. Mantenha os percursos de recuperação do agente de registo do domínio, do fornecedor de DNS e do serviço de e-mail documentados fora da caixa de correio que protegem.

Para domínios familiares, o guia de configuração de e-mail familiar transforma estes registos num plano completo para o agregado familiar. Os administradores de homelabs podem utilizar a avaliação do alojamento próprio para analisar a rede, a reputação e o trabalho operacional subjacentes ao DNS.

Quando as quatro famílias de registos são compreendidas separadamente, a resolução de problemas torna-se muito mais direta: o MX responde para onde vai o e-mail recebido, o SPF responde que infraestrutura pode enviar, o DKIM comprova uma assinatura de domínio e o DMARC verifica o alinhamento com a identidade que o destinatário vê.