Unsolved problem: emails goes to spam!

I know that Strapi recommends to install custom email provider not to use the default one, but why? Can’t we have properly working email provider right out of the box? I’m not an email expert, but as I see the node-sendmail module has the major advantage of sending mail without SMTP server. For most of the cases this is all we need!

see node-sendmail @github

I tested the email configuration in the administration panel and everything works correctly. The only part missing is the domain check. And possibly a test button.

In #3804 this guy found the solution, I think this should be the default config, with a fallback to false in case the key is not found. As a bonus would be nice if we had a way to upload/update the key in administration panel.

I think a properly working email right out of the box is important, because this way we reduce unnecessary concerns on migrations or clean install.

@SorinGFS

The default email system doesn’t require any existing email infrastructure and is useful for testing as the email is sent from the server Strapi is running on. In a production like configuration you should/would have an actual email implementation along with all of the required DNS records (MX, DKIM, ect). Strapi itself cannot predict these settings in advanced and requires the user to configure them.

Strapi itself is not in the “email business” so to speak, hence why we have a handful of providers, actual implementation should be up to the user and we should only provide a viable test option (that being said most consumer ISPs block outbound port 25, hence why we have added an option in the CLI to reset passwords).

If you are willing to work on a better solution we would be open to seeing what you think, but please do open an RFC: GitHub - strapi/rfcs: RFCs for Strapi future changes before you open a pull request.

You’re right, but usually you do have an email implementation, to make it work with Strapi too all you need to do is to copy that ./dkim-private.pem and to specify the key, I think it wouldn.t be too hard to make them updatable form admin panel.

I don’t know the Strapi project well enough to try a PR, I hope somebody else will help us on this!

The issue is, this changes a file on the filesystem, meaning node has to restart. For the same reason why disabled the Content-Type builder, this won’t be possible.

But as an example we have a handful of one-click options where a user may not have email properly setup.

Ok, let’s forget for a moment the admin panel.

If the default config would be the one shown in #3804, and Strapi would check if the key is configured by querying the domainkey using fs.readFileSync('./dkim-private.pem', 'utf8') before compiling the config with dkim: false would it be impossible?

That much can save us from configuring custom email provider…

The rest would be as easy as this: Generating DKIM key with openssl - lxadm | Linux administration tips, tutorials, HOWTOs and articles

@DMehaffy

Not exactly the same case, but here is how I wrote a multi layer fallback system in my project, is tested and working: config keys

With some more research I found that for dkim pass we don’t neccessarily need to have an email implementation. So, first I got my keys, the syntaxes using openSSL to generate DKIM keys can be found here.

We need two keys, first the private key, and based on private key we generate the public key:

openssl genrsa -out dkim-private.pem 1024
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
  • notice that the syntax is slightly modified to get pem extension instead of key

Until here the domain name is not important, you can use the keys with any domain as long as you specify the correct key name everywhere. For most of situations we have a project, or a main project using a registered domain name, and that is the domain we can use to send emails from. That domain name must be set in administration panel > settings > email templates at the sender, e.g. no-replay@myDomain.com and this is the domain that will provide the dkim public key.

Following the instructions from the above webpage I got the public key string in a single line.

Then, I added public DKIM record in namecheap like the image shows:

Using an online dns lookup I tested out the result: (the domain name was modified)

The public part being ready and tested we need to configure email provider to sign emails using dkim-private.pem. For this I moved both keys in my Strapi root folder (we only need the dkim-private.pem but is not a problem if we put both).

In order to get Strapi to read the dkim-private.pem file I created this PR. Basically, if the file exists, is read and set as dkim.privateKey in sendmail email provider.

In order to test the setup I modified the file directly in strapi-provider-email-sendmail and I simullate a registration process (to see if the email-confirmation passes the dkim test). Protonmail provides the function to export the received email where this dkim validation result can be found, and the result is: dkim=pass (1024-bit key). I used a 1024 bit key, but 2048 can be also used.

Conclusion

If the above mentiond PR is approved all we need to do is to set the keys: one in dns, the other in the project’s root folder. If the PR is not approved we need an extra step to customize the email provider.

Caution

On public key setup in dns do not change the host! It should be: default._domainKey. This is because I set the keySelector: 'default' in the PR. Normally, when a domain have more the one email sender that keySelector can take any name, the whole point is to match the one seen in email by the receiving email provider (to be able to query the correct key from dns)…

Final thoughts

Can DKIM solve the problem of emails going into spam on its own? Definitely not! There are several factors that matter:

  • the domain used to send emails must be clean, not listed in anti-spam blacklists
  • if the domain is new it starts with a domain rating equal to zero (is not trusted yet, you have to ask users to check the spam folder too)
  • some email providers are more restrictive than others

What I can certainly say is that DKIM is a mandatory step for getting emails in inbox.