SPF, DKIM e DMARC explicados: o guia completo sobre autenticação de e-mail [2026]

O e-mail enfrenta um problema de confiança. Não existe uma forma integrada de comprovar que uma mensagem provém realmente do domínio que alega ser o seu, razão pela qual alguém pode enviar um e-mail que pareça ter sido enviado pelo seu chefe, pelo seu banco ou pela sua empresa com apenas alguns minutos de configuração.

SPF, DKIM e DMARC são os três registos DNS que resolvem este problema. Em conjunto, indicam aos servidores de correio eletrónico de destino quais os servidores autorizados a enviar mensagens em nome do seu domínio, se cada mensagem foi adulterada durante o trânsito e o que fazer caso uma dessas verificações falhe.

Este guia explica detalhadamente como funcionam os três protocolos, como se interligam, como configurá-los na ordem correta e o que fazer caso algo corra mal. A partir de 2026, os três serão efetivamente obrigatórios para qualquer empresa que envie e-mails. O Gmail, o Yahoo e a Microsoft aplicam esta regra diretamente, e ignorar qualquer um deles prejudica a colocação das suas mensagens na caixa de entrada.

SPF, DKIM e DMARC: uma visão geral

Se quiser apenas uma visão geral rápida, esta tabela resume o essencial. Cada protocolo tem uma função que os outros não têm, e é por isso que os três são necessários em conjunto.

Corrija seus e-mails do WordPress agora

A explicação em 30 segundos

Se alguém lhe pedisse para explicar o que é a autenticação de e-mail numa festa, eis uma versão que cabe em três frases:

• O SPF indica quais os servidores autorizados a enviar e-mails em nome do seu domínio.
• O DKIM comprova que o e-mail não foi alterado por ninguém durante o trânsito.
• O DMARC indica ao servidor de receção o que fazer quando o SPF ou o DKIM falham: entregar, enviar para a pasta de spam ou rejeitar.

Precisas dos três, porque cada um complementa o que falta nos outros.

Como o SPF, o DKIM e o DMARC funcionam em conjunto

Quando um e-mail chega ao Gmail, ao Outlook ou a qualquer outra caixa de entrada, são realizadas três verificações, uma após a outra.

Primeiro, o servidor de destino obtém o endereço IP de onde a mensagem foi enviada e verifica o seu registo SPF. O registo SPF é uma lista dos servidores que autorizou a enviar e-mails em nome do seu domínio. Se o IP de origem constar da lista, a verificação SPF é aprovada.

Em segundo lugar, o servidor verifica a assinatura DKIM anexada ao e-mail. O DKIM é uma assinatura criptográfica aplicada no momento do envio, e o seu DNS contém a chave pública correspondente. Se a assinatura for verificada em relação à chave, o DKIM é aprovado, o que comprova que o conteúdo do e-mail não foi alterado entre o remetente e o destinatário.

Em terceiro lugar, o servidor verifica o seu registo DMARC. O DMARC indica duas coisas: qual dessas duas verificações deve ser aprovada e alinhar com o seu visível From: endereço e o que fazer se nenhum deles funcionar. As três opções são: entregar normalmente, enviar para a pasta de spam (quarentena) ou rejeitar a mensagem por completo.

A questão do «alinhamento» é importante. Sem ele, um atacante poderia passar no SPF para o seu próprio domínio enquanto falsifica o seu na parte visível From: linha. O DMARC colmata essa lacuna ao exigir que o domínio autenticado corresponda ao que o destinatário vê.

O que é o SPF?

O SPF (Sender Policy Framework) é um registo TXT no seu DNS que lista todos os servidores e serviços autorizados a enviar e-mails em nome do seu domínio. É a primeira linha de defesa contra a falsificação de domínios.

Um registo SPF básico tem o seguinte aspeto:

v=spf1 include:sendlayer.net ~all

Analisando a situação:

