File in root directory

Don’t discard the possibility of putting a file in a root directory of the corporate website. It works well and is widely used: Google Webmaster Tools is one example of such technique. This makes this approach attractive: since most users already know it, they won’t be lost. Also, it doesn’t require any technical knowledge, unlike modifying MX records (most small companies won’t even know what an MX record is).

In order to avoid polluting the root directory, you should ask to put a file only when doing your checks. Once you’ve found the file, the user may be able to remove it.

Note that users who don’t have any corporate website won’t be able to access your service, but I don’t think there are many customers in this case.

Note that:

• You should check for both http://example.com/file and http://www.example.com/file, because some websites are configured in a way they don’t support http://example.com/ form.

• You may support HTTPS as well, given that I don’t think there are a lot of companies with no redirection from HTTP to HTTPS.

• You should not accept any other third-level domains such as http://mysite.example.com/, because this will make it possible for someone who bought an third-level domains to claim that he’s the owner of the second-level domain example.com.

Sending an e-mail

Sending an e-mail with secret link is rather problematic. You can’t do it to [email protected], because a given person may not have a corporate e-mail address (this is often the case of startups, where people prefer using their personal address).

Using e-mails such as [email protected] will not work in some cases.

• First, there are always companies not having [email protected], [email protected] etc., but having their particular “system” e-mail addresses you haven’t whitelisted. Consider specifically foreign companies; for example, in France, it is not unusual to use “Administrateur” instead of “Administrator”, including for e-mail addresses and account names.

• Second, many small companies don’t access and don’t know how to access their system e-mails. They pay not even know they have [email protected] with hundreds of urgent e-mails waiting for their reply.

  For the same reason, you can’t base yourself on WHOIS records for e-mail address.

The question is in effect: “What does it mean to own an email domain?”.

Owning a website is defined by the ability to put a file in the root. Ordinary users may be able to put a file on http://example.com/~user42/validation.txt but not on http://example.com/validation.txt.

For email, there’s no such hierarchy. However, the postmaster address is special. (Reserved per RFC2142) You won’t be able to create [email protected]. Thus, the ability to create and/or access postmaster@ is the proof you need for email domain ownership.

Seeing in your comments that you might not prefer to use the file-in-root-of-website method, an alternative which might work is to

Verify ownership using WHOIS

You would need to get the domain being requested (for example stackexchange.com), and one of the emails listed in the WHOIS output for that domain. (Note that this won’t work for secret/private registrations, but if your audience is corporations this usually isn’t a problem)

For example:

WHOIS information for stackexchange.com:**
...
Domain Name: STACKEXCHANGE.COM 
Registrar WHOIS Server: whois.name.com 
Registrar URL: http://www.name.com 
Updated Date: 2014-05-14T16:49:02-06:00 

Registrant Name: Sysadmin Team 
...
Registrant Email: [email protected] 
Admin Name: Sysadmin Team 
Admin Organization: Stack Exchange, Inc. 
...
Admin Email: [email protected] 
Tech Name: Sysadmin Team 
...
Tech Email: [email protected] 
Name Server: cf-dns02.stackexchange.com 
Name Server: cf-dns01.stackexchange.com 
DNSSEC: NotApplicable 

You could even do the whois lookup interactively and provide a dropdown list of the valid emails (in this case, just [email protected]). You would then send a verification code/link to the chosen email.

Ask your users to add a TXT record to their domain with a reference to their user account on your site (their username, ID, or an arbitrary token generated when asking the user to verify their domain).

I remember adding a record called adn_verification=<my user name> on a social network to display my domain as verified, and I thought that’s pretty neat and doesn’t require you to have the domain pointing to a web server.

To add to the suggestions already on the page: I recommend to give the user options in how he validates his domain. The other suggestions on the page are all perfectly usable, but sometimes you are in the situation where someone who wants to verify their domain only has limited access to their server or even their website. For example, your user might not be able to add domain records or files in the domain root.

For example, Troy Hunt allows users to search for an entire domain in his database of compromised accounts, but you need to verify first. He gives the user the choice of 4 methods:

1. Via email;
2. through a meta tag;
3. A file upload;
4. a TXT record.

In all 4 of these cases, he requires the user to enter a specific value somewhere which he verifies against.

The explanation is at http://www.troyhunt.com/2014/01/im-pwned-youre-pwned-were-all-pwned.html.

Could you afford avoiding the use of free webmails for registration?

That’s what Brium does: you can’t sign-in with an @gmail.com, @live.com, etc e-mail – you have to use your own.

And it clusters you by this.

If you are targeting businesses, that should be a good way to go.

You could still have the problem of knowing who the boss is (say, the admin of that group), but it may not be that important – the boss should probably have the tools for telling any employee to transfer the ownership to him, provided someone registered before the boss.