Como configurar corretamente SPF, DKIM e DMARC no Plesk

Neste guia, mostrar-lhe-ei passo a passo como SPF DKIM e DMARC no Plesk para que os seus e-mails sejam autenticados de forma fiável. Receberá procedimentos claros para entradas DNS, comutadores Plesk e métodos de teste com os quais pode aumentar a capacidade de entrega e bloquear remetentes abusivos.

Pontos centrais

• SPF determina quais os sistemas que estão autorizados a enviar mensagens de correio eletrónico para o seu domínio.
• DKIM assina as mensagens enviadas e protege-as contra manipulações.
• DMARC liga o SPF/DKIM a diretrizes e relatórios.
• Plesk fornece assistentes e modelos de DNS para um início rápido.
• Monitorização dos relatórios DMARC aperfeiçoa a sua política em funcionamento.

Verificar pré-requisitos no Plesk

Antes de efetuar quaisquer definições, verifico o servidor de correio utilizado em Plesk e gestão de DNS. No Linux, trabalho normalmente com o Postfix, no Windows com o SmarterMail, uma vez que estes serviços fornecem funções SPF, DKIM e DMARC. Também verifico se o domínio tem as suas zonas DNS no DNS do Plesk ou num fornecedor externo, porque assim posso gerir as entradas fora do Plesk deve ser adicionado. Para um bom funcionamento, mantenho o nome do anfitrião, o DNS inverso e os certificados TLS válidos limpos, uma vez que os servidores de entrega verificam estes pontos. Um ponto de partida limpo poupa muito tempo mais tarde e reforça a Reputação.

Configurar o SPF no Plesk - passo a passo

Para começar, abro "Ferramentas e definições" → "Definições de DNS" e procuro um registo TXT que comece por v=spf1 começa. Se faltar, coloco-o, por exemplo: v=spf1 a mx include:yourmailprovider.de -allpara que os sistemas autorizados possam enviar e todos os outros sejam bloqueados. Se o domínio utilizar remetentes adicionais, como o Microsoft 365, o Google Workspace ou serviços de boletins informativos, adiciono os incluir-da sua documentação. Depois de guardar, aguardo até 48 horas para que a alteração entre em vigor globalmente e testo o registo com um verificador SPF através de um e-mail de teste para uma caixa de correio selecionada. Pode encontrar uma classificação compacta da interação dos mecanismos no guia compactoque explica os cenários mais importantes.

Ativar o DKIM no Plesk - é assim que se procede

Para DKIM Vou a "Ferramentas e definições" → "Definições do servidor de correio" e ativo a opção de assinar as mensagens de correio eletrónico enviadas. Em seguida, abro "Websites & Domains" ao nível do domínio → Domínio → "Mail" → "Definições" e verifico se a assinatura está activada para cada domínio. Se gerir o DNS externamente, exporto os dados de Plesk gerou chaves públicas DKIM e introduzi-las como registos TXT no fornecedor de DNS (ter em atenção o nome do seletor). Após um máximo de 24-48 horas, os destinatários devem validar as assinaturas DKIM, o que eu confirmo enviando um correio de teste para uma caixa de correio de verificação DKIM ou uma verificação de cabeçalho. Uma assinatura válida reforça a Capacidade de entrega percetível.

Definir a política DMARC e utilizar relatórios

Agora, defino DMARC como registo TXT em _dmarc.yourdomain.tld com o valor v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. As etiquetas p, rua e chamada política de controlo e apresentação de relatórios, enquanto adkim/aspf definir o alinhamento estrito (strict). Na prática, costumo começar com p=nenhumavaliar os relatórios durante duas a quatro semanas e, em seguida, elaborar quarentena ou rejeitar sobre. Os relatórios mostram quais os sistemas que enviam e-mails em seu nome e onde o SPF ou o DKIM falham, o que permite fazer correcções diretas. Uma sequência de passos mais pormenorizada descreve a Implementação do DMARC com exemplos concretos.

Propagação de DNS, testes e melhores práticas

