Como configurar registros DKIM, SPF e DMARC para um servidor Zimbra

DKIM, SPF e DMARC resolvem três partes diferentes da autenticação de e-mails de saída, e uma implementação confiável do Zimbra precisa que eles funcionem em conjunto. O SPF informa aos destinatários quais sistemas estão autorizados a enviar e-mails com o domínio do seu envelope. O DKIM adiciona uma assinatura criptográfica vinculada a um domínio. O DMARC verifica se uma identidade SPF ou DKIM aprovada corresponde ao domínio visível no cabeçalho "De" da mensagem e, em seguida, publica uma política de tratamento e relatório.

Um detalhe importante dos padrões atuais é o seguinte: a partir de outubro de 2026, a especificação ativa do protocolo DMARC é a RFC 9989 , publicada em maio de 2026. Ela torna obsoleta a RFC 7489 e altera alguns detalhes de implementação, incluindo a desvalorização da pcttag `old` e a introdução da ttag `testing`. Isso é importante se você estiver copiando um exemplo antigo de DMARC de um guia do Zimbra ou tutorial de DNS anterior.

O que você precisa saber antes de alterar o DNS

Você precisa de acesso administrativo ao shell de um MTA Zimbra, acesso à zona DNS pública autoritativa do seu domínio de envio e uma lista completa de todos os sistemas que enviam e-mails legitimamente usando esse domínio. Essa lista pode incluir seu servidor Zimbra, um servidor de retransmissão ou smart host, plataformas de marketing, sistemas de emissão de tickets, aplicativos em nuvem e qualquer serviço de recuperação de desastres por e-mail.

Um equívoco comum é achar que publicar registros apenas para o host Zimbra é sempre suficiente. Isso só é suficiente quando o Zimbra é realmente o único remetente autorizado. O SPF é avaliado em relação à identidade SMTP, e o DMARC pode expor remetentes terceirizados esquecidos assim que a aplicação da política for ativada. Ação: faça um inventário de todas as fontes de saída antes de publicar uma política SPF ou DMARC restritiva.

Passo 1: Gere a chave DKIM no Zimbra

O Zimbra inclui o zmdkimkeyutilutilitário para assinatura DKIM em nível de domínio. A documentação oficial do Zimbra recomenda executá-lo em um servidor MTA. Para adicionar dados DKIM a um domínio que ainda não os possui, acesse a conta do Zimbra e execute o seguinte comando:

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

O comando armazena os dados DKIM na entrada de domínio LDAP do Zimbra e imprime o seletor e o registro TXT público que você precisa publicar. A documentação de assinatura DKIM do Zimbra também descreve -qcomo consultar dados DKIM existentes, -uatualizá-los e -rremovê-los.

Para instalações modernas do Zimbra, o valor exato do seletor exibido pode diferir dos exemplos encontrados online. O seletor não deve ser uma palavra fixa como `public-key` defaultou ` zimbrapublic-key`; use exatamente o seletor que seu servidor exibe. Ação: copie todo o registro da chave pública da saída do comando em vez de reconstruí-lo manualmente.

Etapa 2: Publicar o registro TXT DKIM

Os verificadores DKIM consultam a chave pública no DNS sob um nome construído a partir do seletor e ._domainkey. O mecanismo é definido na RFC 6376. Em termos práticos de provedores de DNS, o registro geralmente se parece com isto:

Se você deve inserir apenas o nome YOUR_SELECTOR._domainkeycompleto ou apenas o nome da zona, YOUR_SELECTOR._domainkey.example.comisso depende do seu painel de controle de DNS. Alguns provedores adicionam automaticamente o nome da zona. Ação: visualize o nome de registro totalmente qualificado final no seu provedor antes de salvar para não criar um registro inválido acidentalmente ...example.com.example.com.

Etapa 3: Crie um registro SPF TXT para o domínio de envio.

O SPF é publicado como um registro TXT de DNS no domínio cuja autorização de envio você deseja descrever. A RFC 7208 exige registros TXT para SPF e afirma que vários registros SPF com o mesmo nome de proprietário geram um erro permanente. Em outras palavras, não crie um segundo v=spf1registro TXT apenas porque você adicionou outro serviço de e-mail.

Se o seu servidor Zimbra enviar dados diretamente de um endereço IPv4 público estável, um exemplo mínimo seria:

v=spf1 ip4:203.0.113.10 -all

Se todos os hosts referenciados pelos registros MX do seu domínio forem remetentes legítimos de saída, você pode usar o registro padrão mx; se um serviço de terceiros publicar um domínio de inclusão SPF, você pode precisar de um include:mecanismo específico. O registro exato é específico para cada implementação, portanto, não existe uma única string SPF do Zimbra universalmente correta.

Outro erro comum é assumir que `send` ~allé sempre mais seguro que `send` -all. A verdadeira questão é se o seu inventário de remetentes autorizados está completo. Um `send` estrito -allé razoável quando está. Ação: autorize todos os remetentes legítimos em um registro SPF, verifique-o em produção e, em seguida, escolha o allqualificador final com base nessa evidência.

Mantenha o SPF razoavelmente simples. A RFC 7208 limita os mecanismos e modificadores que acionam pesquisas de DNS a 10 durante a avaliação; exceder esse limite pode resultar em problemas permerror. Ação: conte os mecanismos que incluem e outros mecanismos de expansão de DNS antes de adicionar outro fornecedor.

Etapa 4: Publique o DMARC primeiro no modo de monitoramento.

A política DMARC está publicada em _dmarc.example.com. Um primeiro registro cauteloso é:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=noneSolicita aos destinatários que não alterem o tratamento de dados com base na política DMARC enquanto você coleta informações. O ruaendereço solicita relatórios agregados; o formato atual do relatório agregado é especificado pela RFC 9990. Use uma caixa de correio ou um serviço de relatórios capaz de processar relatórios DMARC em vez de uma caixa de entrada pessoal não monitorada.

Não copie cegamente exemplos de implantação de artigos antigos, como o RFC 9989, ou similares. O RFC 9989 é considerado pct=10histórico porque a experiência operacional demonstrou aplicação inconsistente. O padrão atual utiliza o RFC 9989 para testar o comportamento quando necessário. Ação: comece com a análise de relatórios; não confie na amostragem percentual como mecanismo de segurança.pct=25pctt=yp=none

Etapa 5: Verifique todos os três registros no DNS público.

Após o provedor de DNS publicar os registros, consulte-os de fora do servidor autoritativo ou de um resolvedor que tenha acesso ao DNS público. Por exemplo:

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Para SPF, confirme se existe apenas uma resposta TXT começando com v=spf1o nome do proprietário. Para DKIM, confirme se o seletor corresponde exatamente ao valor atualmente armazenado pelo Zimbra. Para DMARC, confirme se existe um único registro de política DMARC utilizável com o nome esperado.

A propagação do DNS depende do seu provedor, do TTL e do cache do resolvedor. Uma alteração que aparece imediatamente em um servidor de nomes autoritativo pode ainda estar em cache em outro lugar. Ação: teste com pelo menos um resolvedor público independente antes de culpar o Zimbra por uma resposta desatualizada.

Etapa 6: Envie uma mensagem real e verifique o alinhamento da autenticação.

Envie uma mensagem do domínio Zimbra para uma caixa de correio em um provedor diferente e inspecione os cabeçalhos completos da mensagem. Um resultado bem-sucedido normalmente deve mostrar uma assinatura DKIM e/ou resultado SPF aprovados, além de aprovação no DMARC, pois pelo menos uma identidade autenticada corresponde ao domínio "De" visível.

É aqui que outra ideia equivocada se torna visível: o DMARC não exige que ambos, SPF e DKIM, sejam aprovados. Ele exige uma identidade SPF alinhada ou uma identidade DKIM alinhada. A RFC 9989 define o alinhamento flexível como padrão para ambos aspf, adkimembora seja possível solicitar um alinhamento estrito com o DMARC s. Ação: inspecione Authentication-Resultse identifique exatamente qual mecanismo está fornecendo a aprovação do DMARC alinhado.

