Please see the following email from Rich Christiansen . . .


=========


I’ve added support for semi-automated Mailjet email verifications!

You might want to have someone save portions of this in Social5’s knowledgebase. (It’s a little long, so you probably want to omit some of the lengthy discussion in the Mailjet section).

Documentation
For both Amazon SES and Mailjet, every time you add the label (e.g. “Sender: Amazon SES” or “Sender: Mailjet”), the system will send another verification email. So, to “resend” a verification email, you can remove the label, Save, add the label back, and Save again.

Amazon SES
Verification Email
I was able to configure a custom verification email that is sent by Amazon. This is an automated process requiring no assistance from Social5 support.

Verified Address Limit

In Amazon SES, the maximum number of verified sender email addresses is 10,000 (Source). This should be enough for now. Once we reach this limit, it can be increased by contacting AWS.


Mailjet
Verification Email
Mailjet’s verification process is a little awkward. Mailjet sends a verification email to the customer, but crucially, the customer can’t simply click the links included in the email. Those links need to be clicked by someone who as admin access to our Mailjet account. So, the system also sends the customer an email asking them to forward the Mailjet verification email to [email protected]. This email looks something like this:


Verified Address Limit
In Mailjet, the maximum number of verified sender email addresses is 100 (Source). Bummer. That’s pretty low. We’re currently using about 20 out of 100 of those slots; I deleted some addresses already and I imagine the list could be pared down a bit further.

100 email addresses is probably good enough for now. Some thoughts about how to handle this limitation:
  • Add entire domains when possible
    • Not only can you verify “[email protected]”, but you can verify all addresses at “example.com”. This uses only one of our allocated verification “slots” instead of one for every email address. (I deleted [email protected], [email protected], etc since we already have a verification in place for the entire social5.com domain).
    • This requires assistance from their IT department - they must add DNS records.
    • Because of this DNS step, this is not available for webmail domains like gmail.com. (Google, Microsoft, etc will simply ignore our requests)
  • Remove disabled/inactive accounts
    • When customers leave Social5 or stop sending emails, you can manually remove them as a verified address in the Mailjet web app.
    • I could additionally upgrade the Social5 backend such that when an account is disabled or the “Sender: Mailjet” label is removed, the verified address is automatically removed.
  • Use sub-accounts
    • Mailjet recommends creating a “sub-account” to enable more verified email addresses (Source).
    • The problem is that using an additional sub-account with the backend would require updates to the code.
      • This might not be as complicated as I’m imagining. Since we’re actually sending emails to Mailjet via SMTP, perhaps Mailjet’s system would be intelligent enough to match up the provided sender email address with the right sub-account. So, adding a new validated address could be as simple as choosing a random sub-account (we would need many) to use for submitting the “verify” email address request. This would come with extra costs, though, since our current account level only allows one sub-account.
        • Update: I noticed that Mailjet uses the API key as the SMTP credentials, so there’s no “guesswork” - we’d have to use the right API key that is associated with the right Mailjet sub-account. So, we’d still have to track on our end which Mailjet sub-account each customer account is using.
    • This upgrade wouldn’t be incredibly complicated, but it also wouldn’t be trivial (otherwise, I’d just make the changes now).
  • On-demand adding/removal of verified sender addresses
    • The backend system could “verify” an email address immediately before it is used, use it, and then “delete” the verified email address.
    • This is a little sneaky - I haven’t tried it, but it might work.
      • Technically speaking, I think it would likely work.
      • However, it might result in the system sending a “click here to verify your email address” email to the sender every time a message is sent, which is not ideal.
      • I suppose an even more-intelligent approach could be to keep track of the last time a verified sender address was used. Any time we needed another “slot”, we would simply delete the least-recently used sender address and add the new one. All things considered, this is probably the best option of everything here, balancing complexity of implementation, user experience, etc.

Notes for future development


This table shows the implemented options (black text) and the yet-to-be-implemented future options (gray text).

 

Name
Quality
Cost
Non-Gmail Recipients
Gmail Recipients
(Default)
Low

 

Direct (Free)
Direct (Free)*
Sender: Amazon SES
Medium
$
Amazon SES ($0.10 per 1k)
Amazon SES ($0.10 per 1k)*
Sender: Smart (Medium Quality)
Medium/High
$
Direct (Free)
Mailjet ($0.70 per 1k)
Sender: Smart (High Quality)
High
$$
Amazon SES ($0.10 per 1k)
Mailjet ($0.70 per 1k)
Sender: Mailjet
Very High
$$$
Mailjet ($0.70 per 1k)
Mailjet ($0.70 per 1k)
*High likelihood of being marked as Spam.

 

The "Smart" senders are designed to find an optimal tradeoff between deliverability and cost on a per-email address basis. As the system is currently designed, implementing this would require more work than is appropriate at the moment. (Senders are determined on a per-message basis (i.e. one message goes to thousands of recipients via the same sender); the "Smart" sender changes would require overhauling the system to allow senders to be determined on a per-recipient basis)

 

This generic naming for the "Smart" senders is forward-looking - it naturally enables us to revisit the Smart senders in the future, potentially adding new rules for what to do with Outlook emails, etc.

 

 

Add a Form Email that can be sent out.
  1. Add the appropriate Sender label. (Removing any existing Sender labels)
  2. Send the form email.

 

Elsewhere
  1. (Optional) Check Verified status with email sender(s) live.
  2. (Optional) Persist Verified status with email sender(s).

 

Later
  1. Improve Gmail detection logic (from basic "@gmail.com" detection to more advanced DNS lookups (with persistence/caching))


Phew! What an email! Hope this helps! :) Let me know what questions you have.
-R