• v=spf1 indica que se trata de um registo SPF.
• include:sendlayer.net autoriza um serviço de envio, neste caso, SendLayer. Cada ferramenta de envio tem a sua própria include: diretiva.
• ~all é a regra genérica para tudo o que não corresponder. O til significa «falha leve» (permitir, mas sinalizar como suspeito). Utilizar -all selecione «falha grave» (rejeitar) assim que tiver a certeza de que o seu registo abrange todos os remetentes legítimos.

Quando chega um e-mail, o servidor de receção verifica o endereço IP de origem e verifica se esse endereço IP está autorizado pelo seu registo SPF. Se estiver, o SPF é aprovado. Caso contrário, o SPF é reprovado.

O que o FPS não consegue fazer

O SPF tem duas limitações bem conhecidas. Ele problemas com o reencaminhamento de e-mails: quando alguém reencaminha o seu e-mail, o servidor de reencaminhamento utiliza o seu próprio IP, que não consta do seu registo SPF. O SPF falha, apesar de o e-mail original ser legítimo. E isso verifica apenas o caminho de retorno, não o endereço visível From: endereço. Um atacante pode passar na verificação SPF com um domínio que controla, ao mesmo tempo que From: parecem com a sua. É por isso que o alinhamento DMARC é importante. Consulte a secção sobre DMARC abaixo.

O limite de 10 consultas DNS

Os registos SPF estão limitados a um total de 10 consultas DNS (RFC 7208). Cada include:, a, mx, ptre exists: essa diretiva conta para o limite. Se adicionar demasiados serviços de envio, vai atingir um PERMERROR, altura em que todas as autenticações falham sem aviso prévio.

A maioria das empresas depara-se com esta situação quando acumula várias ferramentas de marketing, CRMs, serviços transacionais e serviços de assistência. Se estiver perto do limite, siga o nosso guia sobre como fundir vários registos SPF num único registo simplificado.

E atenção: só é possível ter um registo SPF por domínio. Se tentar adicionar um segundo, a RFC 7208 estipula que os destinatários devem considerar toda a configuração inválida, o que equivale a não ter qualquer registo SPF.

O que é o DKIM?

O DKIM (DomainKeys Identified Mail) adiciona uma assinatura criptográfica a cada e-mail que enviar. A assinatura é gerada utilizando uma chave privada detida pelo seu serviço de envio, e o seu DNS contém a chave pública correspondente. Os servidores de receção comparam as duas chaves para confirmar que o e-mail provém efetivamente do seu domínio e que o seu conteúdo não sofreu alterações durante a transmissão.

Um registo DKIM no DNS tem o seguinte aspeto:

selector1._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

O seletor («selector1» neste exemplo) indica aos servidores de receção qual a chave DKIM que devem consultar. A maioria dos fornecedores alterna as chaves periodicamente e utiliza seletores diferentes para fluxos de envio distintos, pelo que o nome do seletor faz parte da localização do registo.

Cada e-mail que envias contém um DKIM-Signature um cabeçalho com um aspeto semelhante a este:

Assinatura DKIM: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

O d= A tag é o domínio que reivindica a assinatura. O s= A tag é o seletor. É esse o registo DNS que os destinatários irão consultar.

O que o DKIM não consegue fazer

O DKIM é poderoso, mas tem as suas limitações. Não indica quais os servidores autorizados a enviar mensagens em nome do seu domínio. Essa é a função do SPF. Um atacante pode falsificar o seu domínio sem que haja assinatura DKIM, e o DKIM, por si só, não tem qualquer influência sobre isso. Também pode deixar de funcionar se um servidor de retransmissão modificar o corpo da mensagem. Por exemplo, uma lista de correio que adicione um rodapé às mensagens enviadas. Além disso, o DKIM não possui mecanismos de imposição integrados. Um servidor de receção pode ignorar uma assinatura com falha, a menos que o DMARC lhe diga para não o fazer.

Comprimento da chave DKIM

