It’s been almost 6 months now. Officially. Less in reality. There is so much to take care of in such a process. I’m still finishing up some paperwork.

I felt like it was time, though. Time to think back and try to draw lessons from closing the business I’ve been running for nearly 7 years.

N2Clic Ltd. Closed Down

It’s a long time, 7 years. In fact, it’s the longest I have been working for the same company. Ever. It is definitely with a pinch in my heart that I came to the decision of closing down my company, N2Clic Limited.

The Begining

N2Clic was incorporated in 2013, but the journey started years before that. The farthest I can remember, my partner, Julien, and I, were discussing what business we would be creating when we were fruit-picking during the summers of our high school years.

We went our ways after high school and finally got serious about the business around 2010.

We started N2Clic as a small, side project in addition to our respective jobs. Things went slow but steady. In 2012, it was going well enough for us to decide to quit our jobs and focus on our web agency full time.

Fast forward 4 years and this is when we took the (harsh) decision to close shop.

A Good Run

Those years were awesome. I’ve learned so much about so many things.

When you run a small business all by yourself you’re forced to do basically everything. It includes things that you may have absolutely no training for and that are far out of your comfort zone.

I can say for sure that this experience made me a better version of my former self. Both on a professional level and on a personal level. Indeed, when you’re the one doing everything, it also means that you’re the one responsible for every mistake. And there were a few. You learn to swallow your pride, admit your mistakes and figure out how to fix them.

Thanks to this experience, I have a more critical and more analytical way to look at things now.

On the company side, we had a good run. We served dozens of clients and the majority of them were very happy. Some even came back to us for multiple projects.

In our 7-ish years in business, we only fired one client. Now that I think about it, we should probably have fired a few others too. Learning when a business relationship needs to be ended is tough. It is harder to see the long-term gain than the immediate loss of income.

During all those years, both my partner and I learned a massive amount of skills, allowing us to expand our commercial offering and to deliver high-quality work. We started out as a very small shop with no name and ended up being in the “premium” tier of our industry.

I wanted a pixel perfect implementation of my designs and they really delivered up to my expectations. Julien is a master at WordPress and PHP in general. He is quick, personable and reliable […] These guys rock!

– Jeremie Tisseau

Decline and the Tough Call

If everything was so good then why closing down? Well, everything was not so good.

To summarize the core of the reason, we were in a position where our business was stagnating. I have identified a number of key moments where we took the wrong decisions and that led us to this stagnant position.

The business was still afloat, but it was not satisfying. Two options became clear:

  1. Invest more money and a year or two to overcome the key mistakes that we made,
  2. Learn from our mistakes and move onto something new (and pass go and collect some cash in the process 😉

We agreed to go for option 2. Both Julien and I love learning new things and being challenged. This was an opportunity to start a new challenge without worrying about the money.

So we got started. We stopped taking on new projects, announced the big news to our existing customers and set to finish the current projects.

For a few years, we have also been running ThemeAvenue under the umbrella of N2Clic. ThemeAvenue was mostly distributing Awesome Support, a support plugin for WordPress.

After much debate, we decided to let ThemeAvenue / Awesome Support go as well. In the process, we learned another new thing: selling a business.

Awesome Support was pretty successful in and on itself so there was no way we could just abandon the project. We managed to find a successor pretty quickly and cashed in in the process. The project now continues to thrive (I might talk about this in another post) and gets all the attention it deserves.

What’s Next?

I started working as the Head of Product and Business Development for a development company called Nimbl3 in November 2016.

Nimbl3 develops web, iOS and Android apps

If I can’t tell what the future holds for me, what I can say for sure is that this company has great potential. I believe I joined the team at the right time. The company seems to be set for a pretty steady growth and they offered me a position that sets me pretty good for the future.

Also, they are very open to product ideas, which is something that I might want to take advantage of in the future.

One of the reasons why I decided to join Nimbl3 is that they focus on building very high quality. I’m not going to dive into details in this post, but I might write another piece about this company in a few weeks. If you need a top-notch web or mobile app, stay tuned 😉

I’ve been wanting to get onto PHPCS for quite some time now. While reading a blog post discussing it, I decided it was now or never. I should have started using PHPCS a while ago anyway…

So, in order to get things up and running, I did a quick Google search and ended up finding a pretty good tutorial, except that it is slightly outdated. Some of the instructions did not match the latest version of PhpStorm.

The article is How to Setup PHP Code Sniffer in Phpstorm on a Windows Machine from

NOTE: At the time of writing this article, I was running PhpStorm version 2016.2.1.

Most of the instructions are correct, except for a couple of them. Here is an updated version of the outdated steps. Also, you’ll need to have PEAR installed on your local machine beforehand.

Step 2

You will actually need to copy all the WordPress-xxx directories in CodeSniffer’s Standards directory as they rely on one another (otherwise you’ll get errors in PhpStorm).

Also, because I’m only using standard PHP on my local machine (no XAMPP or any pre-packaged web server), PHPCS was located in C:\php\pear\PHP\CodeSniffer.

Step 4

The setting you’re looking for is now located in Languages & Frameworks | PHP | Code Sniffer.

Again, because I’m using “raw” PHP, the path to PHPCS was actually C:\php\phpcs.bat.

Step 5

The Inspection settings are now in Editor | Inspections | PHP Code Sniffer validation.

PHP CodeSniffer Validation

PHP CodeSniffer Validation

That’s it. The rest of W3Guy’s tutorial worked perfectly. Time to deal with those extra warnings now!

I have been using phpDocumentor on my Windows laptop lately, and one of the requirements is to have PEAR installed.

While this is a pretty simple process on Linux, it gets a little more complex on Windows.

Actually, it is not that complex. It is just difficult to find the proper resources (or at least it was for me).

I did find a number of posts / tutorials explaining the manual process of installing PEAR, but:

  1. It introduces possibilities of mishaps,
  2. I prefer when things are automated 😉

Automatically Install PEAR on Windows

First of all, I should specify that this was done on a Windows 10 Home x64 install with PHP 7.0.6. No WAMP, no MAMP, just PHP.

There are basically 2 steps required to install PEAR:

  1. Download the “installer”
  2. Run it
  3. Add the environment variables (yeah that’s more than 2 steps, but this one is optional. Bonus!)

Download go-pear.phar provides a super handy phar file that will allow you to install PEAR on your system in just one command line. Download go-pear.phar and save it in your PHP directory (most likely C:\php).

Run go-pear.phar

The next step is to use go-pear.phar to install PEAR. Simply open up a command prompt, move to your PHP directory, and type:

php go-pear.phar

You should then be asked if you want to go for a local or system-wide install. I needed a system-wide install, so this entire tutorial is based on this scenario.

Now, just let the script do its job…

Unlike me, you should not be getting the message “WARNING! Old version found at C:\php […]”. I re-installed PEAR for the purpose of this tutorial, which is why I’m getting this warning.

Add the Environment Variables

As you can see at the end of the process, the script tells you:

For convenience, a REG file is available under C:\phpPEAR_ENV.reg. This file creates ENV variables for the current user.

If you go to C:\php and double-click PEAR_ENV.reg (a warning should appear, just click yes), the script will add all the required environment variables to your system.

Windows Environment Variables

Windows Environment Variables

My blog has been hosted on various machines from various providers. It is only recently that I started to aim for performance, though.

For the last couple of years, it has been hosted with EvxOnline. I then switched to a DigitalOcean (affiliate link, direct link available in article footer) droplet with ServerPilot.

While performance was definitely better with DigitalOcean + ServerPilot compared to EvxOnline, I wanted something even faster.

I have had my eyes on EasyEngine for a little while but didn’t have the chance to really try it yet. So the day I realized I made a typo in my ServerPilot’s app name, the maniac in me didn’t need another excuse to get started with a new stack.

EasyEngine vs ServerPilot

First of all, I need to say that I really like ServerPilot. I’ve used it for many client and personal projects. It is extremely easy to setup, the stack performs really well, and it keeps your server up to date. If you’re looking for good performance without getting your hands too dirty, go for ServerPilot.

If you want to push things a little further however, EasyEngine is, in my opinion, the way to go.

In both cases, I used a $5, SFO1 droplet (512 Mo RAM, 20 Go storage, located in San Fransisco). I also use CloudFlare, even though it doesn’t seem to make any difference with my new setup.

The theme I use is exactly the same, as well as the plugins installed.


ServerPilot uses a modern and proven stack: LAMP/LEMP with Nginx as the public facing web server proxying the request through to Apache.

The blog was then loading in 1.7 seconds in average (I didn’t do any stress tests, just page load time).


EasyEngine is a bit more complex to setup (actually, it is especially the case when transferring a site, installing from 0 seems pretty straightforward), but it is partly because of the number of options available. It is purely LEMP (no Apache here), although you have the option to install HHVM.

I installed WordPress and got rid of WP Super Cache that is basically replaced by FastCGI. I ran the tests and surprise, the page load time is down to 0.8 seconds! (I know it is not exactly 1 second, but my first tests were showing 0.7s and 1s sounds pretty good 🙂

GTmetrix Report

GTmetrix Report


Just like I wrote earlier, if you want performance without getting too much in the console, go for ServerPilot. You basically need to copy/paste one command and that’s it. ServerPilot will do the rest.

If you want to get high performance and are ready to spend more time in the console, EasyEngine is awesome. With very little customization it performs extremely well. Their site says:

Automatically tweaks server configuration as per available hardware resources

I don’t know what this implies exactly, but it seems to be working damn well.

There is one thing I’m wondering about though: how come the performance improvement is that big? I mean, 1 second faster is quite impressive. I’d love to hear more from the EE team 🙂


Some of the links in this article contain affiliate codes. If you wish to visit those links without my affiliate code, here is it.

As a plugin developer who released a few plugins on, I sometimes feel like the song says: Je t’aime… moi non plus. Well, sexual content aside :p

There are two questions I’ve been asking myself a lot lately. Dan Cameron’s post What Now? No Way? Huh? made me feel that maybe others are asking themselves those questions too.

Disclaimer: this post is not at all a critic of the current system. I am not trying to provoke anyone in the community. I am merely trying to get answers to two selfish questions I’ve been asking myslef:

  1. Who am I in the WordPress community?
  2. What are my “rights”?


While this is not the only thing I’ve been wondering about, this post was inspired by how incentivized reviews are being handled.

My first interaction with the .org team on this matter dates back to April 2016 when I released, in all honesty, a small library, WP Review Me, where discount codes were automatically given in exchange for a review.

Otto came down hard on me very quickly in this GitHub issue:

Then, there was Dan’s post, to which I left a pretty lengthy comment. But then I realized there was more than just a difference of opinion, which is why I’m writing this post.

I, Plugin Developer

I love WordPress. I’ve been working with it one way or another since circa 2012. I love how flexible it is, how powerful, and how amazing the community is. I’ve seen some really awesome things happen, and I’ve met some extremely generous and open minded people.

What did I contribute to benefit from that? Mostly plugins. I have contributed a tiny fix to core a while back, and while I felt very proud, it was really nothing compared to what the real core contributors do.

So, as a plugin developer, where do I – I as in I, plugin developer, not just I, Julien Liabeuf – stand in the community?

When I see what happened to Dan (I also had a plugin taken down the same way in the past, minus the removal of reviews), I can’t help be feel cheated. This situation seems extremely unfair to me. But what can I say? Do I have a say in this? Obviously no in Dan’s case.

At a more global scale, what can a plugin developer say in a decision making process?

The Gift of Time

When I release a new plugin on, I spend hours forming the idea, planning the features, writing the code, writing documentation, supporting users… All of that for free.

If someone takes my plugin down or deletes user’s reviews, it’s a bit like saying “all this work you put in for free, we’ll just delete a part of it”. It makes me feel like shit. It makes me feel like I’m nothing, that I don’t have a word to say in how my own work is being used.

Should plugin authors be allowed to step in?

I understand the review team. They, too, put a lot of unpaid time in what they do. Probably more than me. From where I stand, there are two ways of envisioning things.

Plugin Authors Don’t Have a Say

If I were to stop developing plugins and drop WordPress, it wouldn’t change anything. If all plugin authors were doing the same, WordPress would still be here.

If WordPress was gone, though, there would obviously be no plugins. Plugins are nothing without WordPress; which mans that core / review people should definitely be the ones saying what’s ok and what’s not. They should be allowed to do whatever they please with plugins.

Plugin Authors Do Have a Say

If there was no plugins, sure WordPress would still be here. It would certainly not power a quarter of the web, though. It wouldn’t be as great as it is.

This means that plugin developers are a big part of WordPress’ success and as such, they should be allowed to step it.

Easier Said Than Done

Unsurprisingly, I tend to think that plugin developers should have a say. However, the first proposition is valid as well.

There is another thing that should be considered: the amount of time and resources each contributor type puts in.

Core contributors and reviewers certainly give more of their time to the community than I do. Does it mean that their opinion should matter more than mine? Absolutely. They deserve it. But it shouldn’t mean my opinion doesn’t matter at all.

When I read guidelines #9 and #18 that are currently in the spotlight, I feel like someone is telling me “fuck you”.

#9: […] This includes spam, for whatever definition of spam we want to use.

This, to me translates into “You genuinely think what you did was ok? Well I say no. Fuck off”.

#18: […] We reserve the right to arbitrarily disable or remove any plugin for any reason whatsoever. Basically, this is our repository […]

This, to me, translates into “Thanks for releasing your work. Now we rule. Don’t complain”.

These are very aggressive statements and they obviously mean that a plugin developer has no say whatsoever. Which leads me back to my original questions: who am I in the community and what are my rights?


I could summarize all the blah blah above into one simple quiz.

John spent a lot of time to release a free plugin on The review team sees something they don’t like. They suspend John’s plugin and delete his reviews. John wants to discuss the decision. Which of the following answers from the review team is correct?

a) Shut up

b) Let’s discuss that matter


I still don’t really have an answer to my questions. Who am I in the community? What can I do/say? What should I be able to do/say? I feel a bit lost sometimes.

There is one sure thing, though. My post might sound like a critic of the review team, but it’s not. Sure there are things that could be improved in the review team / authors relationship. I’d actually be glad to be part of some kind of reflexion group to try and improve how review team members and plugin authors interact.

I also want to acknowledge the amount of time the review team provides. Thanks for your work guys.

I’ll now be back to tormenting myself with my existential crisis 🙂

So you just got this new WordPress theme or plugin approved by the review team. Exciting!

You get your first downloads and you watch the stats all the time. What are you waiting for? We all know it: reviews! Especially 5 stars reviews 😉

Reviews are Everything

WordPress Plugin Reviews

WordPress Plugin Reviews

Indeed, reviews are often what convinces the user to use your product… or not. That’s why all authors are striving for good reviews.

There is another thing we all know, though: unsatisfied users tend to review more than satisfied users. This means that you can easily end up with some bad reviews even though your product is good and the majority of users are happy.

What can you do about?

It may sound simple (and it is) but you just need to ask your users to review your product.

WP Review Me

This is where this small library I wrote becomes your best marketing tool!

WP Review Me

WP Review Me

It does a very simple job: X days (you can configure X) after the theme/plugin was installed, the user will be prompted to leave a review on

Technically speaking, you can create this prompt with one single line of code:

new WRM_WordPress( array( 'type' => 'plugin', 'slug' => 'my-plugin' ) );

The library also has a number of advanced parameters that will let you customize about anything (notice message, link label, etc). All those are explained on the wiki page of the GitHub repository.


Just asking users to review your plugin might not be enough, though. Sometimes, users need to get something back for giving you a helping hand. This is where the various integrations come into play (well, only one for the moment, but more to come).

EDIT: Initially, this library did integrate with Easy Digital Downloads to offer a discount in exchange for a review. Unfortunately, the WordPress review team believes that doing so would lead to biased reviews and asked me to remove this feature. I am definitely not trying to challenge the community so I abode by their request. More details here:

Up Next

The library does what I need it to do, so improvements will only come if asked. Feel free to add issues to the GitHub repository or submit your PRs 😉

One more NameCheap-related article. Yeah, I’m a big fan of their services!

TL;DR: FreeDNS can’t manage .is domains.

For some client work, I needed to use NameCheap’s FreeDNS service to manage a domain name with the .is extension.

After some back and fourth with the domain registrar to try and switch the DNS to FreeDNS, I finally got in touch with NameCheap’s support team and started what ended up being a 1-hour conversation on their live chat.

By investigating the issue bits by bits, we came to the conclusion that FreeDNS can’t manage .is domain names because it doesn’t fit the .is registry requirements.

The part that blocks everything is that FreeDNS’s nameservers’ TTL is set to 1800 seconds while the .is registry requires at least 86400 seconds. The NS‘s TTL can’t be changed, even internally by the NameCheap’s team.

So, sadly, a .is domain name can’t be managed by NameCheap 🙁

WordPress admin notices are great. They’re extremely handy for communicating an important message to the users of your theme or plugin.

A WordPress Admin Notice

A WordPress Admin Notice

Admin notices can be used for sharing an information, warning of a problem, etc. WordPress made is very easy to register with the admin_notices hook. There is one extremely important thing though: admin notice dismissal.

Dismiss an Admin Notice

Have you ever used a plugin that displays a notice that can’t be dismissed? Or a notice that comes back on every page load, whether or not you have dismissed it already? What a pain… Nobody wants that.

In WordPress 4.2, WordPress introduced dismissible admin notices. This is basically a front-end mechanism that hides a notice when you click the close button. But again, refresh the page and the notice is back.

Persistent Notices Dismissal

What you want is for a notice to be permanently dismissed once this close button is clicked. This is exactly what WP Dismissible Notices Handler does.

WP Dismissible Notices Handler on GitHub

WP Dismissible Notices Handler on GitHub

After writing admin notices dismissal functions over and over I realize how dumb I was for not having a re-usable library. So much for DRY heh.

So I wrote this one. You can very easily use it in your projects using Composer:

composer require julien731/wp-dismissible-notices-handler

This library does 2 things:

  1. Register admin notices
  2. Handle dismissal

Where this library differs from other libraries you can find is the options. When registering a notice, there are two important things that you can set:

  • A user capability: for the notice to show up only for users with a specific capability. Very handy to show a message for admins only for instance.
  • A scope: you decide if the notice should be dismissed at the user level (dismissed for the current user but still on for other users) or at the site level (one user dismisses it for everyone else)

How easy is it to use this library? Well, it’s just one function call away.

dnh_register_notice( 'my_notice', 'updated', __( 'This is my notice' ) );

That’s it. With this one line of code you just registered an admin notice that can be properly dismissed. Find all the available parameters on the GitHub repository.

I’ve been developing WordPress stuff for a few years now. During all this time, my development toolkit changed. A lot.

As I learnt new skills, I discovered new tools. This usually resulted in a gain of productivity, improved skills, and realizing better tools were available.

Even though this cycle definitely has a limit, I think I still have some nice things to discover. Docker for instance is something I’d love to have the time to dive into. Capistrano is also something I really want to learn more about.

As of today though, I’m really happy with my development environment. Here is what it looks like…

Development Environment

In this post I’m focusing exclusively on the environment and not the development tools per se. That could be a topic for another time…

My current development environment is composed of 4 tools (excluding all the basics like Git): Vagrant, Varying Vagrant Vagrants (VVV), Variable VVV (VV) and VVV Dashboard.

This set of tools makes it super easy to setup a production-like dev server, create new site “on the fly” and manage all the resulting mess 😉


Yes I know, the first tool I’m talking about is not in the above list. I’m not going to discuss VirtualBox, I just put it here because a virtualization tool is required to run Vagrant, and VirtualBox is the one I use.




Vagrant is a tool that helps create virtualized development servers quickly. The way it works is: you feed it a configuration (through a config file) and then Vagrant will create a new server with the right box and set it up as instructed in the configuration file.

In my case, the configuration file will be provided by VVV.

Varying Vagrant Vagrants

Varying Vagrant Vagrants

Varying Vagrant Vagrants

VVV is, as stated in their, “an open source Vagrant configuration focused on WordPress development”. It contains a Vagrant configuration specifically designed for WordPress developers.

Once your Vagrant is up with VVV, you get 3 WordPress instances:

  • A fresh WordPress install running the latest stable version
  • A copy of the WordPress repository trunk
  • A copy of the WordPress development repository (containing everything, like unit test etc, handy to contribute and create patches)

With all this you’re ready to develop your latest theme or plugin in a production-like environment. WP_DEBUG is turned on by default so that you won’t miss a stupid PHP warning.

Variable VVV

Variable VVV

Variable VVV

It’s a lot of “Varyblahblah” isn’t it? I mean, without shortening it we would have to say “Variable Varying Vagrant Vagrants”.

Until recently, my main issue with using VVV for all my WordPress development work was the time required to setup a new VVV machine. For that reason I ended up using Wamp for small things. I was not too happy about doing it though, because developing with VVV really is better and more reliable.

That was before I discovered VV. What VV really is is a WordPress instance creation wizard. By running VV in your VVV machine (that’s a hell lot of “V”s seriously), you can create new sites in about 30 seconds. A bit longer to be completely honest as the script still needs to download WP and setup the new instance. With my internet connection is usually takes around 5 minutes.

The setup assistant is really good. By simply typing vv create in your terminal you’ll trigger it and you will be asked a series of questions like the site name, the domain name to use, if you want to enable WP_DEBUG, if you want to enable multisite, etc. Really easy.

VVV Dashboard

VVV Dashboard

VVV Dashboard

The last tool on the list is VVV Dashboard. Why is it useful?

After you played with VV for a while and you ended up having quite a few WordPress instances, then you’ll forget how to access them all. Believe me. And because VVV’s homepage doesn’t show the “extra” things, you’ll end up having to look through the config to find what domain names you used.

VVV Dashboard makes it dead simple. It replaces the default VVV index and in addition of showing all the basics, it will indeed list all your available instances, give you quick access to your sites and the admins.

It will also show you which site has WP_DEBUG enabled, the latest PHP errors, and some server information. Beautiful.

How To

I was planning on writing a brief tutorial on how to setup this development environment, but I realized this post is getting pretty long. Also, all the tools mentioned have pretty straightforward installation guides.

If you guys need extra help for setting all this up, I’ll gladly write a tutorial on how to setup (my) perfect WordPress development environment. Just ask for it in the comments.

When working on client projects, e-mail delivery is a primary concern. Most of my clients (most people in general I assume) use e-mail quite extensively for lead generation on their site.

Making sure e-mails are correctly delivered is crucial. Unfortunately, the basic way e-mails are sent out with website is quite unreliable. The common function used in PHP for instance is mail(). As a WordPress specialist, I very often work with its WordPress wrapper wp_mail().

What this function does is send the e-mails using the hosting server itself. This is very dangerous, especially when using shared hosting. Poor delivery and blacklisting are the two major risks.

Email Delivery Services

I’m not going to list all the reasons why you shouldn’t use a hosting server to send out e-mails. I’m just going to say that it is more than recommended to use a dedicated e-mail delivery service. There are plenty available. Mandrill, MailGun, SendGrid, MailJet…

For all the small clients I’ve been working with, I’ve always used Mandrill (made by MailChimp). They offered a pretty nice free plan that was more than enough for small businesses. However, they stopped this free plan not long ago.

As I was working on yet another small business’s site, I turned towards MailGun. It also is a well made delivery service. However, I encountered one problem when trying to validate the domain (mandatory to start using the service).

MailGun & NameCheap

I am a huge fan of NameCheap for domains management. Their prices are really good, and the support has always been outstanding for me.

Validating your domain on MailGun using NameCheap is not exactly done as described in MailGun documentation. I’ve been able to figure out how to make this work after a bit of research.

You’re asked by MailGun to add an SPF and a DKIM record to your domain hosts. You can Google that around if you don’t know what it is. Instead of just copy/pasting the records as MailGun shows them, here is what you wanna do.

SPF Record

With NameCheap, the SPF record should NOT contain the domain name as the host, but @ instead (which is basically a shorthand for your domain name).

The SPF record in NameCheap should look like this (the pattern is host | value | record type):

@ | v=spf1 ~all | TXT Record


If the SPF won’t validate, you can check it with MXToolbox:

If it shows the correct SPF record, then just wait. If not, check your settings again.

DKIM Record

Regarding the DKIM record, two things need to be changed.

First of all, the host should NOT contain your domain name. It should simply be pic._domainkey.

Second of all, you want to add the DKIM version at the beginning of the value: v=DKIM1. Your record should look something like that (again: host | value | record type):

pic._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBVxKp59mzTBGjleRsxzLg0ESZcDRQSgwwBiUtsllnYNvGZRJbdyfe4rxpoi0+yQvetgrthyA3j2OMpI3IKzo5mFoKBO11wgS5mM8ryjkLCeQtyjtyU02LIDVTfxYY66WOavBvp/PiY+2erWnxqmW0QDB+HNLIaE+JV0dhp85vhxFWQIDAQAB | TXT Record


If the DKIM won’t validate, you can check it with MXToolbox:

When replacing DOMAINKEY, use the part that’s before _domainkey and don’t include any ..

If it shows the correct DKIM record, then just wait. If not, check your settings again.