2mo ago

Custom domain email sometimes marked as invalid?

I’ve recently been working on de-Googling and part of that has been setting up an email with my custom domain. This mostly works great, but one issue I’ve noticed is email validation on some websites detect this email address as invalid. For instance, if I have the domain [name].rocks with the email [name]@[name].rocks (with [name] being a placeholder for my name) my email cannot be used to register with the Ventra app (for getting mobile train tickets) I believe because any site that has an extension with more than four characters is detected as invalid.

I understand this is a validation issue on the end of the app dev / website, but I was wondering if people had suggestions for workarounds when they encounter this? Setting up other custom emails with forwarding? Thanks!

10 comments

I believe because any site that has an extension with more than four characters is detected as invalid.
Usually it's just badly coded apps/websites that only whitelisted some of the main domains e.g. most vanity domains don't make it through. Or sometimes there are apps/websites that purposely block your domain if the admins think it's too spammy or whatever.
If your current email provider allows you to use their own domains as an alias that's one way to sidestep the issue e.g. you'd end up with [something]@[youremailprovider].com --> [name]@[name].rocks
I have Fastmail & they have a ton of their own internal domains so that's one way I sidestep that issue. It's pretty common among most/all email providers when you bring your own domain e.g. pretty sure Proton can do the same thing. Once you have your own domain you can make up any [alias]@[yourdomain] you like or just use the provider's as a front facing alias [alias]@[youremailprovider] --> [anything]@[yourdomain].
- Thanks everyone! I think this will be the solution I go with.

The correct fix is to get the site maintainers to stop rejecting email addresses based on the characters they contain. They shouldn't be doing that. Sadly, some developers believe it's an appropriate way to deter bots, and it can be difficult to educate them.
If they won't fix it, the workarounds are to either not use those sites, or to give them a different address. Unfortunately, the latter means having to maintain multiple email accounts, or forwarding services like Addy.io, SimpleLogin, Firefox Relay, or DuckDuckGo Email.
- Unfortunately, the latter means having to maintain multiple email accounts, or forwarding services like Addy.io, SimpleLogin, Firefox Relay, or DuckDuckGo Email.
  It doesn't, you can hook multiple domains up to deliver mail to the same mail server. I have three domains pointing to a single server myself.
  (edit: added full quote)
  
  The rest of the sentence you truncated points out forwarding services. Yes, others exist beyond the four I mentioned, of course.
  Edit to clarify: Your "it doesn't" argument is that you can use forwarding from other domains that you own. Indeed you can, but that's not a counterargument, because those are forwarding services. They do exactly what I described: the same thing as the example forwarding services in my original comment. You still have to maintain the them, as well as maintain the extra domains.

I have .solutions and .info domain emails that still gets denied by some services, especially anything government or public utility, pain in the arse.
You'd think that at least .info would be pretty well accepted by now.

I have a domain with one of the new TLD which I used for my emails.
Most services worked fine with it, but there were a few cases where my email was flagged as fraudulent and I had to call, explain it was legit and provide with another email.
There was one service I registered which explicitly said they oy accept gmail addresses.
Roughly one year ago I acquired a new domain using the .org extension, I am migrating my accounts to this one, and I havent had any problems so far.
So overall my conclusion is that most services are fine with custom emails, a few of them block based on TLD and an even smaller subset will allow only specific providers. Since I am moving alway from big corp, having a widely used TLD that seems to be accepted in most cases is my personal sweet spot.

Sadly I've run into the same type of problem with a newer TLD as well. My solution was to get a domain in the older TLD space (e.g. .com, .net, .org). I doubt this will be the last site you run into that doesn't support a newer TLD and the low likelihood that you're going to be able to convince someone to fix the issue at every one of those outdated sites means that you'll eventually need a backup domain for something.

I use a simplelogin domain when my custom one isn't accepted. (Everything goes through SimpleLogin anyway.)

10 comments