Passar no DMARC não garante a colocação na caixa de entrada.

Essa é uma das realidades mais importantes na entrega de e-mail moderna.

O DMARC informa a um servidor de e-mail receptor se uma mensagem está alinhada com a política de autenticação publicada do remetente. Ele ajuda os receptores a identificar se uma mensagem que afirma vir de um domínio está devidamente autenticada por meio de SPF ou DKIM.

Mas o Gmail e a Microsoft não tomam decisões de entrega baseadas apenas no DMARC.

Eles também avaliam reputação do remetente, comportamento do destinatário, taxas de reclamação, sinais de conteúdo, indicadores de phishing, contexto de encaminhamento, regras de nível de tenant e sistemas internos anti-abuso.

Isso significa que duas mensagens podem passar no DMARC e ainda assim serem tratadas de forma diferente pelo Gmail e pelo Outlook. Uma pode chegar na caixa de entrada. Outra pode ser filtrada, limitada por taxa, colocada no spam ou rejeitada com base em outros sinais.

Para organizações que enviam para os ecossistemas do Google e da Microsoft, a lição é clara:

DMARC é necessário, mas não é toda a história de entregabilidade.

I. Por Que o Gmail e o Outlook Tratam a Autenticação de Forma Diferente

Gmail e Microsoft suportam SPF, DKIM e DMARC.

Ambos esperam que remetentes sérios autentiquem seus e-mails.

Ambos usam autenticação como parte de uma prevenção de abuso mais ampla.

Mas seus ecossistemas, ferramentas, políticas e camadas de filtragem não são idênticos.

Os requisitos públicos de remetente do Google são mais prescritivos para remetentes em massa. O Google exige que todos os remetentes autentiquem e-mails com SPF ou DKIM, e remetentes em massa devem usar SPF, DKIM e DMARC. O Google também declara que o DMARC passa quando SPF ou DKIM autentica e alinha com o domínio From visível.

A Microsoft também avançou em direção a requisitos mais rigorosos para remetentes. Em 2025, a Microsoft anunciou novos requisitos para remetentes de alto volume para endereços Outlook.com, Hotmail e Live.com, incluindo SPF, DKIM e DMARC. O Microsoft 365 também usa o que chama de autenticação implícita de e-mail, onde SPF, DKIM e DMARC tradicionais são combinados com sinais como reputação do remetente, histórico do remetente, histórico do destinatário, análise comportamental e outras técnicas.

A diferença prática não é que um provedor “se importa” com DMARC e o outro não.

A diferença é operacional.

A orientação pública do Gmail dá aos remetentes uma linha de base mais clara para conformidade de e-mail em massa. O ambiente de filtragem da Microsoft frequentemente inclui mais variação específica de tenant porque Exchange Online Protection, Defender para Office 365, políticas de caixa de correio, regras de permissão/bloqueio e configurações empresariais podem influenciar como uma mensagem é tratada.

Para remetentes, isso cria uma realidade simples:

Você precisa de autenticação que satisfaça ambos os provedores, e reputação forte o suficiente para sobreviver à filtragem além da autenticação.

II. Revisão do DMARC: O Que Realmente Precisa Passar

DMARC é frequentemente mal compreendido.

Uma mensagem não passa no DMARC apenas porque o SPF passa.

Uma mensagem não passa no DMARC apenas porque o DKIM passa.

Uma mensagem passa no DMARC apenas quando pelo menos um identificador autenticado se alinha com o domínio From visível.

Isso significa:

• SPF deve passar e o domínio autenticado pelo SPF deve alinhar com o domínio From visível.
• Ou DKIM deve passar e o domínio de assinatura DKIM deve alinhar com o domínio From visível.

Isso é especialmente importante para plataformas de terceiros.

Uma ferramenta de marketing, plataforma de suporte, CRM, sistema de cobrança ou serviço de e-mail transacional pode passar no SPF ou DKIM usando seu próprio domínio. Isso é útil para o fornecedor, mas pode não ajudar seu resultado DMARC a menos que o domínio autenticado alinhe com seu domínio From visível.

