What it does
Every email WPClientHub sends to your clients already carries your agency’s name, and replies go to your support address — but the address underneath is ours. With client emails from your own domain they come from an address at your domain instead, for example Brightleaf Support <support@brightleaf.agency>, signed for your domain so inboxes show it without a “via” line.
It covers every client email:
- Client reports — scheduled and on-demand deliveries with the PDF attached;
- Help desk sign-in links and client portal invitations;
- Request updates — a request’s status changing for the client;
- Estimates and the reminder two days before one expires;
- Invoices and payment reminders from the Billing Suite.
Emails to your team — alerts, digests, help desk notifications, invitations — and emails from WPClientHub itself never change: they always come from WPClientHub.
It is part of Agency and Scale (the 14-day Agency trial includes it).
Before you start
- An address at a domain you control, such as
support@orhello@at your agency’s domain. Make it a real mailbox: some clients reply to the email rather than to the Reply-To address. Addresses at Gmail, Outlook.com, Yahoo and other mailbox providers can’t be used — only those providers can sign mail from their domains. - Access to the domain’s DNS — wherever its nameservers point: Cloudflare, GoDaddy, Namecheap, your web host, or your registrar.
- About ten minutes, plus however long your DNS host takes to publish changes (usually minutes).
Set it up
- Go to Settings → Email sending.
- Enter the sending address and the display name your clients should see, and press Add domain. We create a signing key for your domain with our sending provider.
- Add the DNS records the page shows (see The DNS records). Each has a Copy button for its name and value.
- Press Check now. As soon as the required DKIM record checks out, client emails switch to your address by themselves — there is nothing else to switch on.
- Press Send a test email: it goes to you through exactly the same steps as a client email. Open its original headers in your mail app and look for
dkim=passwith your domain.
Until the records are verified, nothing changes for your clients: emails keep coming from our address with your name, replies to you. We re-check a new domain every hour for its first week, so you can add the records and walk away.
The DNS records
The page shows the exact values for your domain. They look like this:
| Record | Type | Name | Value | Needed? |
|---|---|---|---|---|
| DKIM | TXT | 20261007120000pm._domainkey | k=rsa;p=MIGf… (your key) | Required |
| Return-Path | CNAME | pm-bounces | pm.mtasv.net | Recommended |
| SPF | TXT | @ | your SPF record with include:spf.mtasv.net merged in | Recommended |
| DMARC | TXT | _dmarc | v=DMARC1; p=none; if you have none | Recommended |
We send through Postmark, which is why the values mention mtasv.net.
DKIM (required)
A public key that lets receiving servers check that an email really was sent for your domain and wasn’t changed on the way. It is the one record that decides when client emails switch to your address: we only ever put your domain in the From line when this key is published and our sending provider has confirmed it.
Return-Path (recommended)
A CNAME that gives bounces a home on your domain (pm-bounces.yourdomain). Receivers check SPF against this host, so with it in place SPF passes for your domain, not just for ours — both checks then line up with your From address (what DMARC calls alignment). Emails switch over without it, because DKIM alone already satisfies DMARC, but add it: it helps with the stricter inboxes.
SPF — one record, never two
SPF lists the services allowed to send for your domain. A domain may have only one SPF record: with two or more, receivers treat SPF as broken for every email from your domain, including the ones from your own mailbox. So we never tell you to “add an SPF record” when you already have one — we show your record with ours merged in, just before its all:
| Your SPF record today | What to change it to |
|---|---|
| none | v=spf1 include:spf.mtasv.net ~all (a new record) |
v=spf1 include:_spf.google.com ~all | v=spf1 include:_spf.google.com include:spf.mtasv.net ~all |
v=spf1 mx include:spf.protection.outlook.com -all | v=spf1 mx include:spf.protection.outlook.com include:spf.mtasv.net -all — your -all is kept |
already includes spf.mtasv.net | nothing to do |
| two SPF records | one record with every entry from both, plus ours — and delete the others |
The 10-lookup limit. Each include, a, mx and redirect costs DNS lookups when a receiver evaluates your record, and SPF allows at most 10 in total — past that, SPF fails for all your mail. We count them (following every include) and warn you when the merged record would go over. If it would, skip our include: with the Return-Path record in place your client emails pass SPF anyway. Or remove includes for services you no longer use.
SPF is “Recommended” rather than required because Postmark checks SPF on the Return-Path host, not on your root domain.
DMARC (recommended, never blocks)
DMARC tells receivers what to do with mail that claims to be from your domain but fails both DKIM and SPF, and where to send reports. If you have none, we suggest starting with v=DMARC1; p=none;, which only monitors: nothing is rejected or sent to spam because of it. Gmail and Yahoo expect a DMARC record from domains that send a lot of mail, and it is what eventually lets you stop others sending as you (p=quarantine, then p=reject). If you already have one, we show it and leave it alone. A missing DMARC record is a warning, never a reason to hold your emails back. Two DMARC records cancel each other out — keep one.
Adding the records at your DNS host
Use the Name exactly as shown. Most DNS hosts add your domain to the end of the name by themselves, which is why the page shows the short form (pm-bounces, not pm-bounces.yourdomain.com); the full name is shown underneath for hosts that want it. @ means the domain itself. Paste TXT values without surrounding quotes unless your host asks for them.
- Cloudflare: DNS → Records → Add record. Choose the type, paste the name and value. For the CNAME, switch Proxy status to DNS only (grey cloud) — Cloudflare proxies new CNAMEs by default, and a proxied CNAME can’t be seen from outside, so it never verifies. To change your SPF record, edit the existing TXT record that starts with
v=spf1rather than adding a new one. - GoDaddy: My Products → your domain → DNS → Add New Record. Pick TXT or CNAME, put the short name in Name (GoDaddy adds the domain), the value in Value, leave TTL at its default. For SPF, use the pencil icon on the existing
v=spf1TXT record. - Namecheap: Domain List → Manage → Advanced DNS → Add New Record. Choose TXT Record or CNAME Record, short name in Host, value in Value / Target, TTL Automatic. If your domain uses Namecheap’s email forwarding, keep its SPF include when you merge ours in.
- Anywhere else (a web host’s DNS zone editor, your registrar): the same three fields — type, name, value. If the name field already shows your domain after it, type only the part we show.
Changes usually show up within minutes; some hosts take a few hours. Press Check now whenever you like.
Checking and status
Each record shows one of:
| Status | Meaning |
|---|---|
| Verified / Found | The record is there with the right value. |
| In DNS — confirming | We can see it; our sending provider hasn’t confirmed it yet (usually a few minutes). |
| Waiting / Not found | Not published yet, or not visible yet. |
| Failing | Something is there but wrong (a different key, two SPF records), or the record was verified and has gone. |
The domain as a whole is Waiting for DNS until DKIM is verified, then Verified; if DKIM breaks later it becomes Failing. A DNS lookup that times out is never read as “missing”: the record keeps its last status and is checked again. Pending domains are checked hourly for their first week, then daily; verified domains daily; failing ones hourly.
What happens if DNS breaks
Records go missing more often than you’d think — a move to a new DNS host, a cleanup of “old” records, a Cloudflare import that skipped one. When a check finds the DKIM record gone or wrong:
- Straight away, client emails go back to our address — your agency’s name in the From line, Reply-To your address — so nothing is ever sent from your domain unsigned, and nothing lands in spam because of it.
- Ten minutes later we look again. If it is still broken, owners, admins and techs with domain alerts on get one email (and your Slack or webhook routes, if you set them up) saying which record and what to put back. A blip that fixed itself alerts nobody.
- Once the record is back, the next check — hourly while it is failing, or Check now — verifies it and client emails return to your address by themselves.
Every change of state is written to the Activity Log.
What your clients see
What your clients see on the settings page lists every client email with the From and Reply-To it would carry if it were sent right now:
- From: your display name and sending address once verified; until then, and whenever the domain isn’t usable, your agency’s name at our address.
- Reply-To: the reply-to address you set for the help desk (Help Desk settings) or for reports (Settings → Organization), when it differs from the sending address. With no reply-to address set, replies go straight to the sending address.
The display name applies to every client email, including reports from a template with its own brand name.
Plans and downgrades
Client emails from your own domain are part of Agency and Scale, and of the Agency trial. On Free and Studio, Settings → Email sending shows what it does and an upgrade link; client emails come from our address with your name and replies to you.
If your plan drops below Agency — or the trial ends — client emails go back to our address at once. Your domain, its key and its records are kept (shown as Paused) and used again as soon as you’re back on Agency. Nothing is deleted at our sending provider until you press Remove.
Who can change it
| Role | Email sending |
|---|---|
| Owner, Admin | Add, change or remove the address, check the records, send a test email |
| Tech, Viewer | See the address, the records and their status |
Limits & defaults
| Setting | Default |
|---|---|
| Plans | Agency, Scale (and the Agency trial) |
| Sending addresses | One per workspace; any address at the same domain can replace it without new records |
| Display name | Up to 70 characters, plain text |
| A domain | Can be used by one WPClientHub workspace |
| Required records | DKIM |
| Re-checks | Hourly for a new domain’s first week, daily once verified, hourly while failing |
| Alert after a break | After a second check 10 minutes later; once per incident |
| Test emails | 5 per 10 minutes per workspace |