Most commonly, when one or more users are unable to receive email from your website, those mails are being flagged as Spam somewhere along the line. Here are some common troubleshooting tips to help diagnose and/or prevent that situation:
You can find more explanations of specific email settings that can be configured within the software on this page
If the above does not help in finding a good email configuration this section contains the collected wisdom we and previous clients have applied within the following admin tool to get emails to properly reach the admin and their clients. It's more general philosophy if the above does not help and the following explains things in a larger context to help you better understand.
Know that there may not be "one fix" to get emails to reach their recipients reliably. You may have to apply several suggestions to get emails sent correctly. This mainly means changes in the following section of the admin tool to configure the software to send through your host. There is no correct "one configuration works for all" to setup the email configuration. The first step is to contact your host to see what they require to send emails through their servers. It is their server. They made the email configuration and so should know how to reliably send emails through them. When you do contact them make sure that you ask them how to specifically configure a script on your site to send emails and NOT how you as a person would send emails from your local email reader through their servers. They could be very different configurations.
Know also that your host is in a constant battle with email spammers to stop spam from getting sent from or through their servers. This effort sometimes forces them to keep certain things secret. Though you should try their suggestions we've found that our clients have needed to stray far from their suggestions to get emails through successfully. So what eventually works for sending emails may be different than their requirements. Many hosts will work in any of the settings you choose but still others require specific usernames and passwords connecting through specific ports to get emails sent. So contact your host first to see what they want you to use and do actually test them. You could be saving yourself lots of time if their suggestions work at the start. But don't be afraid to try different things than they suggest. What's best is what actually works.
In your hosts battle with spam emailers they could be victims of bans also. And if they are banned your site may also be by extension. There's no helping that until your host gets the ban removed. If you are actually getting bounce emails from your target DO take a look at those emails. In many instances the rejecting host puts specific reasons for rejection within their emails that can prove valuable in finding the perfect email configuration or point out there may not be anything you can do within the software to affect a change.
The software itself does not actually send emails. Your 'server' actually sends the emails. Our software simply prepares the email for the server to send out. Our software offers several settings to account for variances in server configurations. Any of the standard possible email configurations we know of are options in the software. We haven't had to change this part of the software in years because those options haven't really changed. Please refer to the following admin tool and try each setting until emails are sent and received successfully:
E-MAIL SETUP > GENERAL E-MAIL SETTINGS > E-MAIL METHOD USED
Note that if the SMTP option is used, you may need to contact your host for an SMTP USERNAME and PASSWORD, as sometimes this is required.
You can try several different configurations within the above admin tool. You can actually send yourself a test email with any specific configuration. Make a configuration and after each configuration use the Send test e-mail to: feature in the following admin tool to send yourself an email. You can then change the configuration and retry immediately if you wish. When you receive an email successfully look within that email. It will contain all of the configurations used to send that email. You can look at the emails that reached you and other test accounts successfully to find the configurations that worked. If you don't receive an email with a specific configuration that configuration didn't work. Also note that it can take a while to receive these emails. You may not receive these emails immediately depending on how your host chooses to send emails. In high traffic times "email queues" at your host's SMTP server may be quite long while other times non-existent affecting the actual time the email gets sent. On top of the actual SMTP server sending hosts also employ SPAM filters that may take time in scanning for SPAM. In sending test emails we suggest you test sending those emails to many email test accounts around the Internet. Use emails at domains like gmail.com, yahoo.com, …etc to send test emails to also. Each of these email services have their own SPAM filters your emails will need to get through.
There are the settings made to get the software to send emails through the system and then there are possible further configurations to get the emails sent by the software into clients email boxes. Simply getting the software to send emails from the admin tool may work for some, most or all of your clients but there are some server configurations where more is required. The configurations you are worried about may not be the ones on your server. Those emails are going out. The Geo software is always sending them. Your clients on the other end of those emails just may not be getting them in their "inbox".
We always suggest the use of the SMTP method first. In this configuration the emails are prepared and handed over to your host. From there they are placed in the email queue at your host. The server response when sending by this method is almost instantaneous. That's because the software is simply adding that email to the host email queue to be sent out and doesn't wait for a confirmation the email was actually sent by the software. You can see issues with the "native mail()" configuration in that the software "waits" for the server to send a response that the email was sent. While that may seem better on the surface it isn't with respect to use of the software. Most php configurations have a 30 second timeout and this timeout could be reached in higher traffic times. Your clients could be left "hanging" at the contact seller, listing placement or registration features.