Google melhora os relatórios DMARC: o que muda para sua entregabilidade

Author

Fabrício Yutaka Fujikawa
25 de setembro de 2025

Olá,

O Google passou a incluir motivos de falha diretamente nos relatórios agregados de DMARC (XML). Agora, além de saber se SPF/DKIM/alinhamento falharam, você recebe o código SMTP que explica o porquê: por exemplo, 550-5.7.27 (SPF) ou 421-4.7.29 (sem TLS). Isso reduz o “achismo” e acelera o diagnóstico de problemas que derrubam suas taxas de entrega.

O que mudou nos relatórios DMARC do Google?

Nos elementos <policy_evaluated><reason>, o Google passou a preencher o campo comment com mensagens como “Sender requirement failed: 550-5.7.1”. Entre os códigos já observados:

  • 421-4.7.27: rate limit por falha de SPF

  • 421-4.7.30: rate limit por falha de DKIM

  • 421-4.7.32: rate limit por falta de alinhamento (SPF/DKIM ≠ From)

  • 550-5.7.25: PTR ausente ou DNS fwd/rev inconsistentes

  • 550-5.7.27: bloqueio por falha de SPF

  • 550-5.7.30: bloqueio por falha de DKIM

  • 550-5.7.1: bloqueio por outros motivos (spam, reputação, RFC)

Por que isso importa?

Para quem envia em volume e precisa cumprir as Diretrizes para remetentes de e-mail do Google, a visibilidade direta, em um único lugar, elimina a necessidade de caçar evidências em NDRs e logs de SMTP espalhados. Você passa a saber o que falhou e onde atuar: DNS, criptografia (TLS), autenticação, alinhamento ou conformidade de cabeçalhos.

Ações recomendadas

  1. Habilite/valide RUA: use o parâmetro rua= no registro DMARC para receber os relatórios atualizados.

  2. Classifique os códigos: dê preferência a plataformas DMARC que classifiquem os códigos para fácil visualização.

  3. Corrija autenticação por prioridade:

    • 550-5.7.27 → revisar SPF (falta de include, extrapolação dos 10 lookups)

    • 550-5.7.30 → revisar DKIM (selector, chave pública)

    • 421-4.7.32 → garantir pelo menos um alinhamento (domínio do From alinhado com o d= do DKIM OU o domínio do SPF).

  4. Conserte DNS reverso: se aparecer 5.7.25, alinhe PTR e A (forward/reverse).

  5. Exija TLS: 4.7.29 indica falta de criptografia; force TLS na saída.

  6. Audite todos os remetentes terceiros: CRMs, ESPs e ferramentas de suporte precisam assinar DKIM com seu domínio e estar no SPF sempre que possível.

  7. Monitore conformidade contínua: com o aumento das exigências, é necessário cada vez mais ter um monitoramento dos logs DMARC; apenas estabelecer uma política no DNS não é mais suficiente. Plataformas como Postmark e PowerDMARC oferecem planos gratuitos ou opções de entrada bem acessíveis.

Até a próxima,
Fabrício

PS: Recentemente, a Valimail foi adquirida pela Digicert, o que só reforça como o mercado de segurança e entregabilidade de email ganha cada vez mais relevância :)