Todas as alterações de DNS demoram tempo, pelo que planeio até 48 horas para alterações globais de DNS. Propagação em. Nesta fase, envio mensagens de correio eletrónico de teste para caixas de correio externas e verifico os resultados da autenticação no cabeçalho para spf=pass, dkim=pass e dmarc=pass. Se um correio receber um falha suave ou NeutroVerifico os mecanismos SPF, os selectores DKIM e o envelope-from (caminho de retorno) para verificar o alinhamento com From:. Quando utilizo redireccionamentos, monitorizo os resultados do DMARC, uma vez que o SPF falha frequentemente neste caso; o DKIM normalmente compensa isso. Evito ~Tudo permanentemente e para configurações produtivas confiam consistentemente em -tudo.

Etiquetas e valores DMARC - tabela compacta

Utilizo a seguinte síntese para DMARC de forma rápida e fiável e para evitar interpretações erradas. Mantenho os valores consistentes nos domínios principais e subdomínios e documento as alterações de forma rastreável. Para os domínios produtivos, defino um alinhamento rigoroso e ativo sempre os relatórios agregados. Relatórios forenses (chamada) Planeio em conformidade com os regulamentos de proteção de dados. A definição de diretrizes claras estabiliza o Reputação do domínio.

Dia	Significado	Valores possíveis	Recomendação
p	Política para o domínio principal	nenhum, quarentena, rejeitar	Comece com nenhum, depois aumente para rejeitar
esp	Política para subdomínios	nenhum, quarentena, rejeitar	sp=rejeitar para configurações produtivas
rua	Relatórios agregados	mailto:adresse	Utilizar o seu próprio endereço de comunicação
chamada	Relatórios forenses	mailto:adresse	Ativar apenas se necessário
adkim	Alinhamento DKIM	r (relaxado), s (rigoroso)	adkim=s para uma atribuição clara
aspf	Alinhamento do SPF	r (relaxado), s (rigoroso)	aspf=s para menos alarmes falsos
pct	Percentagem de aplicação	0-100	Aperto passo a passo com pct

Integrar remetentes externos: Microsoft 365, Google, serviços de boletim informativo

Se um domínio utilizar caminhos de envio adicionais, adiciono os SPF includes para Microsoft 365, Google Workspace, Mailgun, SendGrid ou ferramentas de boletim informativo exatamente como documentado. Para cada serviço, verifico se está ativa uma chave DKIM separada e se o domínio de origem está realmente assinado. Evito duplicados ou demasiados incluir-cascatas, uma vez que o SPF está limitado a dez pesquisas no DNS. Se o orçamento para pesquisas não for suficiente, consolido os remetentes ou transfiro fluxos individuais para subdomínios com a sua própria política DMARC. É assim que mantenho o SPF enxuto e seguro o Assinaturas de.

Controlos aprofundados e seleção de servidores

Para as mensagens de correio recebidas, ativo em Plesk verificar SPF, DKIM e DMARC para que o servidor filtre o spam numa fase inicial. No Linux, estas verificações estão disponíveis por defeito, enquanto no Windows são implementadas com o SmarterMail. Certifico-me de que o servidor de correio eletrónico está devidamente atualizado para que as rotinas de assinatura e os analisadores se mantenham actualizados. Se houver problemas com falsos positivos, ajusto os limites de pontuação, mas nunca o Política do seu próprio domínio. É assim que mantenho a proteção elevada e asseguro a entrega de remetentes legítimos.

Erros comuns e soluções rápidas

Encontros "SPF permerror", normalmente há um erro de sintaxe ou o limite de pesquisa foi excedido. Se o DKIM falhar, verifico o seletor, o registo da chave pública e a terminação do valor TXT com aspas corretas. Se o DMARC falhar falharEm primeiro lugar, verifico o alinhamento: From-Domain, Return-Path e DKIM-d= devem corresponder perfeitamente. Se o SPF falhar com os redireccionamentos, confio no DKIM e manter o estado da assinatura estável. Utilizo esta sequência para resolver a maioria dos problemas de entrega sem ter de efetuar uma longa pesquisa.

Modelos e automação de DNS no Plesk

