IMAP Server Sends and Receives, But Doesn't Deliver

Not much to go on, and the symptoms you're reporting are not entirely clear to me; are these local or remote mail clients, and how do yoi know the mail server is sending and receiving?

Given it's one of the more common triggers for network weirdness and for mail servers in particular, please verify your mail server DNS. Please post your public DNS domain, and somebody here can check it for validity. Alternatively — if you're shy about posting that — this could be a problem typical with many newly-configured and mailfunctioning mail servers; that the host that is your MX record for your domain doesn't have matching forward and reverse DNS translations for its host name; that is, launch Terminal.app and issue the following harmless diagnostic commands (the $ is the prompt, don't type that, and substitute your domain for example.com in the following — I'm showing the mail server name associated with that as yourmailservername.example.org, and I'm showing the IP address you'll see as 10.20.30.40 — you should see your IP address there):

$ sudo changeip -checkhostname

{various configuration output, then an indication of whether changes are required, or not}

$ dig +short MX example.com

10 yourmailservername.example.org

$ dig +short yourmailservername.example.org

10.20.30.40

$ dig +short -x 10.20.30.40

10 yourmailservername.example.com

$ dig +short @8.8.8.8 MX example.com

yourmailservername.example.org

$ dig +short @8.8.8.8 yourmailservername.example.org

10.20.30.40

$ dig +short @8.8.8.8 -x 10.20.30.40

yourmailservername.example.org

If the responses to one or both of the -x commands are not your host name, or if the checkhostname will report an error, then there are DNS issues. By way of explanation, the first set of dig commands asks for your local server's DNS and the second set bypasses your local DNS and asks the Google DNS server at 8.8.8.8.

If you're on a dynamic IP address and short of relaying your mail through another server and using a so-called mail hop service, there is nothing you can do here if you're on a dynamic IP address as you won't be able to get the forward and reverse DNS translations to match, and many of the other mail servers on the 'net will detect this and classify your system as a spam engine and drop arriving messages, and some won't bother to send messages to your server.

Logs?

Both the local and the public DNS are incorrect.

I'd guess you're either not running with local DNS services, or maybe you're trying to use off-network DNS, or possibly your server isn't configured to find local DNS. That doesn't work. Get your local DNS working first. Once that's sorted out and -checkhostname is happy, then you'll want to have the Metrocast ISP folks update your reverse DNS; that IP address should be set to mail.persistence-technologies.com., or to whatever you decide to name your mail server host.

FWIW, you're in a bad IP netblock for potential future use of VPNs. Get out of 192.168.0.0/24 and 192.168.1.0/24 and into some other subnet in 192.168.0.0/16, or a subnet somewhere within the 172.16.0.0/12 or 10.0.0.0/8 private blocks. FWIW, VPNs are based on IP routing and IP routing usually gets confused when the same subnet is found on both ends of the route, and the VPN tends to get tangled — and 192.168.0.0/24 and 192.168.1.0/24 are two of the most common subnets used for home networks and coffee shop networks.

The local DNS is offline or is somehow misconfigured, or the first two commands would have returned responses — that 72.9.2.40 was entered on that third (-x, DNS reverse translation) command implies an unfamiliarity with what's going on here and what's required to happen within DNS — this given that there was no address from the second command, there would be nothing to enter as an IP address for the third (-x, reverse) command.

Establishing local (private) DNS is necessary when using a private IP address space. Neither ISP nor Google DNS can provide the necessary (reverse) translations. Configuring DNS services (somewhere) cannot be skipped.

Get the local DNS configured per the directions I've linked to earlier.

I'd discourage using the same domain inside and out, as that can and usually will lead to more confusion and grief over time. Use either a subdomain of your registered domain (private.persistence-technologies.com or some such), or use a different domain you've registered. Leave your persistence-technologies.com to your public DNS servers. (I usually use a second domain, as using a subdomain leads to more typing of a longer domain over time.)

The server host name is set in Server.app. In the image below, you'll have foo.example.com or mail.example.com next to the upper green ball and foo or mail in the second green ball (where example.com is the domain or the subdomain you're going to use inside your network firewall and on your private, NAT'd network, and foo or mail is the name of the server you're using), and you'll have that name to IP address translation in your local DNS (preferrably not in the 192.168.0.0/24 and 192.168.1.0/24 subnets), and (if you're using a different domain or subdomain inside your network) you'll have persistence-technologies.com as a virtual domain name in the Mail settings for the Provide mail for... settings (press the Edit button to get to the Virtual Domain stuff) in Server.app settings for Mail.

Here is the location for the general host name settings in Server.app; select the name of the server at the top of the left column to see this:

If all else fails here and if you've started various other services within Server.app before getting DNS going (this tends to get the old name embedded in the various services, and can sometimes lead to problems after a host name change), then things are going to be more difficult; if there's not a great deal of accumulated settings yet, I'd encourage a complete system backup or two, and would then probably either remove and clobber the saved settings from Server.app and then reload Server.app here, establish IP and then DNS first, then get the other services configured and going. Here's the closest Apple support article to a Server.app delete and reset and reload restart sequence for performing a Mavericks Server Server.app reset. Once Server.app is redownloaded and reset, then get IP and DNS configured.

Has the DNS services configuration error been resolved?

dig +short mail.persistence-technologies.com

192.168.1.108

dig +short -x 192.168.1.108

persistence-technologies.com.

Have the logs been reviewed for related errors?

Have any (other) configuration changes been made?

Please read the linked article on setting up DNS services.

If you have questions or suggestions after reading that, please ask away.

As for why I'm pointing to DNS? Here is the forward name to IP address translation:

dig +short mail.persistence-technologies.com

192.168.1.108

Here is the reverse IP address to name translation:

dig +short -x 192.168.1.108

persistence-technologies.com.

The host name mail.persistence-technologies.com does not match the resulting host name persistence-technologies.com. from the reverse.

SMTP (the network protocol underneath the mail server) requires the mail server have what's known as a DNS A record, and a DNS A record means that forward and reverse names match.

This means that that mail can end up confused locally, and the mismatch (when in public DNS) also means that other SMTP server hosts can decide the host to be a source of spam and reject the translations.

I would generally avoid using the same domain inside and out — as this configuration usually turns into a hassle. I prefer to use a seperate registered domain (maybe register the .ORG or .NET version), or use a subdomain of persistence-technologies.com. or (and much less desirably) use a bogus top-level domain name. (Using a bogus top-level name is getting much harder to maintain as ICANN brings new top-level domains online.)