some other authentication method, such as SPF. A receiver, after validating the sender's identity, can verify the vouch claimed in VBR-Info: by looking up the reference. iprev Applications should avoid using this method as a means of authentication. Nevertheless, it is often carried out and its results, if any, written in the Received: header field besides the TCP information required by the SMTP specification. The IP reverse, confirmed by looking up the IP address of the name just found, is just an indication that the IP was set up properly in the DNS. The reverse resolution of a range of IP addresses can be delegated to the ADMD that uses them, or can remain managed by the network provider. In the latter case, no useful identity related to the message can be obtained. DNSWL Looking up a DNSWL (DNS-based whitelist) may provide an assessment of the sender, possibly including its identification. Authentication-Results RFC 8601 defines a trace header field Authentication-Results: where a receiver can record the results of email authentication checks that it carried out. Multiple results for multiple methods can be reported in the same field, separated by semicolons and wrapped as appropriate. For example, the following field is purportedly written by receiver.example.org and reports SPF and DKIM results: Authentication-Results: receiver.example.org; spf=pass smtp.mailfrom=example.com; dkim=pass header.i=@example.com The first token after the field name, receiver.example.org, is the ID of the authentication server, a token known as an authserv-id. A receiver supporting RFC 8601 is responsible to remove (or rename) any false header claiming to belong to its domain so that downstream filters cannot get confused. However, those filters still need to be configured, as they have to know which identities the domain may use. For a Mail User Agent (MUA), it is slightly harder to learn what identities it can trust. Since users can receive email from multiple domains—e.g., if they have multiple email addresses -— any of those domains could let Authentication-Results: fields pass through because they looked neutral. That way, a malicious sender can forge an authserv-id that the user would trust if the message arrived from a different domain. A legitimate Authentication-Results: typically appears just above a Received: field by the same domain from which the message was relayed. Additional Received: fields may appear between that and the top of the header, as the message got transferred internally between servers belonging to that same, trusted ADMD. The Internet