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. [email protected]

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!

  • So if I get this correctly, you generate a unique return adress for each user instead of a unique link to click?
    – Guran
    Apr 5, 2019 at 9:02

2 Answers 2


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 [email protected] to claim in the From field of the mail header to be [email protected] 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.


Let's compare the two approaches.


You send an email to [email protected] 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.


You send an email to [email protected] with instructions to send a reply to [email protected] 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 [email protected] 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."

  • 1
    I understand the question differently. In my opinion the OP does not ask about sending the user an email where the user then replies, but instead providing just a mailto:[email protected] link in a web page and expect the user to send a mail there. In other words: no mail is ever send to the user but only the user sends a mail. I come to this interpretation since the title of the question explicitly says "Email verification by sending mail instead of receiving". Apr 5, 2019 at 10:53
  • @SteffenUllrich Yes, in that case the process is certainly not secure. I did ask for clarification in a comment to the OP.
    – Guran
    Apr 5, 2019 at 10:56
  • @Guran, thanks for the answer. Yes, it's from a mailto: link. It doesn't test for deliverability, just sendability. What are the ramifications of that? Apr 6, 2019 at 2:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .