Recently I posted a note to a WordPress group on Facebook about BruteProtect no longer issuing new API keys, and naturally Automattic’s Jetpack plugin was mentioned since that is where you have to go for BruteProtect functionality nowadays. Since the internet never disappoints, Jetpack detractors there were there almost immediately chiming in with the usual comments about how “bloated” the plugin is (I don’t personally agree); how awful Jetpack is because it starts with numerous modules activated out of the gate (I don’t see this as a big problem, as they are easily enabled/disabled and it is something you only have to worry about once per site installation); and how much of a pain it is to manage Jetpack installations for clients due to its requirement for connection to a wordpress.com account.

This last complaint caught my attention, because it reminded me of a discussion we’d had a few months ago at the agency where I work. We were discussing a rollout plan for giving Jetpack to many of our existing clients, but we knew that we would need to connect each site to wordpress.com in order to do so. For ease of use we wanted to use a single email alias such as `[email protected]`, but this was immediately ruled out. When you have multiple independent clients, you can’t connect everyone with the same email address because don’t want each one having access to each others data (especially stats and plugin management!). We needed a different approach.

Our final solution ended up taking about 5 minutes to configure, and allowed us to go through the Jetpack installations with ease. New clients who receive Jetpack are quickly connected with no additional setup required.

YMMV, but this solution worked well for us.

1. We created new MX records for a subdomain of ouragency, `jpack.myagency.com`. We then created a new domain for this FQDN in our mail server.
2. The mail setup for this domain has a single catch-all alias, which forwards to two members of our team who are responsible for all things Jetpack. So you can send an email to `[email protected]`, `[email protected]`, `[email protected]`, `[email protected]` and all mail is simply forwarded to two employees.
3. When connecting a client site to Jetpack, we use a `[email protected]` naming convention with throwaway passwords. No muss, no fuss, and if we ever need to manually log into the account we do a simple password reset (this rarely comes up, so the extra step when it does happen is written off as a necessary evil).

That’s it! We connect the sites using their own email addresses, validation emails are forwarded to our team, and all of our clients have their own segregated Jetpack installations.

Hopefully this information will help inspire someone else to try using Jetpack across multiple installations instead of writing it off because configuration seems “too hard” or “too annoying”.

Truthfully the primary inspiration for us installing it for many of our clients was the Protect module, because it’s so easy to quantify the benefit by looking at the amount of malicious login attacks that are turned away just by turning on this simple piece of functionality. (I used to have actual statistics to demonstrate this, but recent changes to the API have thrown off my reports – I will update this post if/when I get those numbers again!) If you’ve never used it before, I highly recommend it. It comes enabled by default on new installations of Jetpack, but it can’t hurt to double check and make sure yours is running!