As chaves DKIM modernas têm 2048 bits, o que resulta numa cadeia de caracteres da chave pública com mais de 255 caracteres, o comprimento máximo de um único valor de registo TXT. A maioria dos fornecedores de DNS lida com esta situação automaticamente, dividindo o valor em várias cadeias de caracteres entre aspas, mas alguns não o fazem. Se o seu registo DKIM não for guardado ou não for validado, consulte o nosso guia sobre como dividir um registo DKIM.

O que é DMARC?

O DMARC (Domain-based Message Authentication, Reporting, and Conformance) integra o SPF e o DKIM e indica aos servidores de destino o que fazer quando a autenticação falha. É o único dos três que gera relatórios para o utilizador.

Um registo DMARC típico tem o seguinte aspeto:

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r"

Cada etiqueta tem uma função:

• v=DMARC1 indica que se trata de um registo DMARC.
• p= A política é a seguinte: none, quarantine, ou reject.
• rua= é para onde são enviados os relatórios agregados.
• pct= é a percentagem de e-mails a que a política se aplica (útil para implementações graduais).
• aspf= e adkim= modo de alinhamento de controlo, flexível (r) ou rigoroso (s).

Evolução da política: p=nenhuma → p=quarentena → p=rejeitar

A implementação do DMARC é um processo gradual, não uma mudança repentina. As três políticas representam etapas, e o utilizador avança por elas à medida que ganha confiança.

• p=none: Modo de monitorização. Os e-mails com falha são entregues normalmente, mas recebe relatórios sobre os mesmos. Comece sempre por aqui.
• p=quarentena: os e-mails rejeitados são enviados para a pasta de spam do destinatário. Mova-os para aqui após 2 a 4 semanas, quando p=nenhum e não houver e-mails legítimos a serem rejeitados.
• p = rejeitar: Os e-mails com falhas são rejeitados imediatamente (a 550 (Erro SMTP). Mude-se para cá após mais 2 a 4 semanas em quarentena.

Ir diretamente para p=reject é a causa mais comum de interrupções relacionadas com o DMARC. Só descobrirá fontes de envio legítimas de que se tinha esquecido (o seu CRM, a sua ferramenta de marketing, o seu serviço de apoio ao cliente) depois de estas serem rejeitadas. Comece sempre por p=none, leia os relatórios e, em seguida, encaminhe para um nível superior.

Relatórios agregados do DMARC

Quando define rua= No seu registo DMARC, começará a receber relatórios XML diários de todos os fornecedores de e-mail que gerem o e-mail do seu domínio: Google, Microsoft, Yahoo e outros. Estes relatórios mostram todos os endereços IP que enviaram e-mails sob o seu domínio e se as verificações SPF e DKIM foram bem-sucedidas e estão alinhadas para cada um deles.

O XML bruto contém muitos dados irrelevantes e é legível por máquinas, pelo que a maioria das equipas integra o seu rua= introduzir o endereço num serviço de relatórios DMARC (Postmark, dmarcian, EasyDMARC, etc.) que analisa os relatórios e os apresenta num painel de controlo de fácil leitura. É a única forma de identificar fontes de envio legítimas que possa ter ignorado antes de tornar a sua política mais rigorosa.

Alinhamento DMARC

O DMARC introduz um conceito que os outros protocolos não possuem: alinhamento. O SPF e o DKIM são considerados válidos quando a respetiva verificação é bem-sucedida, mas o DMARC só considera essa verificação válida se o domínio autenticado corresponder ao domínio visível From: endereço.

Dois sabores:

• Alinhamento do SPF: o smtp.mailfrom O domínio (return-path) corresponde ao From: domínio.
• Alinhamento DKIM: o d= A tag na assinatura DKIM corresponde à From: domínio.

O DMARC é aprovado se pelo menos um destes critérios for cumprido e a verificação subjacente for bem-sucedida.

O alinhamento flexível (predefinição) permite correspondências de subdomínios, e-mails provenientes de mail.example.com está em consonância com um From: em example.com. O alinhamento rigoroso exige uma correspondência exata. A maioria dos remetentes utiliza o alinhamento flexível, a menos que tenham um motivo de segurança específico para optar pelo rigoroso.

O desalinhamento é a causa mais comum de falha no DMARC, mesmo quando o SPF e o DKIM são aprovados individualmente. Muitos serviços de envio autenticam-se utilizando próprios domínio (por exemplo, sendgrid.net), e não o seu, o que significa que o SPF e o DKIM são válidos, mas o DMARC falha porque nada está em conformidade com example.com. Corrigir o alinhamento implica, normalmente, mudar para um caminho de retorno personalizado ou para uma assinatura DKIM com a marca da sua empresa, oferecida pelo seu fornecedor.

Como adicionar um registo DMARC

Se o seu provedor de e-mail lhe fornecer um registo DMARC específico, adicione-o. Caso contrário, este é um registo genérico inicial seguro em _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected];