O usuário vê seu domínio.

DMARC verifica se o resultado da autenticação se conecta de volta a esse domínio.

III. O Que o Gmail Exige Que os Remetentes Acertem

As diretrizes de remetente do Google tornam a autenticação um requisito básico.

Para remetentes, isso significa que o Gmail espera:

• SPF ou DKIM para todos os remetentes.
• SPF, DKIM e DMARC para remetentes em massa.
• Alinhamento DMARC com o domínio From visível.
• Baixas taxas de reclamação de spam.
• Tratamento adequado de assinaturas e requisitos de cancelamento de inscrição para e-mail de marketing.

O Google também fornece visibilidade por meio do Postmaster Tools. Seu painel de Autenticação mostra a porcentagem de e-mails que passam SPF, DKIM e DMARC para mensagens usando o domínio From do remetente. O Google observa que os remetentes normalmente alcançam altas taxas de sucesso em DKIM e DMARC quando esses métodos são configurados corretamente, enquanto o sucesso do SPF pode ser menor quando remetentes de terceiros estão envolvidos.

Isso importa porque o Gmail fornece aos remetentes uma forma mais clara de observar a saúde da autenticação.

No entanto, o Gmail Postmaster Tools não explica todas as decisões individuais de filtragem. Uma mensagem pode passar na autenticação e ainda ser filtrada se outros sinais indicarem risco.

Problemas comuns de entrega no Gmail incluem:

• Má reputação de domínio ou IP.
• Altas taxas de reclamação de spam.
• Picos repentinos de volume de envio.
• Conteúdo suspeito ou padrões semelhantes a phishing.
• Remetentes de terceiros mal configurados.
• Falhas de DKIM após mudanças de chave.
• Falhas de alinhamento SPF causadas por domínios Return-Path de terceiros.

Para o Gmail, autenticação é a linha de base. Ela coloca você na conversa de confiança. Não garante colocação na caixa de entrada.

IV. O Que a Microsoft Exige Que os Remetentes Acertem

O ecossistema da Microsoft inclui Outlook.com, Hotmail, Live.com, Microsoft 365, Exchange Online Protection e Microsoft Defender para Office 365.

Isso cria mais variação em como as mensagens são avaliadas.

A Microsoft anunciou publicamente requisitos de remetentes de alto volume para endereços Outlook.com, Hotmail e Live.com que incluem SPF, DKIM e DMARC. Para o Microsoft 365, a autenticação de entrada é avaliada por meio de SPF, DKIM, DMARC e sinais adicionais de autenticação implícita, como reputação do remetente, histórico do remetente, histórico do destinatário, análise comportamental e outras técnicas avançadas.

Isso significa que a autenticação importa, mas faz parte de um sistema de decisão mais amplo.

Uma mensagem enviada para um ambiente Microsoft pode ser afetada por:

• Resultados de SPF, DKIM e DMARC.
• Reputação do remetente.
• Histórico do destinatário ou tenant.
• Políticas do Defender para Office 365.
• Regras de transporte do Exchange.
• Listas de permissão ou bloqueio específicas do tenant.
• Inteligência de falsificação.
• Relatórios de usuários.
• Análise de conteúdo e anexos.
• Detecção de URL e phishing.

É por isso que os remetentes às vezes veem diferenças entre tenants da Microsoft.

Uma mensagem pode ser aceita por uma organização e filtrada por outra porque o tenant receptor tem diferentes políticas, configurações de segurança, listas de permissão ou relacionamento histórico com o remetente.

Isso não significa que a Microsoft ignora DMARC.

Significa que o ambiente de filtragem da Microsoft tem mais camadas do que apenas DMARC.

V. Gmail vs Outlook: Diferenças Práticas Para Remetentes

