A autenticação de e-mail é um dos aspetos mais importantes da capacidade de entrega de e-mails e um dos mais mal compreendidos.
A maioria dos remetentes sabe que precisa do SPF, do DKIM e do DMARC, mas apenas alguns compreendem o que cada um deles faz realmente, como funcionam em conjunto ou por que razão os e-mails podem continuar a ir parar à pasta de spam, mesmo quando os três estão configurados.
Parte da confusão deve-se ao facto de se considerar a autenticação como uma solução para a entregabilidade, quando na verdade não o é. A autenticação ajuda os fornecedores de caixas de correio a verificar quem enviou uma mensagem e se esta é fiável. Sem ela, os seus e-mails podem ser rejeitados ou filtrados. Com ela, está simplesmente a cumprir um requisito básico.
Neste guia, irá aprender o que cada método de autenticação faz, como funcionam em conjunto, como configurá-los corretamente e quais são os erros comuns que causam falhas de autenticação, mesmo quando os registos parecem estar configurados corretamente.
O que é a autenticação de e-mail?
A autenticação de e-mail consiste num conjunto de métodos que permite que os serviços de e-mail destinatários, como o Gmail e o Outlook, verifiquem se um e-mail provém efetivamente do domínio que indica e se não foi falsificado ou alterado durante a transmissão.
Funciona através dos registos DNS que o domínio remetente publica:
- O SPF enumera os servidores autorizados a enviar
- O DKIM adiciona uma assinatura criptográfica que confirma que a mensagem não foi adulterada
- O DMARC define a política que está associada ao endereço «De» visível e indica aos destinatários o que devem fazer quando uma verificação falha.
Em conjunto, estes protocolos confirmam a identidade do remetente, um dos critérios que os prestadores de serviços têm em conta antes de decidirem se aceitam, filtram ou rejeitam o correio recebido.
| O que a autenticação comprova |
O que a autenticação não comprova |
| O servidor de envio está autorizado para o seu domínio (SPF) |
Que os fornecedores confiem no seu domínio (reputação) |
| A mensagem não foi alterada durante a transmissão (DKIM) |
Que os destinatários queiram receber ou interajam com o seu e-mail (reputação) |
| O seu domínio «De:» corresponde ao que foi verificado (DMARC) |
Que o seu conteúdo não seja detetado pelos filtros de spam (conteúdo) |
| Cumpre os requisitos mínimos de admissão da entidade prestadora |
Para que o teu e-mail chegue à caixa de entrada |
Os 3 principais métodos de autenticação de e-mail
A autenticação de e-mail assenta em três protocolos que funcionam em conjunto para verificar quem está a enviar um e-mail e se essa mensagem é fiável. Cada um deles tem uma finalidade diferente, e compreender como se articulam entre si é essencial para resolver problemas relacionados com a capacidade de entrega e a autenticação.
SPF (Sender Policy Framework)
O SPF (Sender Policy Framework) é um método de autenticação de e-mail que utiliza um registo TXT do DNS para especificar quais os servidores e endereços IP autorizados a enviar e-mails em nome do seu domínio.
Quando é recebido um e-mail, o fornecedor da caixa de correio consulta o registo SPF do domínio remetente e compara o endereço IP do servidor remetente com a lista de remetentes autorizados. Se o servidor estiver autorizado, o SPF é aprovado. Caso contrário, o SPF é rejeitado.
O objetivo do SPF é confirmar se o servidor que envia o e-mail está autorizado a enviar mensagens para esse domínio. Não verifica o conteúdo da mensagem, a reputação, o envolvimento nem se o e-mail deve chegar à caixa de entrada.
DKIM (DomainKeys Identified Mail)
O DKIM (DomainKeys Identified Mail) é um método de autenticação de e-mail que adiciona uma assinatura criptográfica aos seus e-mails enviados, utilizando um par de chaves pública e privada, para que os provedores de e-mail destinatários possam confirmar que a mensagem foi assinada pelo seu domínio e que não sofreu alterações durante o trânsito.
Quando é recebido um e-mail, o fornecedor da caixa de correio procura a chave pública publicada no DNS do seu domínio sob um seletor específico e utiliza-a para verificar a assinatura adicionada pela sua plataforma de envio. Se a assinatura for válida e a mensagem não tiver sido alterada, a verificação DKIM é bem-sucedida. Se as chaves não corresponderem ou se a mensagem tiver sido alterada, a verificação DKIM falha.
O objetivo do DKIM é confirmar que o e-mail foi assinado por um domínio autorizado na assinatura DKIM e que as partes assinadas da mensagem não foram alteradas após o envio. Por si só, não prova que o domínio «De» visível corresponda ao domínio autenticado. Essa correspondência é gerida pelo DMARC.
DMARC (e a questão do cabeçalho MAIL FROM versus From:)
O DMARC (Domain-based Message Authentication, Reporting and Conformance) é um método de autenticação de e-mail que utiliza um registo DNS para associar os resultados do SPF e do DKIM ao domínio presente no endereço «De:» visível e para indicar aos provedores destinatários o que devem fazer quando a autenticação falha.
Quando é recebido um e-mail, o fornecedor da caixa de correio verifica se o domínio que passou na verificação SPF ou DKIM corresponde ao domínio que consta no endereço «De:» que o destinatário vê efetivamente. Se corresponderem, o DMARC é aprovado. Caso contrário, o DMARC falha e o fornecedor aplica a política que publicou: p=none (apenas monitorizar), p=quarantine (enviar para spam) ou p=reject (bloquear a mensagem).
O objetivo do DMARC é confirmar que o domínio autenticado corresponde ao que o destinatário vê, o que impede que terceiros falsifiquem o seu domínio, e dar-lhe controlo sobre a forma como as falhas são tratadas.
| Fator |
SPF |
DKIM |
DMARC |
| Nome completo |
Estrutura de Políticas do Remetente |
Correio Identificado por DomainKeys |
Autenticação, Relatório e Conformidade de Mensagens com Base no Domínio |
| Objetivo principal |
Verifica se o servidor remetente está autorizado a enviar mensagens em nome do domínio |
Verifica se a mensagem não foi alterada durante a transmissão |
Verifica a correspondência do domínio e indica aos destinatários como lidar com falhas de autenticação |
| O que verifica |
Servidor de envio ou endereço IP |
Integridade da mensagem e identidade do remetente através de uma assinatura criptográfica |
Se o SPF e/ou o DKIM foram aprovados e estão de acordo com o domínio «From:» visível |
| Protege contra |
Envio não autorizado a partir de servidores não aprovados |
Alteração de mensagens e assinaturas falsificadas |
Falsificação de domínios e suplantação de identidade |
| Publicado como |
Registo TXT do DNS |
Registo TXT do DNS (chave pública) |
Registo TXT do DNS |
| Avalia |
Infraestrutura de envio |
Conteúdo da mensagem e assinatura |
Resultados da autenticação e alinhamento de domínios |
| Utiliza o DNS? |
Sim |
Sim |
Sim |
| É aprovado quando |
O servidor de envio está autorizado no registo SPF |
A assinatura DKIM é validada em relação à chave publicada |
O SPF ou o DKIM são validados e correspondem ao domínio «From:» |
| Falha quando |
O servidor de envio não está autorizado |
A assinatura está em falta, é inválida ou foi alterada |
Nem o SPF nem o DKIM correspondem ao domínio «From:» |
| Visível para os destinatários? |
Não |
Não |
Não |
| Oferece funcionalidades de relatórios? |
Não |
Não |
Sim, através de relatórios agregados e forenses |
| Opções de aplicação da lei |
Nenhum |
Nenhum |
p=nenhum, p=quarentena, p=rejeitar |
| Consegue trabalhar sozinho? |
Sim, mas oferece uma proteção limitada |
Sim, mas oferece uma proteção limitada |
Não. O DMARC depende do SPF e/ou do DKIM |
| Problema mais comum |
Faltam fontes de envio ou limites de consulta SPF |
Seletor incorreto ou configuração de assinatura incorreta |
Falhas de alinhamento entre domínios autenticados e visíveis |
| Responde a esta pergunta |
«Este servidor está autorizado a enviar mensagens para este domínio?» |
«Esta mensagem foi alterada e foi assinada por este domínio?» |
«Os domínios autenticados correspondem ao domínio que o destinatário vê?» |
| Papel na capacidade de entrega moderna |
Referência de autenticação |
Referência de autenticação |
Camada de políticas e aplicação exigida pelos principais fornecedores de serviços de correio eletrónico |
| Exigido pelas regras relativas aos remetentes em massa do Gmail, do Yahoo e do Outlook |
Sim |
Sim |
Sim |
Verifique se os seus registos são efetivamente válidos, e não apenas se existem.
Uma pesquisa de DNS apenas confirma que um registo está publicado. Não indica se o SPF e o DKIM são validados quando o Gmail e o Outlook recebem o seu e-mail. O Verificador de SPF e o Verificador de DKIM gratuitos da MailReach realizam testes de ponta a ponta e assinalam problemas relacionados com SPF, DKIM, DMARC, listas negras e DNS reverso num único relatório.
BIMI (e por que é opcional na abordagem fria B2B)
O BIMI (Brand Indicators for Message Identification) é uma norma de e-mail que apresenta o logótipo verificado da sua marca ao lado das suas mensagens nas caixas de entrada compatíveis, mas apenas quando o seu domínio estiver em modo de aplicação do DMARC.
Quando é recebido um e-mail, os fornecedores de serviços de suporte verificam se o seu domínio está a aplicar o DMARC (p=quarantine ou p=reject) e procuram um registo BIMI no seu DNS que aponte para o seu logótipo. Se essas condições forem cumpridas, o seu logótipo é apresentado ao lado da mensagem. A maioria dos principais fornecedores também exige um Certificado de Marca Verificada (VMC) que comprove que é o proprietário do logótipo antes de o exibirem.
O objetivo do BIMI é o reconhecimento visual da marca na caixa de entrada, e não a capacidade de entrega. Não afeta a reputação do remetente, os seus resultados de autenticação nem o facto de o seu e-mail chegar ou não à caixa de entrada. No que diz respeito à abordagem não solicitada (cold outreach) no contexto B2B, é opcional e tem baixa prioridade. Trata-se de uma camada de branding, não de um fator determinante para a capacidade de entrega; por isso, se for um remetente de e-mails de saída a decidir onde investir o seu tempo, o BIMI deve ficar no fim da lista.
Como o SPF, o DKIM e o DMARC funcionam em conjunto
O SPF, o DKIM e o DMARC foram concebidos para funcionar em cadeia, sendo que cada um deles resolve uma parte diferente do problema da autenticação de e-mail.
- O SPF verifica se o servidor que envia o e-mail está autorizado a enviar em nome do domínio.
- O DKIM verifica se a mensagem não foi alterada após ter sido enviada.
- O DMARC funciona em conjunto com ambos e verifica se o domínio que passou na verificação SPF ou DKIM corresponde ao domínio que o destinatário vê no endereço «De:».
Um e-mail não precisa de ser aprovado tanto no SPF como no DKIM para que o DMARC seja aprovado. Basta que um deles seja aprovado e esteja alinhado com o domínio visível no campo «De:». Se nenhum dos dois estiver alinhado, o DMARC falha, mesmo que o SPF ou o DKIM tenham sido aprovados individualmente.
É por isso que os problemas de autenticação podem ser confusos. Uma mensagem pode ser aprovada no SPF, ser aprovada no DKIM e, mesmo assim, falhar no DMARC, porque os domínios autenticados não correspondem ao endereço «De:». Por outro lado, uma mensagem pode falhar no SPF, mas mesmo assim ser aprovada no DMARC, se o DKIM for aprovado e corresponder corretamente.
Em conjunto, estas três normas ajudam os fornecedores de caixas de correio eletrónico a verificar quem enviou o e-mail, se este foi alterado durante o trânsito e se a identidade do remetente é fiável. Sem a combinação destas três normas, os fornecedores têm menos confiança na mensagem e são mais propensos a filtrá-la, classificá-la como lixo eletrónico ou rejeitá-la.
Requisitos dos fornecedores: Google, Yahoo e Microsoft
Desde fevereiro de 2024, a Google e a Yahoo tornaram a autenticação um requisito básico para os remetentes em massa. Os remetentes em massa precisam de SPF e DKIM, uma política DMARC com, pelo menos, p=none, autenticação alinhada, baixas taxas de reclamações de spam e um processo de cancelamento de subscrição funcional para mensagens de marketing ou mensagens a que os destinatários se tenham subscrito.
A Microsoft também introduziu requisitos para remetentes de grande volume, aplicáveis a domínios que enviam mais de 5 000 e-mails por dia para endereços de utilizadores particulares do Outlook.com, incluindo outlook.com, hotmail.com, live.com e msn.com. Estes requisitos incluem a conformidade com as normas SPF, DKIM e DMARC.
A lição prática a reter é simples: mesmo que, tecnicamente, não ultrapasse todos os limites aplicáveis aos remetentes em massa, a autenticação é agora um requisito imprescindível. Deve ter o SPF, o DKIM e o DMARC configurados corretamente antes de expandir qualquer atividade de envio em grande escala.
Como configurar e verificar a autenticação de e-mail (passo a passo)
A autenticação de e-mail funciona melhor quando os protocolos SPF, DKIM e DMARC são configurados em conjunto. Uma vez que cada protocolo se baseia nos outros, faz sentido configurá-los numa ordem específica.
Passo 1: Identifique as suas fontes de envio de e-mail
Comece por enumerar todas as plataformas que enviam e-mails utilizando o seu domínio. Normalmente, isto inclui:
- O seu fornecedor de e-mail (Google Workspace, Microsoft 365, etc.)
- Plataformas de marketing
- Sistemas de CRM
- Ferramentas de abordagem a clientes potenciais
- Plataformas de assistência técnica e apoio ao cliente
- Sistemas de cobrança e faturação
- Qualquer outra aplicação que envie e-mails em seu nome
Dispor de um inventário completo facilita a configuração correta da autenticação e evita que remetentes legítimos sejam ignorados.
Passo 2: Configurar o SPF
Publique um registo SPF no seu DNS que autorize os servidores autorizados a enviar e-mails em nome do seu domínio.
Ao criar o seu registo SPF:
- Publicar um único registo TXT SPF para o domínio
- Adicionar todas as plataformas de envio legítimas
- Utilize os mecanismos de inclusão recomendados pelo fornecedor, sempre que disponíveis
- Revise o registo sempre que for adicionada uma nova ferramenta de envio
- Mantenha o registo preciso e atualizado
O registo deve incluir todas as fontes de envio legítimas, mantendo-se, ao mesmo tempo, preciso e atualizado à medida que são adicionadas novas ferramentas.
Passo 3: Configurar o DKIM
Ative o DKIM para cada plataforma que envie e-mails em seu nome.
O DKIM permite que os destinatários verifiquem se uma mensagem não foi alterada após o seu envio.
Para cada plataforma de e-mail:
- Gerar um par de chaves DKIM na plataforma
- Publicar a chave pública no DNS
- Utilize o seletor fornecido pelo fornecedor
- Ativar a assinatura DKIM para o correio enviado
- Verifique se as assinaturas DKIM estão a ser aceites nas mensagens entregues
A maioria dos fornecedores gera um registo DKIM que deve publicar no DNS. Depois de configurado, as mensagens enviadas são assinadas automaticamente, para que os fornecedores destinatários possam verificar a integridade das mensagens.
Passo 4: Configurar o DMARC
Publique um registo DMARC para definir como os provedores de receção devem tratar as mensagens que não passam na autenticação.
Comece por:
- Um registo DMARC publicado em _dmarc.yourdomain.com
- Uma política de monitorização (p=nenhuma)
- Um endereço de referência agregado (rua=)
- Análises regulares dos relatórios DMARC
Antes de passar à fase de execução:
- Confirmar se todos os remetentes legítimos estão autenticados
- Resolver falhas de alinhamento
- Validar os resultados do SPF e do DKIM em todas as plataformas de envio
A maioria das organizações começa com uma política de monitorização (p=nenhuma) para analisar os resultados da autenticação antes de passar para políticas de aplicação mais rigorosas, tais como p=quarentena ou p=rejeição.
Passo 5: Verificar os resultados da autenticação
Após a configuração, verifique se o SPF, o DKIM e o DMARC estão, de facto, a ser validados nas mensagens entregues.
Verifique se:
- O SPF reenvia as mensagens entregues
- O DKIM é aplicado às mensagens entregues
- O DMARC é aprovado e está corretamente alinhado
- A autenticação continua a funcionar corretamente após a adição de novas ferramentas ou fornecedores
Um registo DNS, por si só, apenas confirma que a configuração existe. A verificação confirma que os fornecedores de caixas de correio conseguem autenticar com sucesso o seu e-mail em condições reais de receção.
Verificar no DNS não é o mesmo que verificar na caixa de entrada.
Este é o passo que a maioria dos remetentes ignora. O Teste de Entregabilidade de E-mail gratuito da MailReach envia o seu e-mail para caixas de entrada de teste nos ambientes do Google, da Microsoft e do Yahoo e, em seguida, mostra onde ele vai parar: na caixa de entrada, na pasta de spam ou em pastas filtradas específicas de cada fornecedor, como a pasta «Promoções» do Gmail. Recebe também os resultados de SPF, DKIM e DMARC da mensagem recebida, além de uma lista priorizada do que deve corrigir em primeiro lugar.
Erros comuns na autenticação de e-mail (e como corrigi-los)
A maioria das falhas na autenticação de e-mails é causada por pequenos erros de configuração que passam despercebidos até que os e-mails comecem a ir parar à pasta de spam, a falhar nas verificações de autenticação ou a ser rejeitados por completo.
Os erros abaixo são aqueles com que os remetentes se deparam com maior frequência. Compreender como ocorrem torna-os muito mais fáceis de identificar, resolver e prevenir antes que afetem a capacidade de entrega.
O registo SPF excede o limite de 10 consultas
O SPF permite um máximo de 10 consultas DNS. Cada plataforma de e-mail que autorizar através de uma instrução «include:» consome parte desse limite. À medida que mais ferramentas vão sendo adicionadas ao longo do tempo, é fácil ultrapassar o limite sem se aperceber.
Quando o limite é excedido, os fornecedores de caixas de correio deixam de poder avaliar na íntegra o registo SPF, o que faz com que as verificações SPF falhem, mesmo que o registo ainda exista no DNS.
Como resolver o problema:
- Faça uma auditoria a todas as plataformas que, atualmente, enviam e-mails em nome do seu domínio.
- Remova as instruções «include:» obsoletas ou que não sejam utilizadas.
- Consolidar os serviços de envio que se sobreponham, sempre que possível.
- Monitorizar o número de consultas sempre que for adicionada uma nova ferramenta de envio.
- Teste o SPF após cada alteração para confirmar se continua a ser válido.
Registos DKIM em falta para novas plataformas de envio
O DKIM é configurado separadamente para cada plataforma de envio. Um registo DKIM que funcione no Google Workspace não autentica automaticamente os e-mails enviados através do seu CRM, plataforma de contacto, sistema de faturação ou serviço de apoio ao cliente.
Isto acontece frequentemente quando uma nova ferramenta é ligada e começa a enviar mensagens imediatamente, mas a sua configuração DKIM nunca chega a ser concluída. Alguns e-mails passam na autenticação, enquanto outros falham, o que torna difícil identificar o problema.
Como resolver o problema:
- Crie um registo DKIM para cada plataforma de envio que utilize o seu domínio.
- Publique o seletor exato e a chave pública fornecidos por cada plataforma.
- Verifique o DKIM após a configuração, em vez de partir do princípio de que o registo está a funcionar.
- Mantenha um inventário de todos os sistemas de envio e dos respetivos seletores DKIM.
- Verifique novamente o DKIM sempre que um fornecedor alternar ou atualizar as suas chaves.
Publicar um registo DMARC sem verificar o alinhamento
O DMARC só é aprovado quando o SPF ou o DKIM correspondem ao domínio indicado no endereço «De:» visível.
Um registo pode existir no DNS e, mesmo assim, não cumprir os requisitos do DMARC se o domínio autenticado não corresponder ao domínio que os destinatários vêem.
Como resolver o problema:
- Verifique se o SPF corresponde ao domínio visível no campo «De:».
- Confirme se o DKIM assina utilizando o mesmo domínio indicado no cabeçalho «From:».
- Analise os relatórios DMARC para detetar falhas de alinhamento.
- Teste e-mails reais para verificar se o DMARC é aprovado na entrega.
- Resolva os problemas de alinhamento antes de avançar para além de p=none.
Passar para p=Rejeitar demasiado cedo
A aplicação do DMARC foi concebida para ser gradual. Passar diretamente para p=reject antes de identificar todas as fontes de envio legítimas pode bloquear e-mails reais da empresa.
O problema surge normalmente quando ferramentas esquecidas, sistemas de terceiros ou aplicações internas continuam a enviar e-mails que não foram devidamente autenticados.
Como resolver o problema:
- Comece com p=none e recolha os relatórios DMARC.
- Identifique todos os sistemas que enviam e-mails a partir do seu domínio.
- Resolva primeiro as falhas de autenticação e de alinhamento.
- Considere a opção p=quarentena ou uma implementação por fases antes de optar por p=rejeitar, se pretender uma transição mais segura.
- Só se deve aplicar a rejeição depois de um acompanhamento consistente ter confirmado que todo o correio legítimo é aprovado.
Basear-se apenas em verificações de DNS
Uma pesquisa de DNS apenas confirma que existe um registo. Não comprova que os fornecedores de caixas de correio autentiquem com sucesso os seus e-mails quando os recebem.
Isto cria uma falsa sensação de segurança. Tudo parece estar correto no DNS, enquanto as mensagens continuam a ser encaminhadas para a pasta de spam ou a falhar nas verificações de autenticação durante a entrega.
Como resolver o problema:
- Envie e-mails de teste para as caixas de entrada do Gmail e do Outlook.
- Verifique os resultados do SPF, do DKIM e do DMARC na mensagem recebida.
- Faça um teste após cada alteração no DNS ou na plataforma de envio.
- Acompanhe regularmente os resultados da autenticação, e não apenas durante a configuração.
- Utilize testes de colocação na caixa de entrada e de autenticação para validar o desempenho em condições reais.
Utilizar um subdomínio para abordagens não solicitadas
Muitos remetentes utilizam um subdomínio para campanhas de contacto não solicitado, partindo do princípio de que isso isola totalmente o risco. Embora a separação ajude do ponto de vista operacional, os fornecedores de serviços de e-mail podem, ainda assim, associar os subdomínios ao domínio principal.
Se as ações de divulgação gerarem reclamações ou um baixo nível de interação, os indicadores de reputação poderão afetar outros e-mails associados à marca.
Como resolver o problema:
- Utilize um domínio secundário distinto para a abordagem não solicitada, em vez do domínio principal da sua empresa. Mantenha-o simples: evite hífens, números e TLDs pouco comuns e autentique-o de forma independente antes de enviar.
- Autentique o domínio secundário de forma independente.
- Aqueça o domínio de divulgação antes de aumentar o volume.
- Mantenha separados o tráfego de marketing, o tráfego transacional e o tráfego de divulgação.
- Proteja o domínio principal da sua empresa contra riscos desnecessários para a sua reputação.
Perseguir listas negras em vez de recuperar a reputação
Uma inclusão numa lista negra pode parecer alarmante, mas a maioria das listas negras públicas tem pouca influência na colocação das mensagens na caixa de entrada do Gmail e do Outlook. Os fornecedores de serviços de e-mail modernos baseiam-se principalmente nos seus próprios sistemas de reputação, sinais de interação e dados relativos a reclamações.
Muitos remetentes passam dias a investigar as entradas nas listas negras, quando o verdadeiro problema é a má reputação do remetente.
Como resolver o problema:
- Verifique se a lista negra indicada é efetivamente utilizada pelos principais fornecedores de serviços de e-mail.
- Concentre-se, em primeiro lugar, nas taxas de reclamação, no envolvimento e na qualidade da lista.
- Melhorar as práticas de autenticação e de envio.
- Acompanhe a colocação na caixa de entrada, em vez de se limitar apenas ao estado na lista negra.
- Considere as verificações da lista negra como um sinal de diagnóstico, e não como a principal métrica de entregabilidade.
Autenticação de e-mail vs. colocação na caixa de entrada
Os fornecedores de serviços de correio eletrónico consideram cada vez mais a autenticação como um requisito básico, em vez de um indicador de confiança. À medida que os sistemas de filtragem se tornam mais sofisticados, a diferença entre o correio autenticado e o correio que chega à caixa de entrada continuará a aumentar. Os fornecedores estão a dar mais atenção do que nunca à reputação, ao envolvimento, à consistência e ao comportamento de envio.
É por isso que os remetentes mais bem-sucedidos encaram a autenticação de e-mail como parte de um processo contínuo de entregabilidade. Cada nova plataforma de envio, mudança de domínio, ferramenta de marketing ou campanha de divulgação cria mais uma oportunidade para que a autenticação se desalinhe sem que ninguém se aperceba.
O próximo passo consiste em verificar continuamente se continuam a funcionar em condições reais de receção e em detetar problemas antes que os fornecedores de caixas de correio o façam.
Cada nova ferramenta, domínio ou campanha representa uma oportunidade para que o SPF, o DKIM ou o DMARC fiquem discretamente desalinhados. Faça um teste gratuito de entregabilidade do MailReach para ver onde os seus e-mails estão a chegar atualmente e combine-o com email warmup para construir a reputação de remetente que a autenticação, por si só, não consegue garantir.
Perguntas frequentes
Quais são os três principais métodos de autenticação de e-mail?
SPF, DKIM e DMARC. O SPF indica quais os servidores que podem enviar mensagens em nome do seu domínio, o DKIM adiciona uma assinatura que comprova que a mensagem não foi alterada e o DMARC associa ambos ao domínio visível no campo «De:» e indica aos destinatários o que devem fazer em caso de falha.
Preciso do DMARC se só enviar e-mails a partir do Google Workspace?
Sim. É recomendado para qualquer remetente e obrigatório em caso de envios em grande volume. O Google Workspace é a plataforma a partir da qual se efetuam os envios; a publicação de uma política DMARC é da sua responsabilidade, não sendo algo que o Workspace trate automaticamente.
Qual é a diferença entre SPF, DKIM e DMARC?
O SPF autoriza os servidores de envio. O DKIM assina a mensagem para que os destinatários possam verificar que esta não foi alterada. O DMARC define a política e exige que haja correspondência entre o que foi enviado e o domínio «De:» que o destinatário vê.
Durante quanto tempo devo permanecer em p=none antes de passar para p=reject?
Mantenha o valor p=none até que os relatórios DMARC mostrem que todos os sistemas legítimos que enviam mensagens a partir do seu domínio estão registados. Adotar esta medida prematuramente pode levar ao bloqueio de e-mails reais da empresa.
A autenticação de e-mail melhora a capacidade de entrega?
É obrigatório para competir e não é possível chegar à caixa de entrada sem isso, mas, por si só, não melhora a colocação na caixa de entrada. São a reputação e o conteúdo que fazem isso. A autenticação abre a porta; a reputação e o conteúdo garantem a entrada na caixa de entrada.