SPF, DKIM e DMARC: rejeição precoce pode bloquear e-mails

Para autenticar um domínio usado no Google Workspace sem bloquear e-mails legítimos, identifique todos os serviços que enviam por ele, configure SPF e DKIM e comece o DMARC com p=none. Avance para rejeição somente depois de observar os relatórios e confirmar que cada fluxo autorizado passa na autenticação com o domínio correto.

Uma plataforma de cobrança ou um formulário do site pode enviar mensagens com o endereço da empresa sem usar os servidores do Google. Se esse serviço falhar no DMARC, uma política p=reject pode levar o servidor destinatário a recusar mensagens legítimas. O período de observação serve para localizar e corrigir esse fluxo antes que a política passe a interferir na entrega.

Faça o inventário de quem envia pelo domínio

Registro SPF do Google Workspace ao lado de um remetente terceirizado que ainda precisa ser incluído no inventário.

Comece pelas contas do Gmail no Workspace e inclua aplicações de notificações, formulários, sistemas de vendas, plataformas de marketing, servidores próprios e gateways de saída. Para cada serviço, anote o domínio mostrado no campo De:, o domínio usado no remetente do envelope, quem administra a configuração e se o fornecedor oferece SPF, assinatura DKIM ou ambos. Registre também envios esporádicos, como cobranças e comunicados programados.

Essa lista precisa distinguir o domínio principal dos subdomínios usados para envio. Uma aplicação pode assinar mensagens por um subdomínio ou usar um endereço de devolução diferente daquele exibido ao destinatário. Essa diferença importa para o alinhamento exigido pelo DMARC; uma mensagem pode passar em uma verificação técnica e ainda falhar na política do domínio visível.

Antes de alterar o DNS, consulte os registros existentes e as instruções atuais de cada fornecedor. Copiar um valor preparado apenas para o Workspace deixa de fora qualquer outro serviço que envie em nome da organização. O inventário também dá um responsável a cada falha encontrada posteriormente nos relatórios.

Configure SPF e DKIM para os fluxos identificados

A orientação do Google para SPF manda incluir os servidores que enviam pelo domínio e apresenta v=spf1 include:_spf.google.com ~all para o caso em que somente o Google Workspace faz esses envios. O registro é publicado como TXT no DNS do domínio, não no Admin Console. Se houver terceiros, adapte o valor com os mecanismos fornecidos por eles e atualize o registro existente.

Verifique o nome em que o provedor DNS publica o TXT, especialmente se o envio também usa subdomínios. Depois, consulte o registro publicamente disponível e confirme se ele contém os remetentes previstos. O mecanismo ~all do exemplo não transforma uma plataforma externa em remetente autorizado: ela precisa constar da configuração apropriada.

Para o DKIM do Workspace, a instrução do Google para DKIM orienta gerar o registro em Apps, Google Workspace, Gmail, Autenticar e-mails, publicar a chave pública no DNS e então selecionar Iniciar autenticação. O nome TXT reúne um seletor e ._domainkey; google._domainkey é um exemplo, mas o valor da chave deve ser copiado do domínio configurado. Se já houver DKIM ativo, confira a configuração antes de substituí-la.

Envie uma mensagem real a uma conta destinatária e abra Mostrar original no Gmail para conferir Authentication-Results e o resultado DKIM. Repita a verificação com cada serviço externo, conforme os recursos oferecidos pelo fornecedor. Uma assinatura válida nas mensagens dos funcionários não demonstra que as mensagens de uma plataforma terceirizada também estejam assinadas.

Publique o DMARC em modo de observação

A documentação do Google para DMARC recomenda aguardar 48 horas após configurar SPF e DKIM e começar com p=none, antes de avançar gradualmente para quarentena ou rejeição. O DMARC também é um registro TXT no DNS. Para o domínio hipotético example.com, um valor inicial é v=DMARC1; p=none; rua=mailto:[email protected], publicado no nome _dmarc correspondente ao domínio.

Troque o endereço do exemplo por uma caixa ou serviço preparado para receber relatórios agregados. Confira como o painel DNS completa o nome do domínio: alguns provedores acrescentam essa parte automaticamente. Publicar o TXT no nome errado impede que a política seja encontrada, mesmo quando seu conteúdo parece correto.

Com p=none, o domínio solicita relatórios sem pedir quarentena ou rejeição por falha no DMARC. Isso não garante chegada à caixa de entrada, pois o destinatário pode aplicar outros filtros. O benefício operacional é observar a autenticação dos remetentes conhecidos enquanto ainda é possível corrigir as falhas sem impor a ação mais restritiva dessa política.

Interprete falhas de autenticação e alinhamento

Domínio no campo De: e domínio da assinatura DKIM não alinhados em uma mensagem corporativa.

O DMARC exige que pelo menos um método passe e esteja alinhado ao domínio do campo De:. Para SPF, a comparação envolve o domínio do remetente do envelope; para DKIM, o domínio da assinatura indicado por d=. Portanto, um serviço pode apresentar SPF aprovado usando seu próprio domínio e ainda falhar no DMARC da empresa se não houver uma assinatura DKIM válida e alinhada como alternativa.

Nos relatórios agregados, agrupe os resultados por origem de envio e compare cada padrão com o inventário. Uma falha de um remetente conhecido pede conferência do domínio usado no envelope, da assinatura DKIM e das opções de domínio personalizado oferecidas pelo fornecedor. Se o serviço assina apenas com o domínio dele, peça uma configuração de DKIM para o domínio da empresa ou ajuste a forma de envio disponível.

Resultados inesperados não identificam, por si só, um serviço autorizado nem provam abuso. Cruze a origem indicada no relatório com aplicações, fornecedores e responsáveis internos; mensagens ocasionais podem não ter aparecido no período observado. Também confira uma mensagem recebida de cada fluxo importante: o relatório mostra o padrão de autenticação, enquanto a mensagem permite examinar seus cabeçalhos e confirmar o domínio efetivamente usado.

Avance para quarentena e rejeição por critérios verificáveis

Considere p=quarantine quando os remetentes previstos já aparecerem na observação e as falhas legítimas de DMARC tiverem sido corrigidas. A tag pct permite aplicar a política a uma parcela das mensagens que falham; como exemplo hipotético de implantação limitada, o registro poderia usar v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]. Observe os relatórios e confirme as entregas importantes após cada mudança antes de ampliar a parcela.

Adote p=reject quando cada fluxo legítimo tiver SPF ou DKIM aprovado e alinhado, os envios menos frequentes tiverem sido contemplados e a fase de quarentena não mostrar interrupções nesses fluxos. O critério não é apenas haver um registro SPF ou uma chave DKIM publicados: a autenticação precisa funcionar nas mensagens recebidas e corresponder ao domínio que o destinatário vê.

Ao adicionar um novo fornecedor, inclua-o no inventário e valide sua autenticação antes de deixá-lo enviar em produção sob a política restritiva. Se um serviço legítimo começar a falhar, corrija o domínio de envio ou a assinatura e acompanhe o resultado nos relatórios. Enquanto a falha persistir, mantenha uma política compatível com a continuidade daquele envio.