A comparação mais segura não é “qual provedor aplica DMARC mais rigorosamente”.

A melhor comparação é como os remetentes experimentam os dois ecossistemas.

A conclusão operacional é direta:

Se seu e-mail autentica limpo, alinha adequadamente, mantém baixas reclamações e usa padrões de envio estáveis, você está melhor posicionado no Gmail e na Microsoft.

Se seu e-mail falha no alinhamento, usa remetentes de terceiros mal configurados ou tem reputação fraca, problemas de autenticação podem aparecer de forma diferente nos dois ecossistemas.

VI. Remetentes de Terceiros São o Ponto de Falha Comum

A maioria das organizações não envia todos os e-mails de um sistema.

Eles usam:

• Plataformas de automação de marketing.
• Sistemas CRM.
• Ferramentas de helpdesk.
• Plataformas de tickets.
• Serviços de e-mail transacional.
• Sistemas de cobrança.
• Plataformas de eventos.
• Ferramentas de RH.
• Plataformas regionais ou de unidades de negócios.

Cada remetente deve ser autenticado e alinhado.

É aqui que os programas DMARC frequentemente quebram.

Uma plataforma de terceiros pode estar incluída no SPF, mas o SPF pode não alinhar porque o domínio Return-Path pertence ao fornecedor.

Outra plataforma pode assinar DKIM a mensagem, mas o domínio DKIM d= pode pertencer ao fornecedor em vez de seu domínio.

Em ambos os casos, a mensagem pode ter autenticação, mas ainda falhar no alinhamento DMARC.

Isso pode afetar Gmail e Microsoft de forma diferente porque cada provedor combina autenticação com outros sinais de filtragem. Mas a correção é a mesma:

Configure cada remetente de terceiros para passar SPF alinhado ou DKIM alinhado.

Em muitos casos, DKIM alinhado é o caminho mais confiável porque SPF pode quebrar em cenários de encaminhamento e infraestrutura de envio compartilhada.

VII. Quando o DMARC Passa Mas a Entrega Ainda Falha

Passar no DMARC não é o mesmo que colocação na caixa de entrada.

Uma mensagem pode passar no DMARC e ainda ser filtrada devido a:

• Altas taxas de reclamação.
• Baixo engajamento.
• Má reputação de domínio.
• Má reputação de IP.
• Conteúdo suspeito.
• Indicadores de phishing.
• URLs inseguras.
• Picos repentinos de volume.
• Má higiene de lista.
• Filtragem de nível de destinatário.
• Regras de nível de tenant.

Isso é verdade para Gmail e Microsoft.

Autenticação prova que a mensagem está autorizada a usar o domínio.

Não prova que a mensagem é desejada, segura ou de alta qualidade.

Essa distinção importa.

Um remetente pode ter SPF, DKIM e DMARC perfeitos e ainda ter desempenho ruim se destinatários marcarem mensagens como spam, ignorarem o e-mail ou se o conteúdo acionar sistemas de filtragem.

VIII. Quando o DMARC Falha Mas o E-mail Ainda Parece Ser Entregue

O reverso também pode acontecer.

Uma mensagem pode falhar no DMARC e ainda parecer ser entregue.

Possíveis razões incluem:

• O provedor receptor aplica contexto adicional.
• A mensagem é encaminhada e avaliada com sinais de autenticação adicionais.
• O destinatário ou tenant colocou o remetente em lista de permissão.
• A mensagem é colocada no spam em vez de rejeitada.
• O receptor trata a política publicada do domínio de forma diferente em cenários específicos.
• A mensagem é julgada de baixo risco por outros sistemas de filtragem.

Isso não significa que DMARC é irrelevante.

Significa que DMARC é um sinal em uma decisão maior do lado receptor.

Remetentes não devem usar entrega ocasional de e-mail com falha como prova de que a autenticação está saudável.

Se relatórios DMARC mostram falhas, essas falhas devem ser investigadas mesmo quando usuários não estão relatando problemas de entrega.

