Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols
draft-ietf-uta-email-tls-certs-09

In the Introduction, you say that ths document replaces Section 2.4 of RFC 2595.  It appears that it's specifically Section 3 that replaces that section.  Maybe it's best to say that?

-- Section 2 --

   reference identifier:  (as defined in [RFC6125]) One of the domain
      names associated by the email (i.e., an SMTP, IMAP, POP3 or
      ManageSieve) client with the target email server and optionally an
      application service type for performing name checks on the server
      certificate.

1. You refer to the definition in 6125 as though you're repeating it here, but you're not: you're giving a different definition.  Maybe if you said "formally defined in RFC 6125" instead, it'd be clearer that this explanation is applying that formal definition to this specific situation (email).

2. It's usually bad to put a parenthesized explanation in the middle of a unit, and "email client" is a unit here.  (And, as almost always, I think "i.e." is unnecessary and further distracting.)

3. The sentence is long and awkward, saying "associated by... with... and optionally...," and it's easy to get lost.

Here's a suggestion:
NEW
   reference identifier:  (formally defined in [RFC6125]) One of the
      domain names that the email client (SMTP, IMAP, POP3 or ManageSieve)
      associates with the target email server.  The identifier can also
      include an application service type for performing name checks on
      the server certificate.
END

- section 3, first paragraph:
MiTM prevention is just one of many reasons to match the reference identifier, right?

-5.1:
It might be worth mentioning that the methods in this draft require the provider to manage private keys for the tenant domains. 

- Informative References:
Please consider whether 2595, 5234, and 6066 should be normative references.

Editorial and Nits:
-2, Reference Identifier:
I agree with Barry's comments. Additionally, do you need the 2119 MUST in the definition? It seems like that belongs in the related requirements/procedures section.

-4.1: This section needs more proofreading\. Here's some things I found, but I may have missed stuff.
-- "manual confirm exception" -> "manually confirm exceptions"
-- "because TLS server certificate verification" - Missing "the" before TLS
-- "failure to match TLS server certificate against the expected domains" - missing "the" before TLS. Should "domains" be singular?
-- "for example.org domain" - missing "the" before "example.org"
-- "this solution depends reliance of DNSSEC " - I don't understand the phrase
-- "The ability of issuing certificates that contain SRV-ID implies..." - I don't understand the phrase.

- 5: Lots of sentence fragments in the numbered list items. That's not necessarily wrong, but mixing them up like this makes it harder to read. (At least for me.)