Se eu gerir muitos domínios, defino a opção Modelo de DNS no Plesk e armazenar aí registos padrão para SPF, DKIM e DMARC. Os novos domínios recebem imediatamente predefinições sólidas que só preciso de afinar. Também implemento alterações planeadas, como DMARC mais rigoroso em todo o domínio, utilizando modelos e scripts. Para rotações das chaves DKIM, trabalho com dois selectores para poder fazer alterações graduais. Isto mantém a operação consistente em dezenas de domínios e sustentável.

Avaliar relatórios DMARC e reforçar a política

Após o arranque, analiso diariamente os relatórios agregados e identifico Fontesque enviam em nome do domínio sem autorização. Bloqueio IPs inesperados e limpo ferramentas desactualizadas antes de reforçar a política. A mudança de p=nenhum em quarentena e mais tarde rejeitar Eu realizo com pct em fases, para que possa medir os efeitos de forma controlada. Se aparecerem remetentes legítimos no relatório falhado, corrijo os SPF includes ou ativo a minha própria chave DKIM. Esta rotina reforça a Reputação visível e reduz a falsificação.

Compreender corretamente o alinhamento

Portanto, isso DMARC Asseguro sempre um alinhamento correto. Com SPF é o domínio no envelope de (caminho de retorno) ou a identidade HELO/EHLO, que deve corresponder ao domínio visível de (estrito: idêntico, relaxado: mesmo domínio de organização). Com DKIM Verifico o d=-Atributo da assinatura: Deve apontar para o mesmo domínio (estrito) ou para o mesmo domínio organizacional (flexível). Na prática, certifico-me de que:

• o caminho de rejeição utilizado (caminho de retorno) utiliza um domínio que corresponde ao domínio de origem ou é deliberadamente externalizado para um subdomínio com a sua própria política DMARC,
• todos os fornecedores terceiros o domínio De sinal (DKIM), e não apenas o seu próprio domínio de envio,
• a assinatura DKIM permanece intacta durante o reencaminhamento para compensar as quebras de SPF.

Se o alinhamento estiver em falta, os receptores DMARC comunicam um erro apesar de um SPF/DKIM válido. dmarc=fail. É por isso que verifico os campos nos cabeçalhos das mensagens de correio eletrónico Resultados da autenticação, Caminho de regresso e os parâmetros DKIM. Isto permite-me reconhecer rapidamente se o SPF ou o DKIM estão a fornecer o alinhamento e onde preciso de fazer melhorias.

Gestão de chaves e parâmetros DNS

Para uma robustez DKIM-utilizei chaves de 2048 bits. Em Plesk Posso definir o comprimento da chave por domínio; utilizo prontamente chaves antigas de 1024 bits. Se necessário, divido registos TXT DKIM longos em vários segmentos de vírgula invertida para que o servidor DNS os entregue corretamente. Também defino registos TTL-valores: Nas fases de lançamento, utilizo 300-900 segundos; em termos produtivos, utilizo 1-4 horas. Isto permite-me reagir de forma flexível às alterações sem sobrecarregar as caches.

O Rotação Faço-o sem falhas com dois selectores:

1. Crie um novo seletor no Plesk e publique a chave pública como TXT no DNS.
2. Alterar o remetente para o novo seletor e observar a monitorização (mostrar cabeçalhos) s=novo seletor).
3. Depois de todos os fluxos terem sido convertidos, remova o seletor antigo no DNS e desactive-o no Plesk.

Utilizo fornecedores terceiros sempre que possível, delegada Registos DKIM (por exemplo, CNAME para o seletor de fornecedor). Isto permite-me manter o controlo na minha zona e rodar as chaves sem correr o risco de quebras operacionais.

Casos especiais: Reencaminhamento, listas de correio eletrónico e gateways

Em ambientes reais, vejo regularmente redireccionamentos, listas de correio ou gateways de segurança que reescrevem mensagens de correio eletrónico. Presto especial atenção aos efeitos neste domínio:

