From the question and particular the comments it appears to me that an explanation of how email works is in order - because the premise of the question is very flawed. Below is a "101" overview of how email servers work.
An eMail server typically comprises multiple services - A service for delivery between computers (MTA - mail transfer agent) called SMTP, and services used for end users to check their email (MUA - Mail user agent) - like POP3, IMAP and Microsoft Exchanges protocol.
When email is delivered between machines there is a 2 part process to work out how to find the appropriate machine. The first step - which is now standard is look up a special record in the DNS called an MX (Mail Exchange) record. This provides the domain name of the mail server which is resolved into an IP addres, and mail is delivered to it. You need to know that an MX record is simply a reference to a machine name - so to change how mail works you don't need to change any nameservers, and you can handle email independently of other services like web service.
A throwback to old days is that if there is no MX record, a mail server can try resolve the record for the domain name its delivering email from directly. Doing this is technically allowed because of legacy requirements before the DNS system existed but is a bad idea - and indicates whoever is handling email lacks even basic competency. The question appears to incorrectly assume this mode of delivery is the norm.
POP3, IMAP and Exchange protocols simply listen on a port and can pull emails from disk and provide them to a client after authenticating the user. The protocols differ in how they synchronise email between multiple clients and the commands used for authentication.
None of the protocols require a domain name for people to connect to the server - the server is accessible by IP address only. Whenever you use a domain name for an SMTP/IMAP/POP server your mail software is simply doing a lookup to get its IP address and is then connecting to that. ** Only after the connection is established to the IP address of the mail server is email requested - and the mailbox - which is often the email address - provided by the client to the server with the contents of the mail box being provided after authentication. Thus, even if there is a mail server that already has mailboxes set up with data in them, even if there is no DNS, it is practical to retrieve the email.
For further clarification - to check email from a POP3 server the communication could be emulated along the following lines (IMAP is similar) :
CLIENT: telnet ip.addr.of.server 110
SERVER: Connected to ip.addr.of.server.
+OK Server ready.
CLIENT: user email@example.com
CLIENT: pass PasswordGoesHere
SERVER: (provides a list of numbers - XXX - associated with emails)
CLIENT: retr XXX
SERVER: (sends the email associated with number XXX)
Note that provided the IP address of the mail server is known, DNS is entirely unnecessary in recovering the email.
There is one minor exception to this - when you are using secure versions of the protocols. In these cases there is an additional step where the there is an attempt to verify the domain name of the machine you are trying to connect to. If you use IP addresses there is every likelyhood that this will throw up a warning because the IP address you connected to does not match the domain name associated with the servers certificate. As this is a client side thing this error can be ignored if you are confident that no one is trying to intercept your communications)