All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Anyone else with Delayed/Lost emails [MXroute]?
Heya all,
The past week or so I've been having quite a few moments like "Is it just me, or...?" so I thought it might help to drop a question here while waiting for a reply from MXroute.com. I think a lot of LowEndTalkers use MXroute so you might have some valuable feedback.
Some mailboxes are hosted in MXroute (a service I respect - check disclaimer below). But I've been having some issues with lost/delayed incoming emails from April 30th 2018 up to now (May 9th).
More specifically: Some incoming emails never made it through and the senders didn't get any error/warning. In some cases I can be 100% sure that the sender did send the message because it was CCed to other people too. Everyone got it but me. Needless to say that I've already checked spam/junk. Some other incoming emails made it through but with a 12-24h delay.
I haven't noticed any issues with outgoing emails.
Anyone else facing similar issues?
Disclaimer: This post is not a flame war, name-and-shame, or anything negative about MXroute. MXroute is a nice service which I have and will continue to recommend to people. Please refrain from posting non constructive comments like "ditch mxroute" or "take your email elsewhere".
Comments
Sometimes, sometimes.
I don't have this issue personally.
Have you logged in to cPanel and checked "Track Delivery" ? There you can see all the incoming & outgoing emails for your accounts, and if they were successfully delivered or rejected (+ the reason of their rejection).
Sometimes. No return no error no logs.
I've had it once or twice but have no evidence to support that or help diagnose the issue
@Jarland @MikePT
No really there's no way to tell that an email wasn't successfully delivered, unless it is rejected. The "Delivered" notification means the person opened the message with their mail client set to allow hitting a remote beacon gif, which is a lousy privacy setting.
If the mail is delivered successfully (lands in the person's inbox) but the person doesn't open it, or if they are sane enough to not enable the beacon ping, you never get that notification. It's like when you send someone a physical letter and they don't answer. That doesn't mean it didn't reach them.
(edited for clarity)
I don't reject email without error except for one server and under one condition (hits backup relay and fails virus scan, guaranteed not relevant to legit email), but it is the duty of the sending server to return any error we return back to the sender as the server rejected has the duty of sending the bounce notification. Not being able to connect to us would also generate a bounce error. The key in the logic is that it's impossible to send an email to our server and not have it received while not receiving a bounce error unless the sending server is broken or the sender is rejecting/filtering the bounce notifications from their own server. Now, having it received and having it delivered are different things, as customers can control and limit delivery via forwards, filters, etc. By received I mean accepted by our server for the purpose of delivering to the local recipient.
For what it's worth I've never once expected an email and didn't receive it within a reasonable amount of time (under 1m) on my service (exception for reported outage). I've been eating my own dog food since day one
I'm still under water in tickets but if you include the most information that you can (expected sender/recipient, date of expected email, even expected subject could potentially help) and let me know the ticket # I'll do my best to rush it.
9/10 times I get this report it's because someone set up a filter or forwarder and judged the end result without considering that either of these things can prevent you from seeing an email that was accepted for delivery. The other times are always DNS. I'll of course keep an open mind and investigate everything within my scope of influence. I'll never claim it can't be my problem, only alert you to how unlikely it is so that you consider reviewing other possibilities as well. There is like a one in a million chance that an email got caught in a queue cleaning job of 200,000+ outbound messages thanks to someone's easy password
(very very slim chance)
I knew this topic would prove to be a good idea!!
Thank you guys for your replies and special thanks to @kbap for the great hint! I must have been blind to miss such a useful feature.
Once again, I have only good things to say about MXroute.com. Ticket replies were very informative, complete with log excerpts pinpointing the issues, which for the record were not issues with the service. As Jarland already said, some sending servers are not configured correctly and either filter or [whatever] bounce messages. In such cases the sender never gets the bounce
That's why I used the word rejected :-) Delivered in the context of the Delivery report means the email has been accepted by the remote server, not read by the recipient which is completely different
Oh I thought delivery report meant that the click ping got back to the sending server. If it just means that the remote server accepted it and possibly spamholed it, then ok sure.