Isto coloca-o no modo de monitorização, com os relatórios a serem enviados para uma caixa de correio que controla. Para uma configuração completa, incluindo o tratamento de relatórios e a evolução das políticas, consulte o nosso guia específico sobre como criar um registo DMARC.

Por que precisa dos três (e o que acontece se tiver apenas um)

Cada protocolo resolve o que os outros não conseguem. Eis o resumo:

Se utilizar apenas o SPF, fica vulnerável a falsificações baseadas no alinhamento: um atacante autentica-se com o seu próprio domínio enquanto exibe o seu. Se utilizar apenas o DKIM, qualquer servidor pode continuar a fazer-se passar por si. Se utilizar apenas o DMARC, não existe qualquer autenticação subjacente que este possa fazer cumprir. A única configuração que realmente funciona é a que inclui os três em conjunto.

O SPF, o DKIM e o DMARC serão obrigatórios em 2026?

A autenticação de e-mail passou de «boa prática» a «requisito imprescindível» entre 2024 e 2026. Eis a situação atual.

Remetentes em massa (mais de 5 000 e-mails por dia para o Gmail ou o Yahoo)

• Fevereiro de 2024: O Gmail e o Yahoo introduziram requisitos para remetentes em massa. São obrigatórios os protocolos SPF, DKIM e DMARC. São obrigatórios cabeçalhos de cancelamento de subscrição com um clique. A taxa de reclamações de spam deve permanecer abaixo de 0,3%.
• Maio de 2025: A Microsoft introduziu requisitos equivalentes para o Outlook.com, o Hotmail e o Live.com.
• Novembro de 2025: O Gmail passou de adiamentos temporários (erros 421) para rejeição definitiva (erros 550) no caso de mensagens não conformes. Já não existe período de carência. As mensagens não conformes são rejeitadas imediatamente.

Remetentes com menor volume (menos de 5 000 por dia)

Tecnicamente, não está sujeito às regras aplicáveis aos remetentes em massa, mas as verificações de autenticação subjacentes aplicam-se a todas as ligações. A ausência de SPF, DKIM ou DMARC reduz a taxa de entrega na caixa de entrada em até 76 %, mesmo com volumes reduzidos. As regras visam, em princípio, os remetentes em massa; no entanto, os filtros de spam utilizam os mesmos critérios para todos.

Contextos de conformidade

• A norma PCI DSS v4.0 inclui requisitos de autenticação de e-mail para organizações que tratam de dados de cartões de pagamento.
• Diretiva Operacional Vinculativa n.º 18-01 da CISA exige que todas as agências federais dos EUA implementem SPF, DKIM e DMARC com p=reject.
• Existem requisitos semelhantes no Reino Unido (NCSC), na Austrália (ACSC) e no Canadá (CCCS) para o setor público e as infraestruturas críticas.

Conclusão: mesmo que envie 50 e-mails por mês a partir do seu formulário de contacto, continua a precisar dos três registos.