IX. Modos de Falha Silenciosa Para Observar

Os problemas mais perigosos são aqueles que não criam tickets de suporte imediatos.

1. Deriva de Autenticação

Um fornecedor muda a infraestrutura. Um seletor DKIM é rotacionado incorretamente. Inclusões SPF mudam. Uma equipe de negócios adiciona uma nova ferramenta de envio.

O e-mail pode continuar a ser entregue por um tempo, mas relatórios DMARC começam a mostrar falhas.

Sem monitoramento, o problema permanece oculto até que a entregabilidade caia ou o risco de falsificação aumente.

2. Mascaramento de Reputação

Um remetente com forte reputação pode não ver impacto imediato na entrega de alguns problemas de autenticação.

Isso pode criar falsa confiança.

A lacuna de autenticação ainda existe e pode se tornar visível mais tarde quando a reputação mudar, o volume aumentar ou os limites de filtragem do provedor mudarem.

3. Diferenças de Entrega Específicas de Tenant

Ambientes Microsoft podem variar por configuração de tenant.

Um cliente pode receber a mensagem. Outro pode colocá-la em quarentena. Outro pode bloqueá-la por causa de regras locais ou política do Defender.

Isso torna a solução de problemas mais difícil porque apenas os resultados de autenticação não explicam todos os resultados de entrega.

4. Encaminhamento e Listas de E-mail

Encaminhamento pode quebrar SPF porque o servidor de encaminhamento não está autorizado no registro SPF do remetente original.

DKIM pode sobreviver ao encaminhamento se a mensagem não for modificada. Se DKIM também falhar, DMARC pode falhar.

ARC pode ajudar receptores a avaliar o contexto de e-mail encaminhado, mas remetentes ainda devem buscar forte alinhamento DKIM para reduzir dependência do comportamento de encaminhamento.

X. Orientação de Implementação Para Gmail e Microsoft

Um programa de autenticação forte não deve ser projetado apenas para um provedor.

Deve funcionar em ambos os ecossistemas.

1. Publique DMARC e Monitore Relatórios

Comece com monitoramento para identificar remetentes legítimos e falhas.

Um registro estático básico pode se parecer com:

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

Uma abordagem melhor é usar um registro de monitoramento DMARC gerenciado através do Skysnag para que relatórios sejam coletados, analisados e transformados em inteligência acionável de remetente.

Inicie o monitoramento DMARC com Skysnag e obtenha seu registro DMARC gratuito.

2. Autentique Todos os Remetentes Legítimos

Para cada remetente, confirme:

• SPF está autorizado onde necessário.
• DKIM está habilitado.
• Pelo menos um método alinha com o domínio From visível.
• O remetente está documentado.
• O proprietário do negócio é conhecido.
• A autenticação é monitorada ao longo do tempo.

3. Prefira DKIM Alinhado Para Plataformas de Terceiros

Quando possível, configure plataformas de terceiros para assinar DKIM usando seu domínio.

Isso reduz a dependência do alinhamento SPF, que pode ser frágil quando o e-mail passa por infraestrutura compartilhada ou caminhos de encaminhamento.

4. Separe Fluxos de E-mail

Use domínios ou subdomínios apropriados para diferentes categorias de e-mail.

Por exemplo:

• E-mail transacional.
• E-mail de marketing.
• E-mail de suporte.
• Notificações de segurança.
• Sistemas internos.

Isso facilita o gerenciamento de autenticação e a proteção de reputação.

5. Avance Para Aplicação Com Cuidado

Não fique em p=none para sempre.

Após descoberta e remediação, mova domínios maduros para quarentena e depois rejeição.

Uma abordagem em etapas deve ser baseada em:

• Prontidão do domínio.
• Maturidade de subdomínio.
• Estabilidade de grupo de remetentes.
• Criticidade de negócios.
• Taxas de aprovação de autenticação.
• Status de remediação.