• ReencaminhamentoO SPF falha frequentemente porque o IP de reencaminhamento não está no SPF do domínio remetente. Neste caso, confio em DKIMque fornece a proteção do conteúdo. Se a assinatura permanecer inalterada, o DMARC existe através do alinhamento DKIM.
• Listas de correio eletrónicoMuitas listas mudam de assunto ou de rodapé, quebrando assim a assinatura DKIM. Nesses casos, planeio um alinhamento descontraído e verifico se a lista utiliza SRS/ARC ou as suas próprias assinaturas. Se possível, utilizo um subdomínio com a sua própria política DMARC para as listas.
• Gateways de segurançaOs gateways que reescrevem mensagens ou reescrevem o envelope-from devem estar corretamente alinhados com o domínio do remetente. Eu documento o seu papel e ancoro-o no SPF (ip4/ip6) ou via include para que o alinhamento seja mantido.

Encontrar mensagens de correio eletrónico com spf=fail através de um reencaminhamento, isto não é automaticamente crítico, desde que dkim=pass está presente e o alinhamento DKIM está correto. Avalio a totalidade dos resultados de autenticação em vez de sinais individuais isolados.

IPs partilhados, HELO/EHLO e rDNS

Se vários domínios partilharem o mesmo IP de saída, confio em rDNS e nomes HELO/EHLO consistentes. O ponteiro inverso aponta para um FQDN (por exemplo mail.hosting-example.tld), cujo registo A aponta para o mesmo IP. O MTA reporta exatamente com este nome. Certifico-me de que o Certificado SMTP TLS corresponde ao nome HELO (SNI se forem fornecidos vários nomes). Para cada domínio remetente, asseguro também que o SPF/DKIM/DMARC estão completa e corretamente alinhados - o IP partilhado, por si só, não afecta o DMARC, desde que a autenticação seja eficaz.

Para remetentes dedicados (por exemplo, correio transacional vs. marketing), gosto de os separar através de subdomínios e, opcionalmente, dos seus próprios IPs. Isto ajuda com Gestão da reputaçãosimplifica a avaliação dos relatórios DMARC e minimiza a interferência mútua.

Acompanhamento e implementação na prática

Para garantir o bom funcionamento, combino a Análise DMARC com etapas claras de implementação:

• Linha de base: 2-4 semanas p=nenhumrecolher todos os relatórios agregados (rua), identificar as fontes de erro.
• LimpezaRemova os remetentes não autorizados, limpe os SPF includes, active o DKIM em todos os sistemas legítimos.
• VestirCom pct gradualmente para quarentena, mais tarde rejeitar aumento, medir os efeitos em percentagem.
• AlertaDefina valores limite (novos IPs, taxa de falha por fornecedor, novos domínios) e configure notificações.
• DocumentaçãoMantenha os selectores, TTL, tempos de execução chave, orçamento SPF e responsabilidades sob controlo de versão.

Verifico o Orçamento de pesquisa SPF (máx. 10 mecanismos com consultas DNS) e consolidar inclui. Mecanismos críticos como ptr ou +tudo Geralmente não os utilizo; ip4/ip6, a, mx e direcionados incluir continuam a ser o meio de eleição. É assim que mantenho a configuração estável e auditável.

Verificação rápida para cada domínio

No final de cada instalação, executo um Verificar através de: Registo SPF disponível, orçamento de pesquisa inferior a dez, mecanismos corretamente ordenados, -tudo Ativo. Assinatura DKIM válida, seletor documentado, comprimento de chave suficiente, rotação planeada. DMARC com registo TXT válido, alinhamento rigoroso, caixas de correio de comunicação acessíveis e arquivadas. Mostrar mensagens de teste spf=pass, dkim=pass e dmarc=pass no cabeçalho. Utilizo esta sequência para manter as configurações reprodutíveis e Erro baixo.

Resumo prático para um sucesso rápido

Começo cada projeto com NormasManter o SPF reduzido, ativar o DKIM para cada remetente e implementar o DMARC com relatórios. Seguem-se duas a quatro semanas de monitorização para eliminar pontos cegos e reforçar as diretrizes. Integro serviços externos de forma controlada, documento as inclusões e mantenho o orçamento de pesquisa sob controlo. Utilizo modelos de DNS para vários domínios e planeio a rotação das chaves DKIM para manter as assinaturas actualizadas. Resumo ideias práticas úteis e dicas de resolução de problemas no meu Dicas para o Plesk 2025 para que possa manter uma forte Capacidade de entrega alcance.