[ShakataGaNai]

> Developers using custom domains for their email address should seriously consider the risks they are taking on by using the email for their online accounts. If this domain expires or is hijacked, where does that leave them?

This high level point really irritates me. What if your let your domain expire? What if your domain is hijacked? This applies to EVERYONE doing ANYTHING online with their own domain name - aka every business. What if you let your email account get hacked? What if you stop logging into your gmail account and they deactivate it for inactivity?

At the end of the day there are a hundred ways your accounts can have issues, if you don't care. If you don't pay attention. If you don't set up the proper alerting. Custom domains are not magically worse than using a gmail account.

As a normal, non-business, person... The longest running domain I've had was registered in 2005. It is still setup to receive email and works reliably, as it has done so for the last 17 years. Yes, it's been through several different email services in that time - but because I care about it I make sure it keeps working.

[lrem]

I also have a personal domain that's nearing 20 years of being online. Today qt.io refused registering an account because they didn't like said domain. I refuse to use another one. Despite already having written a repro and found where is the bug in their code. What have we come to?

[techsupporter]

> Today qt.io refused registering an account because they didn't like said domain.

Did their form say what wasn't liked about your domain? I'm curious because I remember a time, you may as well, when lots of account forms only accepted domains from known residential ISPs and would try to guess domains used by freemail providers.

These days, I'm curious why a group like QT would care.

[lrem]

Nope, the error message stated only that I can't open an account with this domain.

[burrows]

Seems like the author is making a reasonable point to me. The risk profile for a gmail email address and a custom domain email address are different and developers may benefit from understanding this difference.

I don’t think he’s attacking the character or intelligence of people who use custom domains, he’s pointing out a gotcha that they may not be aware of.

[jmull]

You're giving the article more credit than it's earned.

Indeed, a developer should understand the risks and benefits associated with using an email address on domains they control vs. domains someone else controls.

Too bad the article doesn't make that point.

(Seems obvious to me that a domain you control is less risky since the mitigations are relatively straight-forward and reliable, while for a domain you don't control, you really don't have any reliable mitigations if the domain owner decides to shut you down. Not to mention that a third-party domain also has the risk of expiring or being highjacked. A third-party domain only makes sense if you want to trade risk for dollars: a cheaper or free email address for a greater risk of losing control of the email address.)

[tjoff]

Having your own domain shoulders you from google or any other mail provider. Surely that is vastly better.

[burrows]

We can do a risk profile for an email with a custom domain versus a gmail domain.

Do we need to differentiate between custom email domain with self-hosted mail server and custom email domain with gmail?

If I self-host the mail server then I’ll have a machine running on digital ocean or ec2 and this machine will accept connections from the Internet. I think this machine should be included in the assessment. So now the risk of a custom email domain depends on when/how I apply patches and how ssh access is configured?

[tjoff]

That is like a fraction of a fraction of a fraction of people with own domains.

I don't think that's relevant, at all.

[burrows]

Could you please clarify your point? I don’t understand the comment as is.

[tjoff]

That we don't need to differentiate on that level.

We'd first have to differentiate people that write their password on post-its in an open environment. People that have the same password on all services etc.