Skip to content

Transactional email: the mail your site sends

Every WordPress site sends mail of its own — password resets, order confirmations, form notifications. In CloudPress that outbound traffic is handled by Transactional Email, a per-site feature with its own menu in the site's sidebar. This is the place to look when a customer tells you the password-reset mail from your site never arrived.

Transactional Email is not Mailspace

CloudPress has two separate email features. Picking the wrong one is the most common mistake here, so start with the difference.

Transactional Email Mailspace
What it is Outbound mail your WordPress site sends by itself Mailbox hosting — real mailboxes people sign in to and read
What it belongs to One site The workspace, not a site
Where you manage it The Transactional Email menu in a site's sidebar The Mailspace item in the workspace sidebar
Reach for it when Your site can't send password resets, order confirmations, or notifications You want you@yourdomain.com to receive mail

If what you actually want is mailboxes, aliases, or mailing lists, none of this page applies — see Mailspace instead.

Everything below is done in the dashboard. The same settings, send logs, usage figures and DNS re-check are also available over the REST API — see Site transactional email.

Before you start

  • The feature has to be switched on for the platform. It isn't a per-workspace setting and there's nothing you can enable yourself: when it's on, the Transactional Email menu appears on every site's sidebar; when it isn't, the menu is absent everywhere. If you can't see it, get in touch.
  • A domain attached to the site, if you want mail to be authenticated properly. Without one, the DNS screen has nothing to set up.
  • Nothing to order, nothing to turn on per site. The site's email account is created for you when the site is activated, and refreshed when you attach or change its domain.
  • Any member of the workspace who can open the site can read these screens. Lifting a block (below) additionally requires a role with edit permission on the site.

The three screens

Open the Transactional Email menu in the site's sidebar and you get three children:

Menu item What it's for
Overview Sending volume, delivery health, current usage, and the most recent messages
DNS Setup The three DNS records that authorise your domain to send, and their verification status
Log Search A searchable record of individual messages your site sent

The DNS Setup page calls itself Settings

The sidebar entry reads DNS Setup, but the page it opens is headed Settings. They're the same screen.

Read the Overview

Open the site's Transactional Email menu and choose Overview. What you see depends on the state of the site's email account:

  • While it's still being created, the page shows Setting up your email account — "Your transactional email account is being provisioned. This typically takes a few minutes."
  • If creating it didn't succeed, you get Transactional email not configured, with a button through to the DNS screen. That state won't clear on its own; contact support.
  • Once the account is live, the full dashboard renders.

On the live page you get:

  • Current Usage — a bar plus three figures: Billing Cycle (how far through the current monthly sending cycle you are, with its start and end dates), Current Usage (messages sent against the allowance included with the site's plan), and Projected Usage (that pace extrapolated to the end of the cycle). Resizing the site's plan updates the included allowance.
  • Last 7 days / Last 30 days / Last 90 days buttons that redraw everything below them.
  • Three trend cards — Emails Sent, Delivered, and Bounced — and a larger Email Volume chart.
  • DNS Health, a compact three-row summary of SPF, DKIM, and Domain Lockdown, with a DNS Records button through to the DNS Setup screen.
  • Recent Logs, the newest handful of messages, with View all → through to Log Search.

Set up DNS so your mail is trusted

Receiving mail servers will only trust mail sent on your domain's behalf if your DNS says they should. That's what the DNS Setup screen is for.

  1. Attach a domain to the site first. If the site has no domain, the screen shows No domain attached — "Add a domain to your site to set up DNS records and enable MailChannels email delivery" — with an Add a domain button. See Adding a domain to a site.

  2. Open Transactional Email → DNS Setup. The DNS Records card lists exactly three records, under the columns Type, Name, Value, and Status:

    Type Name Value
    SPF @ v=spf1 include:relay.mailchannels.net ~all
    DKIM mailchannels._domainkey v=DKIM1; k=rsa; p=… — the public key generated for your site, shown in full on the page with a copy button
    Lock _mailchannels v=mc1 auth=… — your site's own sender identifier

    All three are published as TXT records; the Type column labels them by their role rather than by their DNS type.

  3. Let CloudPress publish them, or add them yourself. If the domain's DNS is hosted in your workspace, the three records are created for you automatically — there is nothing to copy. If it isn't, the page says so: "Your domain uses external DNS. Add the records below manually to your DNS provider to enable MailChannels email delivery." Copy each row into your DNS provider. See Managing DNS for records hosted here.

  4. Wait for the Status column to catch up. Each row shows Pending, Verified, or Failed. CloudPress re-checks the records in the background, so a record you have just added turns Verified without any action from you. If you have only just pointed the domain at us, you may first see "Your domain's nameservers haven't fully propagated to Bunny DNS yet. DNS records will be verified automatically once propagation is complete."

An SPF record you already have is never overwritten

A domain may only carry one v=spf1 record, so if the apex already has one, CloudPress will not add a second — and the SPF row keeps reporting Failed until that existing record authorises the platform's relay itself. Fix it by editing your own SPF record to include include:relay.mailchannels.net, rather than adding another record.

Look up messages your site has sent

  1. Open Transactional Email → Log Search. Until the site's email account is live the page says "Log search will be available once your transactional email account is active."

  2. Pick a tab. Logs lists everything; Alerts narrows the same list to messages that were not delivered. With nothing wrong, the Alerts tab reads No issues found — "Your account is in good standing — no bounces, complaints, or drops detected."

  3. Filter, then search. Choose what to match on — Recipient, Sender, or Subject — type into the Search... box, optionally set a start and end date, and click Search. The search runs on the server, so results and paging always reflect the filters you submitted. Reset appears once a filter is active and clears them all.

  4. Read the results. Columns are Status, From, To, Subject, SMTP (on wider screens), and Sent at. Status is one of Delivered, Failed, Spam, or Unknown, and the SMTP column carries the response code the receiving server returned.

  5. Expand a row for the detail. The chevron at the end of a row opens SMTP response, Message ID, Size, and — when they apply — Spam disposition and Virus disposition.

  6. Page through longer result sets with Previous and Next; the footer reads "Showing {from}–{to} of {total}". Intermediate relay hops are filtered out of the table, so a page can hold fewer rows than that range implies.

How far back the log goes

With no filters set and nothing to show, the Logs tab reads "No log entries found for the last 3 days." The empty state also notes that "Sent emails appear here within a few minutes of delivery" — a message your site sent seconds ago may not be listed yet.

If sending gets blocked

CloudPress blocks a site's outbound mail when its recipients react badly to it. A single spam complaint blocks the account immediately. Hard bounces and dropped messages are tolerated in ordinary numbers and only block the account once the recent failures look like a list-quality problem rather than a typo.

A blocked account is unmistakable. The Overview page carries a red Account Suspended banner — "This email account was suspended on {date} (UTC). Reason: {reason}" — and the DNS Setup screen grows an Account suspended card showing Suspended Since and Reason. When the block was triggered by a specific message, a Triggering email card below it shows the Event type (Spam complaint, Hard bounce, or Dropped) along with its Date, From, To, Subject, and Detail.

To lift it yourself:

  1. Deal with the cause first. Clean the list, remove invalid addresses, and stop sending to people who did not ask for it — otherwise the next failure blocks the account again.

  2. Open Transactional Email → DNS Setup and find the Account suspended card.

  3. Click Unblock account, then confirm in the dialog with Yes, unblock my account. The card tells you how many attempts you have left: "{count} of 2 unblocks remaining this 30-day period". The allowance is two per rolling 30 days.

When the button isn't there, the card doesn't say why

Whenever self-unblocking isn't available, the Unblock account button and its remaining-attempts line disappear, and the card shows both messages together — "You have reached the self-unblock limit. Please contact support." and "Contact support to unblock your account." You get that same pair for every reason, so nothing on the screen distinguishes one situation from another. It may be that you have used both unblocks in the current 30-day window; or that this isn't a sending-behaviour block at all but a system hold, raised because the site is suspended over an unpaid invoice or is a deleted site sitting in its retention window; or that a further complaint arrived while another hold was in force and hasn't been dealt with yet. The Reason on the card is your only clue, and the remedy differs — settle the invoice, restore the site (see Deleting and restoring a site), or contact us.

Next steps