Email verification by sending mail instead of receiving

Question

I have an app whose main purpose is to help people track emails they send.

In most user onboarding, The user is sent a secret URL via email. They validate by clicking a link to return the secret.

An alternative would be to create a mailto: link with a bcc: containing an email address that is the secret. e.g. verifiy-some-long-hash@example.com

We plan to implement the bcc: anyways. Assume the API used to read the emails includes info on DKIM/SPF verification.

Technically, does that validate the email address as well as clicking a link?

If the email doesn't include the DKIM/SPF info, my assumption is it could have been forged, so it's not complete enough to assume the email is validated.

Thank you!

Answer 1

Relying just on a mail claimed to be send by a specific user will neither be sufficient not practical to verify the sender, even with SPF and/or DKIM validation.

Neither SPF nor DKIM validate the sender of the email in the first place. They verify at most that a mail was send using a mail server which is allowed to send mail for the claimed domain - where the claimed domain is unrelated to the domain in From field in the mail header (i.e. what is usually seen as the senders address). Only DMARC will align the domain in the From field of the mail header with the claimed domain in the SMTP dialog (SPF) or the DKIM-Signature (DKIM).

Even then - this will only align the domain part but not the actually full address. Thus relying only on this would allow attacker@example.com to claim in the From field of the mail header to be goodguy@example.com and neither SPF nor DKIM nor DMARC would complain.

In addition to that it is common to have domain often explicitly allow service providers (like Office365, Mailchimp,...) to send mail in their name by adding their IP addresses or domains to the SPF policy or providing them with the key needed for DKIM. These service provider have the infrastructure typically shared between all clients which badly affects the granularity SPF would offer and also means that somebody except the domain owner can send DKIM signed mails with the owners domain.

Apart from being insufficient to validate the sender it would also require the clients infrastructure to have DMARC and at least one of SPF or DKIM properly implemented - which only very few have.

Answer 2

Let's compare the two approaches.

Either:

You send an email to newuser@userdomain.com with a link to mydomain.com/longsecretuniquekey and consider the users email adress validated if you recieve a request to that url within a certain timeframe.

Or:

You send an email to newuser@userdomain.com with instructions to send a reply to longsecretuniquekey@mydomain.com and consider the users email adress validated if you recieve an email to that adress within a certain timeframe.

I'd say that those two approaches are equivalent from a security perspective.

In both cases, you know that someone (or something) can recieve an email sent to newuser@userdomain.com and that this somebody/something actively decided to send a request to the provided url/email to the provided adress.

In neither case do you know if that someone is a legitimate owner of the email adress, a man-in-the-middle or someone who has gained wrongful access. In neither case do you know if it is a human user or a bot.

The reply-to email approach comes with some extra caveats. Primarily: you might get false confirmations from out-of-office replies, "user not found" replies etcetera. Also two way email confirmation increases the risk of someone sniffing the email.

But still: implemented properly, they should be more or less equivalent. As in "Not very secure, but better than nothing."