Ir a la documentación
Base de conocimiento

Remitente verificado

Una marca junto al remitente cuando los registros publicados del dominio emisor cuadran.

Detalles

  • Cada mensaje que recibes lleva una fila Sender checks bajo Details, que nombra qué dijo cada uno de los tres mecanismos, si pasó o no, y quién lo dijo. El veredicto se calcula al llegar a partir de lo que informó el relé receptor, así que es un registro de lo que ocurrió y no una comprobación ejecutada cuando abres el mensaje.
  • El veredicto se LEE, no se recalcula. Los servidores que reciben tu correo comprueban la firma contra el mensaje tal como llegó y declaran el resultado en la propia entrega, junto al mensaje y no dentro de él; eso es lo que informa el sello. Aquí nada lo vuelve a deducir, porque verificar una firma por tu cuenta significa conservar los bytes originales de cada mensaje para siempre, y un buzón aquí guarda en su lugar el hilo ya analizado. La descripción emergente lo dice en lugar de dejar que el sello dé a entender otra cosa.
  • Nunca se cree un veredicto escrito dentro del mensaje. Authentication-Results es una cabecera corriente y cualquier remitente puede escribir una diciendo que pasó, así que una afirmación que viaja dentro de un mensaje se muestra como el informe de un desconocido y no como un hallazgo. El sello solo se dibuja sobre veredictos que llegaron con la entrega, calculados por los servidores que recibieron el mensaje, la única parte de un mensaje entrante que su remitente no puede escribir.
  • DMARC y DKIM, no SPF. SPF falla en todo mensaje legítimamente reenviado, ya que el reenviador no está en el registro del dominio original, así que exigirlo le quitaría el sello a la mayor parte del correo que llega a una bandeja de entrada a través de una lista o una redirección. Un mensaje que pasa los tres lo dice en la fila Sender checks; uno que pasa DMARC sin el conjunto completo también lo dice, y nombra el mecanismo que realmente se rompió en lugar de suponer que fue SPF. Un fallo de DKIM junto a un DMARC correcto no se trata como un fallo en absoluto: DMARC pasa con cualquiera de los dos mecanismos alineados, y una firma rota por el pie de una lista de correo es la razón habitual de ese par.
  • Un veredicto de phishing lo supera. Una cuenta comprometida envía correo perfectamente autenticado, así que el sello se retira en cualquier mensaje marcado como peligroso: el sello responde si el dominio es quien dice ser, y nunca se le permite suavizar el aviso que responde si el mensaje es seguro.
  • BIMI no forma parte del sello, y es deliberado. Colgar la marca de un logotipo publicado significaría que un dominio que lo pasa todo no muestre nada porque nunca compró uno, lo cual es un hecho sobre un presupuesto de marketing y no sobre el correo. El logotipo se dibuja donde le corresponde, como avatar del remitente, y se retira en un mensaje que no pasó DMARC, porque la marca propia de una marca junto a una dirección falsificada es lo más persuasivo que un cliente de correo puede hacer por un atacante.
  • Que no haya marca significa que no se probó nada, no que algo fallara. El correo almacenado antes de que existieran estas comprobaciones no lleva veredicto alguno, y dice «not checked» en lugar de tomar prestado un aprobado que nunca se ganó.