Base de conhecimento

Remetente verificado

Uma marca ao lado do remetente quando os registos publicados do domínio remetente batem certo.

Detalhes

Todas as mensagens que recebe trazem uma linha de Verificações do remetente em Detalhes, indicando o que cada um dos três mecanismos disse, se passou ou não, e quem o disse. O veredicto é calculado à chegada a partir do que o relay recetor reportou, por isso é um registo do que aconteceu e não uma verificação feita quando abre a mensagem.
O veredicto é LIDO, não recalculado. Os servidores que recebem o seu correio verificam a assinatura contra a mensagem tal como chegou e declaram o resultado na própria entrega, ao lado da mensagem e não dentro dela; é isso que o selo reporta. Nada aqui o volta a derivar, porque verificar uma assinatura por si mesmo significa guardar para sempre os bytes originais de todas as mensagens, e uma caixa de correio aqui guarda antes a conversa já processada. A dica di-lo, em vez de deixar o selo dar a entender outra coisa.
Nunca se acredita num veredicto escrito dentro da mensagem. O Authentication-Results é um cabeçalho vulgar e qualquer remetente pode escrever um a dizer que passou, por isso uma afirmação transportada numa mensagem é mostrada como um relato de um estranho e não como uma conclusão. O selo só é desenhado sobre veredictos que vieram com a entrega, calculados pelos servidores que receberam a mensagem, a única parte de uma mensagem que chega que o seu remetente não consegue escrever.
DMARC e DKIM, não SPF. O SPF falha em todas as mensagens legitimamente reencaminhadas, já que quem reencaminha não está no registo do domínio original, por isso exigi-lo retiraria o selo à maior parte do correio que chega a uma entrada através de uma lista ou de um redirecionamento. Uma mensagem que passa nos três di-lo na linha de Verificações do remetente; uma que passa no DMARC sem o conjunto completo também o diz, e indica que mecanismo realmente falhou em vez de assumir que foi o SPF. Uma falha de DKIM ao lado de um DMARC aprovado não é tratada como falha de todo: o DMARC passa com qualquer um dos mecanismos alinhados, e uma assinatura partida pelo rodapé de uma lista de distribuição é a razão habitual para esse par.
Um veredicto de phishing prevalece sobre ele. Uma conta comprometida envia correio perfeitamente autenticado, por isso o selo é retido em qualquer mensagem assinalada como perigosa: o selo responde se o domínio é quem diz ser, e nunca lhe é permitido suavizar o aviso que responde se a mensagem é segura.
O BIMI não faz parte do selo, deliberadamente. Pendurar a marca num logótipo publicado significaria que um domínio que passa em tudo não mostra nada porque nunca comprou um, o que é um facto sobre um orçamento de marketing e não sobre correio. O logótipo é desenhado onde pertence, como avatar do remetente, e é retido numa mensagem que não passou no DMARC, porque a marca de uma marca ao lado de um endereço forjado é a coisa mais persuasiva que um cliente de correio pode fazer por um atacante.
Nenhuma marca significa que nada foi provado, não que algo falhou. O correio guardado antes de estas verificações existirem não traz veredicto nenhum, e diz “não verificado” em vez de tomar emprestado um passe que nunca ganhou.