Entregabilidade e autenticação do remetente

Entrega não é uma única coisa

Ao enviar uma campanha da Loja Aurora por uma ferramenta de e-mail, há etapas diferentes no caminho até noticias@example.com aparecer para alguém.

Entregabilidade é a capacidade de a mensagem alcançar o destinatário. O primeiro resultado técnico relevante é saber se o servidor destinatário aceitou ou rejeitou a mensagem naquela tentativa. Isso ainda é diferente de saber em qual pasta ela foi colocada.

Portanto, evite concluir que uma mensagem foi lida — ou sequer chegou à caixa de entrada — apenas porque o envio foi aceito.

Como interpretar cada resultado

Rejeitada: o servidor destinatário não aceitou a mensagem naquela tentativa. Há um motivo a investigar, mas esse resultado não diz, por si só, que todas as mensagens futuras terão o mesmo destino.

Aceita pelo servidor: o servidor destinatário recebeu a mensagem. Essa evidência não prova que ela entrou na caixa de entrada e também não prova leitura.

Após aceitar, o servidor destinatário pode classificar a mensagem na caixa de entrada, em spam ou em quarentena. A classificação depende de avaliações do próprio sistema destinatário.

A ferramenta de e-mail informa que o servidor destinatário aceitou uma mensagem da Loja Aurora.

O que é possível afirmar com segurança?

A reputação é um conjunto de sinais que o servidor destinatário pode considerar ao decidir como tratar uma mensagem. Ela pode envolver o domínio usado no envio e a infraestrutura de envio: servidores e endereços IP utilizados pela ferramenta de e-mail.

Essa infraestrutura pode ser compartilhada entre clientes do serviço. Por isso, nem todo sinal observado depende apenas da Loja Aurora. Ainda assim, a equipe controla práticas importantes, como a origem dos contatos, a regularidade dos envios e a coerência com o que foi prometido na inscrição.

Reputação não é garantia de presença na caixa de entrada: uma mensagem pode ser aceita e ainda ser filtrada.

Regularidade não significa enviar sempre na mesma quantidade, e relevância não significa adivinhar o interesse de alguém. São práticas de redução de risco:

• evitar mudanças bruscas sem entender seu impacto;
• respeitar a finalidade e as preferências já registradas;
• investigar sinais antes de culpar somente a ferramenta de e-mail;
• manter registros da origem e da situação dos contatos.

Não existe frequência ou volume universalmente seguro. O contexto da base, o histórico e os critérios do servidor destinatário também importam.

Nem toda falha exige a mesma reação. Leia o motivo informado pela ferramenta de e-mail e siga suas regras de tratamento antes de decidir o que fazer com um contato.

Uma devolução permanente (hard bounce) indica um problema que tende a não se resolver, como endereço inexistente. Uma devolução temporária (soft bounce) aponta uma condição possivelmente passageira, como caixa cheia ou indisponibilidade momentânea.

A classificação é um ponto de partida: o motivo específico e a regra do serviço orientam a ação.

Para endereço inexistente, interrompa as tentativas e mantenha o impedimento de envio. Não reimporte o contato para contornar uma supressão.

Em caixa cheia ou indisponibilidade temporária, a ferramenta de e-mail pode realizar novas tentativas conforme suas próprias regras. Não faça insistências manuais indefinidas. Se a falha temporária persistir, revise a situação do contato.

Um bloqueio por política pede investigação técnica. Ele não prova, por si só, que o endereço é inválido.

Uma reclamação de spam é um sinal de que a pessoa marcou uma mensagem como indesejada; ela não é uma reclamação de atendimento. Interrompa novos envios promocionais para esse contato e investigue a origem da inscrição, a expectativa criada e a frequência recebida.

Higiene da base não é aumentar artificialmente a quantidade de contatos. É manter impedimentos, registrar evidências e tratar cada ocorrência sem reativar quem já está suprimido.

Na Loja Aurora, o endereço remetente é noticias@example.com. A parte após @ identifica example.com: esse é o domínio visível do remetente (From).

O domínio ajuda a identificar qual organização e qual configuração técnica precisam ser consideradas. Porém, saber o domínio não prova que a equipe tenha acesso para administrá-lo.

O DNS é o sistema que mantém informações publicadas sobre um domínio, inclusive informações usadas na autenticação de e-mail. A administração do DNS pode estar em um serviço e com uma pessoa diferente daquela que usa a ferramenta de e-mail.

São procedimentos diferentes:

• Verificação de endereço remetente: confirma que alguém consegue acessar a caixa de e-mail de noticias@example.com, geralmente concluindo uma confirmação enviada pela ferramenta de e-mail.
• Autenticação de domínio: é uma configuração técnica ligada a example.com e às informações do domínio no DNS.

Portanto, verificar o endereço não autentica automaticamente o domínio. E autenticar o domínio não garante que uma mensagem chegará à caixa de entrada: qualidade da base e outros sinais ainda influenciam a entrega.

Se quem opera a ferramenta de e-mail não tem autorização administrativa sobre o domínio ou o provedor de DNS, a etapa técnica deve ser encaminhada ao responsável adequado, seguindo a orientação vigente da ferramenta de e-mail.

Uma mensagem pode carregar identidades diferentes. Na Loja Aurora, o endereço que a pessoa vê é noticias@example.com: seu domínio visível do remetente (From) é example.com.

Mas a infraestrutura pode usar outro domínio no transporte: o domínio do envelope (MAIL FROM) pode ser example.net. SPF e DKIM não fazem a mesma pergunta — e nem sempre avaliam o mesmo domínio.

SPF é uma declaração publicada em DNS sobre quais servidores podem enviar mensagens usando o domínio avaliado nessa verificação. Ele responde, em essência: “esta infraestrutura está autorizada para o domínio do envelope?”

No exemplo, se o domínio do envelope (MAIL FROM) é example.net, o SPF avalia example.net — mesmo que o domínio visível do remetente (From) seja example.com.

DKIM adiciona uma assinatura à mensagem. O servidor destinatário usa uma chave pública disponibilizada em DNS para conferir se a assinatura corresponde ao domínio signatário do DKIM (d=) e se as partes assinadas permaneceram íntegras.

Isso não criptografa o conteúdo do e-mail. A assinatura serve para verificação, não para esconder o texto da mensagem.

Relacione cada mecanismo ou situação à função e ao domínio correspondente.

Para a Loja Aurora, o domínio visível do remetente (From) é example.com, pois a mensagem sai de noticias@example.com.

DMARC verifica se esse domínio visível está alinhado a uma identidade que passou em SPF ou DKIM. Nos casos deste tutorial, alinhamento significa igualdade entre domínios:

• SPF aprovado para o domínio do envelope (MAIL FROM) example.com pode satisfazer DMARC.
• DKIM aprovado com d=example.com pode satisfazer DMARC.
• SPF aprovado para example.net não se alinha, sozinho, ao From example.com.

Basta um mecanismo aprovado e alinhado. A aprovação de DMARC, porém, não garante presença na caixa de entrada.

A política DMARC orienta o tratamento solicitado quando a verificação falha:

• p=none: solicita monitoramento, sem solicitar quarentena ou rejeição por DMARC.
• p=quarantine: solicita que a falha seja tratada com cautela, como possível quarentena.
• p=reject: solicita rejeição da mensagem que falhar em DMARC.

São solicitações ao servidor destinatário, que aplica suas próprias políticas. Portanto, uma política não é garantia de um resultado idêntico em todos os destinatários.

Compare os mecanismos com o domínio visível do remetente (From), que é example.com em todos os casos. A tabela mostra o resultado de cada verificação.

Uma verificação segura começa pelo que você consegue identificar, não por uma alteração em DNS.

Para a Loja Aurora, registre o domínio visível do remetente (From): example.com, usado em noticias@example.com. Depois, levante os serviços que enviam em nome da marca e quem administra cada um. A ferramenta de e-mail e o provedor de DNS podem ter responsáveis e acessos diferentes.

example.net é um domínio que pode aparecer na infraestrutura de envio; ele não é, por si só, o nome de um serviço. Quando ele surgir, identifique qual serviço legítimo o utiliza antes de avaliar qualquer mudança.

Se a ferramenta de e-mail for o Mailchimp e a conta oferecer esse recurso, siga a orientação atual exibida nela. Caso contrário, use a orientação da ferramenta utilizada. Não presuma recursos incluídos em determinado plano.

A conferência passa por identificação, orientação da ferramenta de e-mail, comparação com o DNS e leitura do estado disponível.

Leia na orientação vigente da ferramenta de e-mail os campos que ela pede: tipo, nome ou host e valor ou destino. Esses dados são específicos da solicitação recebida; não invente registros universais nem substitua informações existentes por suposição.

O estado do Painel ilustrativo é uma evidência útil, mas limitada ao escopo conferido pela ferramenta. Ele não prova que todos os serviços de envio estão corretos, não comprova sozinho o DMARC e não demonstra chegada à caixa de entrada.

Um plano de verificação transforma sinais dispersos em decisões rastreáveis. Separe sempre o que foi observado do que é uma interpretação possível e do que ainda precisa ser confirmado.

Priorize impedimentos de envio: devoluções e reclamações de spam não são motivo para insistir. Em paralelo, registre pendências técnicas sem alterar DNS por conta própria.

Use os cinco campos desta tela para que cada pendência tenha uma ação segura, um responsável definido e uma condição clara de encerramento.

Cenário fictício — Loja Aurora

A Loja Aurora envia como noticias@example.com. O domínio visível do remetente (From) é example.com.

• A ferramenta de e-mail mostra o endereço remetente como verificado, mas a autenticação do domínio aparece como pendente.
• A organização não tem acesso ao provedor de DNS. O responsável técnico administra o domínio e também outros serviços legítimos de envio.
• Em uma mensagem analisada, o domínio do envelope (MAIL FROM) é example.net e o SPF foi aprovado. O domínio signatário do DKIM (d=) é example.net e o DKIM foi aprovado. O DMARC falhou. Neste caso, alinhamento exige domínio igual ao domínio visível.
• Outra mensagem foi aceita pelo servidor destinatário; não há informação sobre a pasta em que ficou.
• Na base, ana@example.net teve uma devolução permanente (hard bounce) por endereço inexistente e já está suprimida. bruno@example.net teve uma devolução temporária (soft bounce) por caixa cheia. carla@example.net registrou uma reclamação de spam.

Não altere DNS, não reative contatos suprimidos e não faça novo envio para resolver o caso.