Etapa 7: Passe da monitorização para a aplicação da lei somente após os relatórios estarem sem ressalvas.

Assim que seus dados DMARC mostrarem que os remetentes legítimos se autenticam e se alinham corretamente, você poderá alterar a política para `authentication` p=quarantineou, eventualmente, para ` unauthentication` p=reject. No padrão atual, `authentication` none, quarantine`unauthentication` e `unauthentication` rejectexpressam a avaliação do proprietário do domínio sobre o uso não autenticado, mas os destinatários ainda mantêm a discricionariedade local no tratamento de dados.

Não trate p=rejecto DMARC como uma otimização de entregabilidade. O DMARC é, primordialmente, um mecanismo de autenticação e controle de abuso de domínio; ele não torna automaticamente os e-mails desejados confiáveis ​​nem garante sua entrega na caixa de entrada. Ação: faça da aplicação do DMARC uma decisão de segurança baseada na cobertura de autenticação adequada, e não na promessa de taxas de entrega mais altas.

Etapa 8: Rotacione as chaves DKIM sem excluir imediatamente o registro DNS antigo.

Para atualizar os dados DKIM de um domínio, o Zimbra utiliza os seguintes documentos:

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

O comando cria dados DKIM atualizados e gera uma nova entrada DNS. A Zimbra recomenda especificamente manter o registro TXT anterior no DNS por um período de tempo para que as mensagens assinadas com a chave anterior ainda possam ser verificadas durante a transmissão ou em fila de espera. Ação: publique o novo seletor primeiro, verifique-o e mantenha o seletor anterior temporariamente antes de removê-lo.

Referência rápida: o que cada registro comprova

Verificações específicas do Zimbra que vale a pena fazer

As diretrizes de proteção de e-mail do Zimbra observam que o DKIM deve ser gerado por domínio e publicado no DNS público de cada domínio. Elas também documentam problemas de alinhamento que podem surgir com determinadas personas ou comportamentos de resposta automática em configurações mais antigas. Esses detalhes são situacionais, e não universais: se sua implementação usa aliases, personas, relays ou reescrita incomum de envelopes, teste esses caminhos de mensagem separadamente.

Para uma instalação do Zimbra com múltiplos domínios, repita a configuração do DKIM e a publicação do DNS para cada domínio de envio. SPF e DMARC também são políticas de domínio; não assuma que um registro em um domínio hospedado cubra automaticamente outro domínio não relacionado. Ação: crie uma pequena matriz de testes para cada domínio e cada rota de saída antes de habilitar a aplicação rigorosa do DMARC.

Lista de verificação de validação final

• Existe exatamente um registro SPF começando com v=spf1em cada domínio de envio.
• O registro SPF inclui todas as rotas de saída autorizadas e permanece dentro dos limites de processamento de DNS do SPF.
• O Zimbra está assinando e-mails de saída com o seletor armazenado para esse domínio.
• A chave pública DKIM correspondente está visível no DNS público em selector._domainkey.
• O registro DMARC TXT é publicado em _dmarc.domaine utiliza a sintaxe atual.
• As mensagens de teste externas mostram uma aprovação SPF ou DKIM alinhada e, portanto, uma aprovação DMARC.
• Os relatórios agregados são analisados ​​antes de passarem da fase de monitoramento para a quarentena ou rejeição.
• Os seletores DKIM antigos são mantidos temporariamente durante a rotação e removidos somente após o período de transição.

Se essas verificações forem aprovadas, seu servidor Zimbra não estará apenas publicando três registros DNS; ele estará apresentando uma cadeia de autenticação coerente que os destinatários remotos podem validar. Essa distinção é mais importante do que copiar qualquer exemplo de string de um guia, porque as fontes SPF corretas, o seletor DKIM e o momento de aplicação do DMARC dependem de como seus e-mails realmente saem da organização.