Our registration system requires email confirmation. The confirmation table is continuing to add users that aren't confirming their accounts, and the vast majority of these are @gmail.com addresses.

Given that many have given us a good effort in filling out other fields and appear to be valid potential users, I'm pretty sure we have a GMail delivery issue.

What steps have you taken to ensure that transactional email is actually getting to a user's Gmail box?

    Sender Policy Framework requires you to add a bit of extra DNS for your domain. I started there. I also set up DKIM at one point. The deliverability to my addresses (some of which are gmail) seems to work fine regardless of which gmail account I use, but other users report that they cannot receive email at their respective gmail addresses.

    I would also point out that gmail is perhaps one of the most popular (and probably most-abused) email systems in the world. There's a strong chance that a lot of those orphaned confirmation table records are just script kiddies screwing around. If, however, you are getting complaints from real users about the email never arriving, your emails might be getting caught in gmail's spam filters. Based on my very limited knowledge of google's algorithms, I would NOT be surprised if every account on gmail has its own spam filter rules that are tailored to some degree to that user.

    I'd also fully expect that your domain, if it lacks SPF and DKIM or whatever up to this point, might be suffering in some kind of internet limbo where the reputable anti-spam systems consider your email "dodgy" and so you are getting stuffed in the spam folder. It may take you time to climb out of this jail/pit/prison. I'd start by setting up SPF/DKIM and whatever good-citizen-type stuff you can and hopefully your spam factor will improve over time.

      I implemented SPF for us some time ago. DKIM is currently underway. Unfortunately for me, I marked one of our transactional email as "not spam" in my phone's Gmail account, so I can't use that for testing any longer. One of the salespeople has a Gmail account or two, so maybe we can do further testing with their email address.

      As for the veracity of the account seekers, we've been able to find social profiles for most of them on LinkedIn, so I'm not really sure what to think about that, but I'll keep that under advisement.

      dalecosp I would hardly consider the existence of a social media account proof that an email address is valid and belongs to a human being. On the contrary: creating a social media account seems to be the new first stop for scammers in this day and age.

      I also wanted to suggest that you should use a modern bot check like Google's reCAPTCHA v3 to make sure that anyone supplying an email address is, in fact, a human. I believe it's vital to protect any registration or entry point for your software application with technologies like these. I hate to suggest using yet another data collection tool from a tech titan like Google, but the bots are more and more savvy all the time.

        We do have CAPTCHA from Google. If the PHB gets too concerned about these abandoned registrations, I guess I'll make a larger effort to verify them independently. What I'm really afraid of is abandoning the confirm step altogether, which definitely does play into the hands of the bots and Nigerian scammers, etc.

        dalecosp Yeah I hear you about not wanting to abandon the confirmation step. My first thought on this was perhaps to give your users an option to address the delivery failure by sending YOU an email to expedite a registration. Like, during the registration process put a big ALERT on the page that says "be sure to check your junk email folder -- if the email hasn't arrived in an hour or two, send an email with this code AABBCCCWHATEVER to complete-registration@example.com. You could set up a cron job to check the email inbox there and process incoming messages and make sure they were actually sent from where they are supposed to be sent from -- like check the IP addresses in the headers and all that junk.

        I also saw this link, which looks quite helpful for your plight:
        https://support.google.com/mail/answer/6227174?hl=en

          Write a Reply...