Sob RFC 9989 §5.4, a DMARC pass não garante a colocação na caixa de entrada. Ele estabelece um resultado de autenticação de domínio alinhado para uma mensagem. Um serviço receptor ainda pode rejeitar a mensagem por outro motivo, aceitá-la como spam, colocá-la na caixa de entrada ou aplicar posteriormente um tratamento específico do usuário.
Este limite é importante porque o diagnóstico errado cria a mudança errada. DNS não pode reparar consentimentos inadequados, reclamações sustentadas ou conteúdo indesejado. Por outro lado, o trabalho de reputação não corrige um caminho de autenticação desalinhado.
Separe as etapas da entrega
Use quatro medidas distintas:
- Etapa: Autenticação; Pergunta: Fez SPF ou DKIM passou e pelo menos uma identidade passageira se alinhou com De?
- Etapa: Aceitação; Pergunta: O servidor receptor aceitou a mensagem durante SMTP ?
- Etapa: Colocação; Pergunta: Após a aceitação, onde o receptor colocou ou expôs a mensagem?
- Etapa: Engajamento; Pergunta: O que o destinatário fez e quão confiável é essa medição?
A conclusão positiva SMTP após o fim dos dados ser especificado em RFC 5321 §4.2.5. Uma mensagem pode passar na autenticação e falhar na aceitação. Pode ser aceito e colocado em spam. Ele pode chegar à caixa de entrada e não receber nenhum envolvimento útil. Não descreva todos os quatro resultados como capacidade de entrega.
Leia uma tabela de diagnóstico fictícia
Os seguintes casos são sintéticos. Eles ilustram como escolher a próxima investigação sem reivindicar o desempenho observado.
- Observação: DMARC ; Caso A: Aprovado; Caso B: Aprovado; Caso C: Falha
- Observação: SMTP ; Caso A: Aceito; Caso B: Aceito; Caso C: Rejeitado com resposta relacionada à autenticação
- Observação: Colocação; Caso A: Spam; Caso B: Caixa de entrada; Caso C: Nenhuma cópia entregue disponível
- Observação: Reclamações ou sinais de destinatário; Caso A: Reclamações elevadas; Caso B: Normal para a coorte definida; Caso C: Não aplicável a mensagem rejeitada
- Observação: Próximo foco; Caso A: Consentimento, expectativas, reputação, conteúdo e padrões de envio; Caso B: Continuar monitorando tráfego comparável; Caso C: Cadeia de identidade, assinatura, caminho SPF e resposta do provedor
No Caso A, alterar DMARC de nenhum para rejeitar não resolve o motivo pelo qual as mensagens autenticadas são indesejadas. Investigue a origem, a supressão, a frequência, o conteúdo e o feedback do fornecedor da lista. No Caso C, o teste da caixa de entrada não pode começar até que a rejeição relacionada à autenticação seja compreendida.
Use a autenticação como um pré-requisito, não um atalho de reputação
Os provedores de caixas de correio publicam requisitos e recomendações para remetentes, como Diretrizes do Google para destinatários pessoais Gmail. Esses requisitos podem incluir SPF , DKIM , DMARC , DNS válido, práticas de transporte, controles de reclamações e fácil cancelamento de assinatura para tráfego aplicável. Atender a um requisito não dispensa os outros.
A autenticação é valiosa porque cria uma identidade de domínio estável e ajuda os destinatários a atribuir mensagens. Não compra reputação, não prova o consentimento do destinatário nem garante tratamento favorável. As decisões de reputação e classificação são específicas do receptor e podem variar de acordo com o fluxo de tráfego, destinatário e horário.
Não infira a causa de uma alteração simultânea DNS e de posicionamento. Um programa de envio pode alterar volume, audiência, conteúdo e infraestrutura ao mesmo tempo. Registre as intervenções e compare coortes iguais antes de tirar uma conclusão.
Diagnosticar com evidências do receptor relevante
Comece com a resposta SMTP real e os resultados de autenticação confiável dentro do limite especificado por RFC 8601 §7.1. Se a mensagem foi rejeitada, o código e o texto que a acompanha podem identificar uma categoria, mas o código por si só não é um diagnóstico completo. A documentação do provedor e o envio de logs são necessários para interpretá-lo.
Se a mensagem for aceita, use a telemetria disponível do provedor, testes iniciais com limitações declaradas, relatórios de destinatários e dados de campanha controlados. Uma caixa de correio de teste é uma evidência sobre essa caixa de correio e mensagem, e não uma previsão universal para todos os destinatários.
Para autenticação, registre From, a identidade SPF avaliada, cada domínio DKIM d=, alinhamento e a política aplicável. Para a integridade do programa, registre fluxo de tráfego, volume, informações de reclamação, comportamento de supressão, origem da lista, alterações de conteúdo e tempo.
Trate as métricas de engajamento com cuidado
A taxa de abertura não é um proxy independente confiável para posicionamento na caixa de entrada ou atenção humana. Proteção de privacidade de e-mail da Apple baixa conteúdo remoto em segundo plano, independentemente do envolvimento. Orientação de rastreamento aberto do Mailchimp também documenta imagens de rastreamento bloqueadas e limitações de formato de cliente. Os cliques também podem incluir verificação de segurança automatizada, conforme descrito em Orientação sobre atividades de bot do Mailchimp.
Defina a população e o método de medição. Combine respostas de entrega, reclamações, comportamento de cancelamento de assinatura, evidências de fornecedores e resultados de negócios. Evite alegar melhoria de uma métrica sem uma linha de base comparável e uma explicação de mudanças confusas.
Evite alterações DNS direcionadas ao problema errado
Não adicione outro SPF incluído porque uma campanha autenticada acaba sendo spam. Não enfraqueça o alinhamento para perseguir a colocação. Não publique duplicatas Registros SPF. Não prossiga para rejeitar apenas porque uma mensagem de teste chegou à caixa de entrada.
As alterações DNS devem resolver um problema comprovado de identidade ou política. Mudanças nas práticas de envio devem resolver problemas de consentimento, frequência, conteúdo, segmentação ou reputação. Às vezes, ambos os fluxos de trabalho são necessários, mas devem manter proprietários e evidências separados.
Crie um registro de diagnóstico conjunto
Um registro de caso útil contém:
- o remetente exato, do domínio e do fluxo de tráfego;
- uma mensagem representativa e resultados de autenticação confiáveis;
- Resposta SMTP e carimbo de data/hora;
- posicionamento observado com método e limitações;
- reclamação, supressão e evidências de destinatário disponíveis para essa coorte;
- mudanças técnicas e programáticas recentes;
- uma hipótese, proprietário, intervenção e data de revisão.
Este formato resolve a questão " DMARC corrigiu a capacidade de entrega?" em questões testáveis. A autenticação melhorou? A aceitação mudou? O posicionamento mudou para correspondência comparável? A resposta do destinatário melhorou sem mudar o público?
Para a evidência de identidade, use o guia da cadeia de identidade de e-mail. Para obter uma linha de base de monitoramento, continue com o Guia de política de monitoramento DMARC.
Mantenha a conclusão dentro das evidências
Para o Caso A, retenha a observação autenticada, mas como spam, e investigue as evidências da reclamação declarada; para o Caso C, preserve a rejeição real antes de investigar o posicionamento da caixa de entrada. Compare o mesmo método de medição e coorte entre as alterações. Aberturas ou cliques automatizados não são prova de ação humana. Estes casos são fictícios e não medições de campanha ou promessas de melhoria.