Real-Time Email Address Verification
Today end users need to go back and forth to confirm their email address. Email address verification is necessary in order to comply with country-specific spam laws. E.g. CAN-SPAM Act.
If a business does not verify the submitted email address, then they may be spamming innocent people who never submitted their email address.
For example, an abuser submits [email protected] address in your email newsletter subscription form. If you keep sending your newsletters without verifying email address, then you are sending spam to Jeff Bezos.
Some study says around 25% of the users never confirm their emails. So from the business perspective, they lose 25% of the potential customers.
We are simplifying the email address verification process. Email addresses are verified in real-time. In other words, users don’t have to leave the website/app to verify their email address.
VRFY is one of the SMTP commands introduced in RFC 821.
VRFY command asks the server to verify an email address resides on the server. Many mail servers do not support VRFY command in order to prevent abuse. For example, spammers can use the VRFY command and scrap valid email addresses and send spam mails later.
RFC 5321 mandates VRFY command. Instead of disabling it completely, the server should return the 252 code like this.
Normal Verification Request
In the following example, John Doe manually click the verification link to verify his email address.
Real-Time Verification Request
Dombox Address Generation
Created IP and Created Datetime
When a Dombox address is generated, we actually record the Created IP and Created Datetime
Signup IP and Signup Datetime
When a Dombox address is submitted by a user during signup or newsletter subscription, your website/app should record the Signup IP and Signup Datetime.
Send Verification Request
Once you detect a dombox address, just send us a verification request via SMTP. We respond with Created IP (sha256 hash format) and Created Datetime (unix timestamp format).
Since we are dealing with real-time verification, if the "Created Datetime" is NOT less than 1 hour (i.e. < 3600 seconds), then we respond with the generic message.
252 Cannot VRFY user, but will accept message and attempt delivery.
Validate the Datetime
First compare our "Created Datetime" with your "Signup Datetime".
If the time difference is less than 1 second or more than 1 hour (i.e. > 3600 seconds), then you have invalid data. So proceed to normal verification method.
Validate the IP
Take the sha256 hash of your "Signup IP".
Compare it with our "Created IP".
If the hash doesn't match, then you have invalid data. So proceed to normal verification method.
If both Datetime and IP validation successful, then you have the valid data.
If successful, use QUIT command to close the connection.
Insert Dombox Address, Signup IP, Signup Datetime in your database table and mark the user as "Verified".
If failed, switch to RCPT TO command to go for normal verification method.
Plain SMTP is vulnerable to man-in-the-middle attacks.
For example, the attacker can eavesdrop the conversation [passive attack] or modify the conversation [active attack]. So a secure connection is required in order to prevent such attacks.
STARTTLS is an SMTP extension which establishes secure connection. EHLO is needed for STARTTLS. EHLO stands for Extended "Extended Hello".
If EHLO and STARTTLS command is not issued, then real-time address verification not gonna work. We respond with the default 252 code for VRFY command.
Sender Policy Framework
At the moment, we accept real-time verification request only from the "Dombox Domain". In [email protected], example.com is the "Dombox Domain".
So make sure you have SPF record configured properly in your "Dombox Domain" (example.com in this case) and the "Client IP" is whitelisted in your SPF record.
It is the client's responsibility to make sure that the server certificate is valid.