223 lines
6.4 KiB
Markdown
223 lines
6.4 KiB
Markdown
## Goal
|
||
|
||
Set up transactional email for each client’s WordPress site using Maileroo, while keeping every client isolated from the others.
|
||
|
||
This document is written for a website agency that manages multiple client domains and wants a repeatable, low-friction workflow.
|
||
|
||
---
|
||
|
||
## Recommended Structure
|
||
|
||
Use this hierarchy for every client:
|
||
|
||
- One Maileroo account for the agency.
|
||
- One Maileroo Application per client.
|
||
- One verified sending domain per client.
|
||
- One sender/API key per client.
|
||
- One WordPress mail connection per site.
|
||
|
||
This keeps Company A’s site separated from Company B’s site, so credentials and authorized domains do not overlap.
|
||
|
||
---
|
||
|
||
## Why This Works
|
||
|
||
Maileroo describes Applications as separate, self-contained sending environments. Each application can be restricted to its own authorized domains, which is the main isolation layer you want for client work.
|
||
|
||
Maileroo also says agencies can add an unlimited number of domains, and each domain gets its own sender key, which makes it practical to manage many clients from one account.
|
||
|
||
---
|
||
|
||
## Step-by-Step Setup
|
||
|
||
### 1. Create the client record internally
|
||
|
||
Before touching Maileroo, make a small internal record for each company:
|
||
|
||
- Company name.
|
||
- Website URL.
|
||
- Sending domain, usually the main domain or a subdomain like `mg.client.com`.
|
||
- From address, such as `noreply@client.com` or `website@client.com`.
|
||
- Destination address for form notifications, such as `hello@client.com`.
|
||
|
||
This gives you a clean source of truth for setup and handoff.
|
||
|
||
### 2. Create a Maileroo Application for that client
|
||
|
||
In Maileroo, create a new Application named after the client, for example:
|
||
|
||
- `Acme Plumbing`
|
||
- `Acme Plumbing - Website`
|
||
- `Acme Plumbing - Production`
|
||
|
||
Use one application per client so each site has its own sending environment.
|
||
|
||
### 3. Add and verify the client’s domain
|
||
|
||
Add the client’s sending domain in Maileroo and complete DNS verification.
|
||
|
||
Recommended DNS records:
|
||
|
||
- SPF.
|
||
- DKIM.
|
||
- DMARC.
|
||
|
||
If possible, use a subdomain for sending, such as:
|
||
|
||
- `mail.client.com`
|
||
- `mg.client.com`
|
||
- `tx.client.com`
|
||
|
||
This keeps transactional email separate from the client’s main mailbox setup.
|
||
|
||
### 4. Restrict the Application to that client’s domain only
|
||
|
||
This is the key isolation step.
|
||
|
||
Set the application’s authorized domains to only that client’s domain. If you leave the authorized-domain list blank, Maileroo can allow sending from any verified domain in the account, which is not what you want for agency isolation.
|
||
|
||
For example, Acme Plumbing’s application should only allow:
|
||
|
||
- `acmeplumbing.com`, or
|
||
- `mg.acmeplumbing.com`
|
||
|
||
### 5. Create that client’s sending credentials
|
||
|
||
Generate a sender key or API credentials for that client/domain.
|
||
|
||
Best practice:
|
||
|
||
- One credential set per client/site.
|
||
- Store credentials in your password manager.
|
||
- Name them clearly, such as `Acme Plumbing - WP Production`.
|
||
|
||
Do not reuse the same key across multiple clients.
|
||
|
||
### 6. Connect WordPress using API if possible
|
||
|
||
For WordPress, use a plugin that supports Maileroo.
|
||
|
||
Preferred order:
|
||
|
||
1. Maileroo API.
|
||
2. Maileroo SMTP.
|
||
3. Avoid host SMTP.
|
||
|
||
API-based delivery is the cleanest option because it reduces the setup friction that often happens with server SMTP.
|
||
|
||
### 7. Set the From address correctly
|
||
|
||
Use a real address on the authenticated client domain, such as:
|
||
|
||
- `website@client.com`
|
||
- `noreply@client.com`
|
||
- `forms@client.com`
|
||
|
||
Do not use a Gmail address or an address from another domain.
|
||
|
||
For form notifications, keep the actual From address authenticated, and use Reply-To for the visitor’s submitted email if needed.
|
||
|
||
### 8. Send a test email before wiring the contact form
|
||
|
||
Before connecting the form plugin, send a plain WordPress test email.
|
||
|
||
Test it to:
|
||
|
||
- Your agency inbox.
|
||
- The client inbox.
|
||
- A Gmail address.
|
||
- An Outlook or Microsoft 365 address.
|
||
|
||
This catches authentication problems early.
|
||
|
||
### 9. Connect the contact form
|
||
|
||
Once mail delivery is working, build the contact form in WordPress using Contact Form 7, WPForms, or another form plugin.
|
||
|
||
The form should:
|
||
|
||
- Send notifications to the client’s chosen inbox.
|
||
- Use the authenticated domain as the From address.
|
||
- Use Reply-To for the visitor’s email if needed.
|
||
|
||
### 10. Document everything
|
||
|
||
Save the following for each client:
|
||
|
||
- Maileroo Application name.
|
||
- Verified domain.
|
||
- DNS records added.
|
||
- Sender/API key name.
|
||
- WordPress plugin used.
|
||
- From address.
|
||
- Notification recipient.
|
||
- Date tested.
|
||
- Who owns DNS access.
|
||
|
||
This is what makes the setup repeatable later.
|
||
|
||
---
|
||
|
||
## Isolation Rules
|
||
|
||
Use these rules on every client:
|
||
|
||
- One Application per client.
|
||
- Authorized domains set explicitly.
|
||
- One credential set per client/site.
|
||
- Never reuse API keys across clients.
|
||
- Use separate From addresses per client.
|
||
- Keep credentials in a shared password manager grouped by client.
|
||
- Rotate keys when a site is rebuilt, migrated, or handed off.
|
||
|
||
---
|
||
|
||
## Suggested Naming Convention
|
||
|
||
A simple naming system helps a lot:
|
||
|
||
- Application: `Client Name - Website - Prod`
|
||
- Domain: `mg.clientdomain.com`
|
||
- From address: `website@clientdomain.com`
|
||
- Key: `Client Name - WP Mail - Prod`
|
||
|
||
Use the same pattern for every client so the setup stays easy to audit.
|
||
|
||
---
|
||
|
||
## Internal SOP
|
||
|
||
Here is the shortest version of the workflow:
|
||
|
||
1. Create a Maileroo Application for the client.
|
||
2. Add the client sending domain and verify SPF, DKIM, and DMARC.
|
||
3. Restrict the Application to that authorized domain only.
|
||
4. Generate that client’s sender/API key.
|
||
5. Install Post SMTP or the Maileroo plugin on WordPress.
|
||
6. Connect via Maileroo API first, SMTP second.
|
||
7. Set the From address on the same authenticated domain.
|
||
8. Send test emails.
|
||
9. Hook up the form plugin.
|
||
10. Save all setup details in your internal client record.
|
||
|
||
---
|
||
|
||
## Important Caveat
|
||
|
||
New Maileroo accounts may begin in Test Mode, where sending is limited until the required production steps are completed, including adding a domain. Make sure your agency’s main account is fully production-ready before onboarding multiple clients.
|
||
|
||
---
|
||
|
||
## Practical Recommendation
|
||
|
||
If you are standardizing this for an agency, use this as the default model:
|
||
|
||
- One agency Maileroo account.
|
||
- One Maileroo Application per client.
|
||
- One verified sending domain per client.
|
||
- One API key per client.
|
||
- One WordPress mail configuration per site.
|
||
- Separate credentials, separate domains, no sharing.
|
||
|
||
That gives you a clean, low-volume, low-maintenance system for many client sites.
|