A ordem de configuração que importa (a maioria das pessoas erra nisto)

Adicione primeiro o SPF. Depois, o DKIM. E, por fim, o DMARC. Com intervalos entre cada um. Esta ordem é inalterável, e errar nesta sequência é a razão mais comum pela qual as novas implementações prejudicam a entrega.

Porquê esta ordem?

O DMARC verifica os resultados do SPF e do DKIM. Se adicionar o DMARC antes de esses dois estarem implementados e validados, todos os e-mails falharão na autenticação. Com uma política de p=quarantine ou p=reject, o que significa que os seus e-mails começam a ir parar à pasta de spam ou a ser rejeitados assim que o DMARC for implementado. Muitos provedores nem sequer permitem que adicione um registo DMARC até que o SPF seja validado.

Tempo até cada um ficar ativo

• FPS: 5–30 minutos
• DKIM: 1 a 4 horas
• DMARC: 1–24 horas

Depois de cada registo ser propagado, envie um e-mail de teste para um endereço do Gmail que controle e verifique os cabeçalhos através da opção «Mostrar original». Tanto o SPF como o DKIM devem aparecer PASS antes de adicionar o DMARC.

Onde adicionar registos SPF, DKIM e DMARC

Os três registos são adicionados como registos TXT nas definições de DNS do seu domínio, no mesmo local onde gere os registos A, os registos MX e os servidores de nomes. O local exato onde se encontram depende de quem gere o seu DNS.

Servidores partilhados (Bluehost, SiteGround, HostGator)

A maioria dos serviços de alojamento partilhado inclui um Editor de Zonas DNS no seu painel de controlo, na secção «Domínio» ou «Gestão de DNS». Procure uma opção para adicionar um registo TXT.

Registadores de domínios (GoDaddy, Namecheap, Google Domains)

Se o seu alojamento e domínio forem separados, o seu DNS costuma estar gerido pelo seu registador. Procure por «Definições de DNS» ou «Gerir DNS» no painel de controlo do seu domínio.

Cloudflare

Abra o painel do Cloudflare, selecione o seu domínio, clique em «DNS» no menu à esquerda e adicione um novo registo TXT. Eis a vista do editor:

Vercel

Se o Vercel hospedar o DNS do seu domínio, abra o projeto e clique em Definições → Domínios → Registos DNSe adicione um novo registo TXT. O campo «Host» aceita @ para o vértice (utilizado para o SPF) e _dmarc para o DMARC.

Netlify

O Netlify DNS encontra-se na secção «Domínios» do painel da sua equipa. Clique no domínio e, em seguida, em «Configurar o Netlify DNS» (se ainda não o tiver feito) e, por fim, adicione registos na secção «Registos DNS».

Squarespace

O Squarespace gere o DNS através de Domínios → [nome do domínio] → Configurações de DNS → Registos personalizados. Adicione registos TXT com Host = @ para o domínio de topo, ou _dmarc para o DMARC.

Como testar o SPF, o DKIM e o DMARC

Três formas fiáveis de verificar se os três registos estão a funcionar conforme o esperado.

Método 1: Gmail «Mostrar original»

Envie um e-mail de teste a partir do seu domínio para um endereço do Gmail que controle. Assim que chegar, abra o e-mail, clique no menu com os três pontos no canto superior direito e selecione «Mostrar original». Procure estas três linhas na parte superior:

• SPF: Aprovado (com o seu domínio)
• DKIM: PASS (com header.d= (indicando o seu domínio)
• DMARC: APROVADO

Se algum destes sintomas se manifestar FAIL ou NEUTRAL, passe diretamente para a secção de resolução de problemas abaixo.

Método 2: Jogos de damas online

O MxToolbox, o dmarcian e o HostedScan oferecem todos verificações gratuitas de SPF, DKIM e DMARC. Introduza o seu domínio e obterá um rápido resultado de aprovação/reprovação para cada registo, além de diagnósticos para erros comuns, como um número excessivo de consultas DNS ou problemas de sintaxe.

Método 3: Verificador de domínios do WP Mail SMTP

A ferramenta de teste de e-mail do WP Mail SMTP verifica automaticamente os três registos sempre que enviar um e-mail de teste, sem necessidade de utilizar uma ferramenta separada. A ferramenta assinala registos em falta, registos SPF duplicados, problemas com a assinatura DKIM, falhas de alinhamento DMARC e problemas com o registo PTR, tudo a partir do painel de administração do WordPress.

Resolução de problemas relacionados com falhas de SPF, DKIM e DMARC

Se os seus registos estiverem configurados, mas a autenticação continuar a falhar, a causa reside quase sempre numa destas situações. Cada uma segue o mesmo padrão: sintoma → causa provável → diagnóstico → solução.

1. O DMARC falha, apesar de o SPF ter sido aprovado

Sintoma: A opção «Mostrar original» do Gmail mostra SPF: PASS mas DMARC: FAIL.

Causa provável: Falha no alinhamento do SPF. O domínio do caminho de retorno não corresponde ao domínio visível From: domínio.

Diagnóstico: Olha para o smtp.mailfrom valor nos cabeçalhos, corresponde ao domínio em From:?

Solução: Altere o caminho de retorno do seu serviço de envio para o seu domínio (a maioria dos fornecedores disponibiliza uma configuração de «caminho de retorno personalizado» ou «domínio de rejeição») ou recorra ao alinhamento DKIM, que é frequentemente mais fácil de configurar.

2. Falta a assinatura DKIM nos e-mails recebidos

Sintoma: Os cabeçalhos não mostram DKIM-Signature: nem sequer uma linha.

Causa provável: o DKIM não está, de facto, configurado no lado do remetente, ou está a ser utilizado um seletor incorreto.

Diagnóstico: Envie um teste a partir de outra ferramenta (diretamente do Gmail ou de outro serviço SMTP) para comparar. Verifique o painel do seu fornecedor de SMTP para ver o estado do DKIM; a maioria indica se o seletor está verificado.

Solução: Verifique novamente se os registos DKIM CNAME ou TXT existem exatamente como especificado pelo seu fornecedor. O nome do seletor no seu registo DNS deve corresponder ao que o fornecedor está a utilizar para assinar; erros ortográficos neste contexto são extremamente comuns.

3. SPF «permerror: demasiadas consultas DNS»

Sintoma: Os servidores de e-mail rejeitam as suas mensagens com um SPF PERMERROR.

Causa provável: O seu registo SPF contém mais de 10 consultas DNS (o limite máximo definido pela RFC 7208). É comum quando se empilham include: diretrizes para vários serviços.

Diagnóstico: Use uma ferramenta de nivelamento de SPF para contar as suas consultas. Cada include:, a, mx, ptre exists: conta.

Solução: Remova as inclusões desnecessárias ou utilize um serviço de simplificação de SPF que converta as inclusões em entradas de IP diretas. Encontre o passo a passo completo no nosso guia de fusão de SPF.

4. Vários registos SPF no mesmo domínio

Sintoma: FPS PERMERROR ou NEUTRAL apesar de ter um registo que parece válido.

Causa provável: tem dois ou mais registos SPF TXT. A norma RFC 7208 considera que esta situação é inválida; os destinatários irão tratá-la como se não existisse qualquer registo SPF.

Diagnóstico: Correr dig TXT yourdomain.com, ou utilize a pesquisa de SPF do MxToolbox. Se vir dois registos que começam por v=spf1. É esse o problema.

Solução: Misture o include: instruções de ambos os registos num único registo. Guia detalhado aqui.

5. Falha no alinhamento DMARC (o assassino silencioso)

Sintoma: SPF: PASS e DKIM: PASS mas DMARC: FAIL.

Causa provável: Nenhum dos protocolos está em conformidade com o From: domínio, apesar de ambos passarem individualmente.

Diagnóstico: Comparar três valores nos cabeçalhos, o From: domínio, o smtp.mailfrom domínio e o DKIM d= etiqueta. Pelo menos uma das duas últimas deve corresponder à primeira.

Solução: Configure o seu serviço de envio para utilizar o seu domínio no caminho de retorno (para alinhamento SPF) ou na assinatura DKIM (para alinhamento DKIM). A maioria dos fornecedores utiliza, por predefinição, o seu próprio domínio; terá de ativar manualmente o alinhamento.

6. Registo DKIM demasiado longo para o DNS

Sintoma: O seu fornecedor atribuiu-lhe uma chave DKIM, mas o DNS não a aceita.

Causa provável: Os registos TXT individuais têm um limite de 255 caracteres por cadeia de caracteres. As chaves DKIM de 2048 bits excedem esse limite e têm de ser divididas em várias cadeias de caracteres entre aspas dentro do mesmo registo.

Diagnóstico: Conte os caracteres na sua chave; se forem mais de 255, significa que esse é o problema.

Solução: Divida o valor em blocos de 255 caracteres, cada um entre aspas: "v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI...". A maioria dos fornecedores de DNS modernos faz isso automaticamente; outros não. Guia completo em Como dividir um registo DKIM.

7. O SPF inclui o seu provedor, mas os e-mails continuam a não ser entregues

Sintoma: O seu registo SPF inclui corretamente o seu servidor de correio (por exemplo, include:sendlayer.net), mas os e-mails continuam a falhar na verificação do SPF.

Causa provável: está a enviar a partir de um endereço IP diferente daquele para o qual o seu include remete, normalmente porque tem vários serviços a enviar mensagens sob o mesmo domínio (por exemplo, mensagens transacionais através SendLayer e de marketing através do Mailchimp), mas apenas incluiu um.

Diagnóstico: Verifique os cabeçalhos para identificar o IP de origem real. Compare-o com os IPs constantes no registo SPF do seu domínio.

Solução: Adicione tags de inclusão para todos os serviços que enviam mensagens a partir do seu domínio, incluindo todas as ferramentas de marketing, serviços transacionais, serviço de assistência e CRM. Se isso fizer com que ultrapasse o limite de 10 consultas, consulte a questão n.º 3.

8. A configuração DMARC p=reject está a bloquear os seus próprios e-mails legítimos

Sintoma: Os clientes deixam de receber os seus e-mails transacionais (redefinições de palavra-passe, recibos), mas os seus envios de teste funcionam normalmente.

Causa provável: Mudaste-te para p=reject demasiado depressa, antes de incluir todas as fontes de envio legítimas no seu SPF.

Diagnóstico: Verifique os seus relatórios agregados do DMARC; estes mostram todos os remetentes que têm falhado no seu domínio. Os remetentes legítimos serão fáceis de identificar (o seu CRM, ferramenta de marketing, serviço de assistência).

Solução: Voltar para p=quarantine ou p=none. Utilize os relatórios DMARC para adicionar os remetentes legítimos em falta à lista SPF. Aguarde 2 a 4 semanas até que os relatórios indiquem 0% de falhas no correio legítimo e, em seguida, volte a aplicar a política.

9. Registos adicionados, mas que não estão a ser propagados

Sintoma: Adicionou os registos, mas as ferramentas continuam a indicar que faltam.

Causa provável: armazenamento em cache do DNS no seu registador, no seu resolvedor local ou no servidor de destino. É comum que ocorram alterações com TTL baixo após registos com TTL elevado terem sido previamente armazenados em cache.

Diagnóstico: Correr dig +trace TXT yourdomain.com a partir de uma rede diferente, ou consultar diretamente o DNS do Google com dig @8.8.8.8 TXT yourdomain.com. Se esses comandos mostrarem o registo, mas o seu programa de teste não, trata-se de um problema de cache.

Solução: Espere. A propagação do SPF geralmente é concluída em menos de uma hora, enquanto a do DMARC pode demorar até 24 horas. Se, após 48 horas, ainda não tiver resultados, verifique novamente se o registo foi guardado corretamente no seu registador; uma armadilha comum são as interfaces que exigem um passo de confirmação que possa ter ignorado.

10. Os e-mails de teste são bem-sucedidos, mas os e-mails reais falham

Sintoma: O e-mail de teste do WP Mail SMTP apresenta todos os indicadores a verde, mas os e-mails reais do WordPress (notificações de formulários, redefinições de palavra-passe) falham na autenticação.

Causa provável: percursos de envio diferentes. O teste do plugin é enviado através do servidor de e-mail configurado, mas os e-mails do WordPress gerados por alguns plugins ou formulários podem ignorá-lo.

Diagnóstico: Verifique o From: O endereço dos e-mails que não estão a ser entregues é do seu domínio, ou [email protected]? Se for o último caso, existe uma discrepância no endereço de remetente.

Solução: No WP Mail SMTP, ative a opção «Forçar endereço de remetente» para que todos os e-mails do WordPress utilizem o seu endereço autenticado, independentemente da configuração definida pelo plugin de origem.

Notas específicas do WordPress

O WordPress tem um problema específico com o e-mail: por predefinição, utiliza o PHP mail() função, que envia mensagens sem qualquer autenticação. Os seus registos SPF, DKIM e DMARC podem estar perfeitamente configurados, mas se o WordPress estiver a enviar e-mails através do PHP mail() Se o tráfego for proveniente do IP partilhado do seu alojamento web e esse IP não constar no seu registo SPF, todas as verificações de autenticação falharão.

A solução consiste em encaminhar todos os e-mails do WordPress através de um serviço SMTP autenticado. O WP Mail SMTP faz isso através de integrações com um clique para SendLayer, SMTP.com, Brevo, Gmail/Google Workspace, Microsoft 365, Amazon SES, Mailgun, SendGrid, Postmark, SparkPost e outros. Cada integração está pré-configurada para se autenticar corretamente e estar em conformidade com o seu domínio.

Se os seus e-mails do WordPress estão a ir parar à pasta de spam, a causa geralmente é a falta de autenticação ou uma autenticação incorreta. Encontra o diagnóstico completo no nosso guia sobre por que razão os e-mails do WordPress vão parar à pasta de spam.

Corrija seus e-mails do WordPress agora

v=DMARC1; p=none; rua=mailto:[email protected];

v=spf1 include:sendlayer.net ~all

v=spf1 include:sendlayer.net include:_spf.google.com ~all

Em seguida, verifique o seu registo PTR

SPF, DKIM e DMARC são três dos quatro registos DNS que são importantes para a capacidade de entrega de e-mails. O quarto é o seu registo PTR, a entrada DNS inversa que associa o seu IP de envio ao seu domínio. Os fornecedores de serviços de e-mail verificam-no em cada ligação, e um registo PTR ausente ou genérico prejudicará a sua capacidade de entrega, mesmo que o SPF, o DKIM e o DMARC sejam todos aprovados.

Para obter informações detalhadas, consulte o nosso guia sobre registos PTR e DNS inverso. Se estiver a enviar um volume significativo de mensagens, convém também configurar as Ferramentas do Google para administradores de correio eletrónico para monitorizar a forma como o Gmail avalia a sua reputação de remetente.

Pronto para corrigir os seus e-mails? Comece hoje mesmo com o melhor plugin SMTP para WordPress. Se não tiver tempo para corrigir os seus e-mails, pode obter assistência completa de Configuração de Luva Branca como uma compra extra, e há uma garantia de reembolso de 14 dias para todos os planos pagos.

Se este artigo o ajudou, siga-nos no Facebook e no Twitter para obter mais dicas e tutoriais sobre o WordPress.