Evite implantação baseada em porcentagem como estratégia principal. Programas DMARC conscientes atuais devem fazer implantação em etapas por domínio, subdomínio, grupo de remetentes e unidade de negócios em vez de confiar em pct.

6. Monitore Reputação Separadamente da Autenticação

Relatórios DMARC mostram resultados de autenticação.

Eles não explicam completamente a colocação na caixa de entrada.

Use ferramentas de provedor e métricas operacionais onde disponíveis, incluindo:

• Google Postmaster Tools.
• Rastreamento de mensagens do Microsoft 365 e relatórios de segurança quando aplicável.
• Dados de bounce.
• Tendências de reclamação.
• Métricas de engajamento.
• Monitoramento de lista de bloqueio e reputação.
• Testes de entrega em provedores de caixa de correio.

Autenticação e reputação devem ser monitoradas juntas.

XI. Implicações de Conformidade

Autenticação de e-mail suporta muitos programas de conformidade e governança, mas deve ser descrita com precisão.

DMARC pode apoiar objetivos de anti-phishing, proteção de domínio, supervisão de fornecedores e integridade de comunicação. Também pode fornecer evidências de que a organização monitora envios não autorizados e falhas de autenticação.

No entanto, DMARC não satisfaz automaticamente GDPR, PCI DSS, HIPAA, SOC 2, NIS2 ou qualquer outra estrutura por si só.

Melhor enquadramento:

• DMARC suporta controles de anti-phishing e integridade de comunicação.
• SPF e DKIM suportam autenticação de remetente.
• Relatórios DMARC suportam monitoramento e coleta de evidências.
• Aplicação suporta proteção contra falsificação de domínio exato.
• MTA-STS e TLS-RPT suportam visibilidade de transporte seguro de e-mail.

Skysnag Comply ajuda organizações a manter visibilidade, relatórios e evidências sobre postura de autenticação de e-mail em fontes de envio e domínios.

XII. Modelo Operacional Prático

Para organizações que enviam para Gmail e Microsoft, o modelo operacional deve ser simples:

1. Conheça todos os remetentes.
2. Autentique todos os remetentes.
3. Alinhe pelo menos um método de autenticação com o domínio From visível.
4. Monitore relatórios DMARC continuamente.
5. Rastreie reputação de provedor e sinais de reclamação.
6. Separe fluxos de e-mail por função e risco.
7. Avance de monitoramento para aplicação quando pronto.
8. Trate problemas de entrega como problemas de autenticação e reputação.
9. Revise remetentes de terceiros regularmente.
10. Mantenha documentação para auditoria e governança.

Este modelo funciona porque não depende de adivinhar exatamente como Gmail ou Microsoft pesam cada sinal internamente.

Ele se concentra nos controles que os remetentes podem realmente gerenciar.

XIII. Principais Conclusões

Gmail e Microsoft exigem forte autenticação de e-mail para remetentes sérios, especialmente remetentes de alto volume.

Os requisitos públicos de remetente do Gmail são mais prescritivos para remetentes em massa, enquanto a Microsoft combina autenticação tradicional com sinais de autenticação implícita, como reputação, histórico de remetente, histórico de destinatário, análise comportamental e controles específicos de tenant.

Passar no DMARC não garante colocação na caixa de entrada.

Falhar no DMARC nem sempre significa rejeição imediata.

Autenticação deve ser gerenciada junto com reputação, taxas de reclamação, qualidade de conteúdo, padrões de envio e visibilidade específica de provedor.

O maior risco operacional é o desalinhamento de remetentes de terceiros. Cada plataforma enviando em nome do domínio deve ser configurada para passar SPF alinhado ou DKIM alinhado.

A estratégia mais segura não é otimizar para Gmail ou Microsoft separadamente. É construir um programa disciplinado de autenticação que funcione em ambos.

Inicie o monitoramento DMARC com Skysnag e obtenha seu registro DMARC gratuito.