Black Friday: 50% off. Your first year on any annual plan, until 1 December. See the dealFirst year on annual plans, until 1 December
WPClientHub V2 is live. Fewer plugins on your client sites: caching, forms and image optimization now come built into WPClientHub One. See what’s newCaching, forms and images, built in. See what’s new
Sign in Start free

← Docs  /  Clients & Support portal

Client emails from your own domain

Updated 2026-10-07

Reports, help desk sign-in links, request updates, estimates and invoices from your agency’s own address — the DNS records, explained, and what happens if one breaks. Agency and above.

Browse documentation

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@ or hello@ 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

  1. Go to Settings → Email sending.
  2. 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.
  3. Add the DNS records the page shows (see The DNS records). Each has a Copy button for its name and value.
  4. 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.
  5. 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=pass with 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:

RecordTypeNameValueNeeded?
DKIMTXT20261007120000pm._domainkeyk=rsa;p=MIGf… (your key)Required
Return-PathCNAMEpm-bouncespm.mtasv.netRecommended
SPFTXT@your SPF record with include:spf.mtasv.net merged inRecommended
DMARCTXT_dmarcv=DMARC1; p=none; if you have noneRecommended

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 todayWhat to change it to
nonev=spf1 include:spf.mtasv.net ~all (a new record)
v=spf1 include:_spf.google.com ~allv=spf1 include:_spf.google.com include:spf.mtasv.net ~all
v=spf1 mx include:spf.protection.outlook.com -allv=spf1 mx include:spf.protection.outlook.com include:spf.mtasv.net -all — your -all is kept
already includes spf.mtasv.netnothing to do
two SPF recordsone 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=spf1 rather 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=spf1 TXT 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:

StatusMeaning
Verified / FoundThe record is there with the right value.
In DNS — confirmingWe can see it; our sending provider hasn’t confirmed it yet (usually a few minutes).
Waiting / Not foundNot published yet, or not visible yet.
FailingSomething 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:

  1. 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.
  2. 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.
  3. 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

RoleEmail sending
Owner, AdminAdd, change or remove the address, check the records, send a test email
Tech, ViewerSee the address, the records and their status

Limits & defaults

SettingDefault
PlansAgency, Scale (and the Agency trial)
Sending addressesOne per workspace; any address at the same domain can replace it without new records
Display nameUp to 70 characters, plain text
A domainCan be used by one WPClientHub workspace
Required recordsDKIM
Re-checksHourly for a new domain’s first week, daily once verified, hourly while failing
Alert after a breakAfter a second check 10 minutes later; once per incident
Test emails5 per 10 minutes per workspace

Troubleshooting

DKIM still says Waiting, but I added the record
Check the name: most DNS hosts add your domain themselves, so a name typed in full becomes pm._domainkey.yourdomain.com.yourdomain.com. Use the short name shown. Also check the value was pasted in one piece — some hosts split long values, which is fine, but a missing character is not. Then press Check now; changes can take up to a few hours to show.
The Return-Path CNAME is “Not found” on Cloudflare
It is probably proxied (orange cloud). Edit the record and switch Proxy status to DNS only (grey cloud); a proxied CNAME can’t be seen from outside Cloudflare.
It says I have two SPF records
Two records starting with v=spf1 make SPF fail for all mail from your domain, ours or not. Replace them with the single merged record shown, then delete the others.
My SPF record would need more than 10 lookups
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. Don’t add a second SPF record to get around the limit.
Will this affect our own mailbox (Google Workspace, Microsoft 365)?
No. The DKIM and Return-Path records use their own names and don’t touch your mailbox’s records, and the SPF change only adds our include to your existing record. Your mailbox keeps working exactly as before.
Can I use a Gmail or Outlook.com address?
No. Only Google or Microsoft can sign mail for gmail.com or outlook.com, so mail from those addresses sent by anyone else fails DMARC. Use an address at your agency’s own domain.
Client emails went back to your address
A required record stopped working, your plan dropped below Agency, or the domain is waiting for DNS. Settings → Email sending says which, and shows the record to fix. Replies still reach you meanwhile.