Question
Hey all,
I just wanted to see how everyone sets up SMTP for client sites. Currently, I’m creating an additional email in their cPanel, such as info@ or contact@, or an exisitng email if there is which they rarely use. Then, I set it up with the “Other SMTP” option in the Fluent SMTP plugin. However, for clients who use Google Workspace or O365, it’s a chore to log in to their O365 account and go through the setup process for Fluent or WP Mail SMTP to work as I can’t use Other SMTP option, and have to choose the O365 or GWorkspace option.
Now, I’m considering creating an account with SendInBlue or SendGrid. I would add each client’s domain to the account, complete the DNS verification and setup process, and then use that. Alternatively, should I create SendInBlue or SendGrid accounts on behalf of each client and set it up that way?
I’m unsure whether I should do it under my account or the clients’ accounts. I’m just trying to find the easiest, simplest, yet best and free way to do it. Thanks all!
https://www.reddit.com/r/Wordpress/comments/14nmemz/best_way_to_setup_smtp_for_clients_websites/
Answer
The questioner’s instinct to wonder whether the account belongs under the agency or under the client is the right framing. The client wins. The right default for a WordPress agency standardising SMTP across many client sites is one transactional provider account per client, opened on the client’s domain, with credentials held by the agency in a shared vault. The plugin side is FluentSMTP for all of them.
This is not the simplest choice on day one. It is the simplest choice on day 365, when one client has left for another agency and needs to take their sending pipeline with them, when another has had a contact-form bot blast a thousand messages and triggered a reputation hit, and when a third has asked for a deliverability audit and somebody needs to read their bounce logs separately from twenty other clients’ bounce logs. Per-client accounts isolate failure, isolate handover, and isolate billing without making the agency’s day-to-day operation meaningfully more painful.
The four real architectures for this problem each fail a different test. The walkthrough below names them, says where each works, and says where each breaks.
The four architectures
1. Per-client provider account on the client’s domain (recommended)
Each client gets their own SMTP2GO, Brevo, Postmark, or Amazon SES account. The account is registered against the client’s domain and their billing email (a billing@ or accounts@ address on the client’s domain, not the agency owner’s Gmail). The agency stores the login credentials and the SMTP/API keys in a shared password vault entry tagged to that client. The SMTP plugin on the client’s WordPress install connects to the per-client account.
Where it works: every common agency case. Low-volume marketing sites on a free tier. Mid-volume WooCommerce stores on a Postmark or Brevo paid plan. Sites whose deliverability is operationally important enough that they need their own bounce stream and their own complaint dashboard. Provider reputation segmentation is per-account on shared IPs and total on dedicated IPs, which makes per-account isolation the operative unit regardless of plan tier.
Where it breaks: the setup cost on day one (~20 minutes per client for account creation, domain verification, DKIM and SPF records, FluentSMTP connection, test send) and the small subset of clients whose legal or procurement processes prevent an external account being opened on their behalf. The setup cost is paid once per client and never again. The procurement case is rare in the SMB market most WordPress agencies serve and is handled by switching to Architecture 2 for that one client.
2. One agency-wide account, every client’s domain added as a verified sender
A single Brevo or Postmark account, owned and paid for by the agency, with each client’s domain added as an additional verified sending domain. One bill, one console, one IP reputation history. The agency builds it into their retainer pricing as a flat per-site fee.
Where it works: agencies with a standardised pricing model who absorb the email cost and never expect a client to leave. The model is most defensible at agencies that explicitly white-label hosting and email as part of “managed WordPress” packages and have contracts that establish what happens to the email pipeline on offboarding.
Where it breaks: the handover. Extracting one client’s domain from an agency-owned Brevo or Postmark account into a new account they control is awkward. The DNS records change. The sending history is left behind, which matters for reputation at the recipient end. The DKIM key rotation has to be timed against the WordPress plugin reconfiguration, or mail breaks for a window. None of these are insurmountable, but each is a small operational tax that an agency on a per-client account model pays zero of.
The second failure mode is reputation cross-contamination. One client’s compromised contact form blasting 10,000 messages to nonexistent addresses produces a complaint rate spike against the shared IP. Every client on that account inherits the dip until it recovers. Per-client accounts confine the damage to the client who caused it.
3. The host’s mailbox plus the host’s SMTP (the questioner’s current setup)
A cPanel mailbox (info@, contact@) on the client’s hosting account, used as the SMTP login from the WordPress plugin’s “Other SMTP” connection. No transactional provider involved.
Where it works: a single-site freelancer running half a dozen WordPress installs on the same host for hobby projects or unbilled work, where the volume is genuinely tiny and the deliverability bar is “the form mostly goes through, and when it doesn’t, the client tells me and I fix it.”
Where it breaks: shared-hosting IPs have mediocre transactional reputation by default. The mailbox password is stored in plaintext in the SMTP plugin’s database, which is a credential-exposure footprint that scales linearly with the fleet. Setup is per-account-tedious in exactly the way the questioner describes. And it ties the WordPress site’s email reliability to the cPanel mailbox’s life-cycle: when the client renames their info address or rotates the mailbox password, the form silently stops working.
Authentication is the second problem. The host may or may not publish SPF and may or may not DKIM-sign on behalf of the customer’s domain. Gmail’s post-February-2024 sender requirements treat unauthenticated mail as junk-or-rejected, which means many of these setups produce silent deliverability failures the agency only learns about when a client mentions they are not receiving form notifications. See form-not-sending-mail-to-gmail-but-sending-to-office365 for what that failure looks like in practice, and DNS for WordPress email: SPF, DKIM, DMARC for the records that fix it.
4. Google Workspace or Microsoft 365 SMTP relay via a user mailbox
FluentSMTP’s first-party Gmail/Google Workspace and Outlook/Microsoft 365 connections use OAuth, not plaintext passwords, and route outgoing WordPress mail through the client’s Workspace or 365 tenant on a paid user’s authority. This is what the questioner means when they say the Workspace/365 case is a chore: the setup flow requires the user to log in through OAuth and authorise the connection per site.
Where it works: a single specific case. A client where transactional mail must come from a real staffed mailbox a human reads (a small B2B where the contact form goes to [email protected] and the reply chain is meant to look like a normal email exchange, not a transactional notification). The OAuth route preserves the appearance and the reply path.
Where it breaks: the per-mailbox sending limits, the licence cost, and the handover. Google Workspace caps a paid user at 2,000 unique external recipients per day (3,000 external recipients per day in total, counting duplicates) (
Google Workspace sending limits). Microsoft 365 (Exchange Online) caps a standard mailbox at 10,000 recipients per day with a 30-messages-per-minute throughput (
Exchange Online limits). These are larger numbers than most small-site contact forms produce, but they are sized for human use, not for transactional bursts. The next step up from a Workspace user mailbox is provisioning a relay-only mailbox or moving the workload to a transactional provider, which is Architecture 1 with extra steps. The licence cost (a Workspace or 365 user seat) is per-mailbox. And the handover problem is structural: the sending mailbox is tied to a person at the client.
Use it when the client specifically needs a human reply path on the same mailbox. Otherwise, route around it.
Provider picks for the recommended architecture
For per-client accounts under Architecture 1, four providers cover the common volume bands. All pricing verified June 2026; verify before standardising a fleet on a specific free tier, as the entry-level offerings shift.
| Provider | Free tier | Entry paid | Where it fits |
|---|---|---|---|
| SMTP2GO | 1,000 messages/month, no card | $10/mo for 10,000 messages | The default for low-volume client sites. Simple DNS, low ceremony, no marketing overlay. |
| Brevo | 300 messages/day (~9,000/month), shared across marketing and transactional | Tiered by daily limit | Where the client also has a marketing-email use case. The two sides share one account and one daily cap. |
| Postmark | 100 messages/month (Developer plan, non-expiring) | $15/mo for 10,000 messages | Where transactional mail must work. The cleanest reputation in the category. Worth it any time a dropped password reset or order confirmation has a real business cost. |
| Amazon SES | 3,000 messages/month for the first 12 months on new AWS accounts | $0.10 per 1,000 messages | Only for agencies already running AWS infrastructure. Per-client IAM access keys are clean if the agency is already managing IAM; the sandbox-exit process and bounce/complaint SNS plumbing are administrative weight otherwise. |
Resend, Mailgun, and SendGrid are reasonable too. They do not occupy a slot in the table because their pricing or positioning duplicates what one of the four above already covers for the agency use case. SendGrid in particular has changed its free-tier terms multiple times in the last three years; the current entry-level is a free trial, not an indefinitely-free allowance, which makes it a less safe default for a fleet than SMTP2GO or Brevo.
For the WordPress side, FluentSMTP is the right plugin across the fleet. It is free, has no upsell pressure, supports per-connection sender domains (so if Architecture 4 applies to one specific client, it sits alongside the Architecture 1 connections without a second plugin), and supports OAuth for the Workspace/365 case. WP Mail SMTP is fine and more widely installed; its Gmail / Google Workspace OAuth is free, but Microsoft 365 / Outlook OAuth and Amazon SES sit behind the Pro tier, and the upgrade prompts in the admin UI are constant. Post SMTP covers the same ground with a different feature emphasis (mobile alerting, multi-site monitoring) and is worth considering for an agency with a true multi-site estate.
Credentials and the handover playbook
The vault entry per client should contain: the provider login (the URL, the username, the password), the SMTP credentials or API key used in the plugin, the DKIM and SPF records as they were published, the date the domain was verified, and a short note on what changes if the client offboards.
What never lives in the vault: the agency owner’s personal Gmail account login. Using a Gmail address as the provider login because it is “easier” ties the client’s email pipeline to a person and produces an awkward conversation when that person leaves the agency. The client’s info@ or contact@ cPanel mailbox password also stays out, because that is Architecture 3’s failure mode imported into Architecture 1. Shared spreadsheets, Notion pages, and unencrypted notes are all wrong; a real password manager is the only acceptable substrate.
When a client offboards, the handover is the vault entry plus a single email: “Your A transactional email is the automated message a WordPress site sends in response to a single user action – a password reset, an order confirmation, a form receipt – addressed to the user who triggered it. Read full reference → account is at $PROVIDER under the login below. The DKIM and SPF records currently published on your domain authenticate this account. Logging in and changing the email address on the account transfers ownership; we will remove our access on confirmation.” That email is possible because the account was opened on the client’s domain in the first place. Under Architecture 2 it is not.
The flip side – a new client onboarding – is a 20-minute checklist:
- Open the provider account in the client’s name, with the billing email on the client’s domain.
- Verify the domain (the provider’s docs walk this; the records are listed under their own UI).
- Publish the DKIM and SPF records on the client’s DNS. See DNS for WordPress email: SPF, DKIM, DMARC for the canonical setup.
- Install FluentSMTP on the client’s WordPress site and configure the connection with the provider’s SMTP credentials or API key.
- Set “Force From Email” in FluentSMTP to an address on the client’s domain (
[email protected]or similar). This prevents WooCommerce and other plugins from overriding the From header with an unauthenticated address. - Send a test message and check it lands in the inbox at Gmail and Outlook/365. The WordPress email test suite is the canonical sequence.
- Write the vault entry.
If you only standardise on one thing
The single decision that determines whether an agency’s fleet-wide SMTP setup ages well is whose domain the provider account is registered against. Open every new client’s account on their domain, on their billing address, with the credentials held in the agency’s vault. The setup tax is 20 minutes once. The cost of getting it wrong is paid in every offboarding, every reputation incident, and every audit.