Email

Email on CloudPress is two systems, not one feature with two halves. They sit at different levels — one on the workspace, one on a single site — they are provisioned by different paths, and neither holds a reference to the other. A fault in one is never fixed by touching the other.

Two systems, not one

The dividing line is authorship: a human composing a message needs Mailspace, a site emitting one needs Transactional Email.

flowchart LR
    person([A person]) --> mbox["Mailspace<br/>mailbox"]
    mbox -->|reads / sends| world([The internet])
    wp["WordPress site"] -->|password resets,<br/>order confirmations| relay["Transactional Email"]
    relay --> world
    mbox -.->|belongs to| ws[["Workspace"]]
    relay -.->|belongs to| site[["One site"]]

Both can serve the same domain at once — mailboxes for your people, transactional sending for the site. See Running both on one domain for the one place they meet.

How each one is switched on

Whether either feature exists at all is decided platform-wide. Neither is a workspace setting and neither is a plan entitlement, so if one is absent there is no toggle in your settings to find and no upgrade that produces it. Transactional Email in particular looks like it should be per-plan, because it is scoped per site — but scope and availability are different axes: one site, whole installation.

Mailspace: mailboxes for a domain

A mailspace is ordered against a domain and lives at the workspace level, alongside your sites rather than inside one. It holds the whole addressing layer for that domain: mailboxes, aliases, groups, mailing lists, and masked addresses you can hand out and throw away.

Because serving a domain means we start accepting mail as that domain, the mailspace is not created on the mail server until we have confirmed you control the name. Until then it sits in the list with an Awaiting verification badge and its own pages aren't available.

One mailspace can serve several domains — the primary it was ordered for, plus secondaries added later. Each carries its own mail DNS and is tracked separately.

For everything you actually do with a mailspace, the Mailspace guides cover it end to end — from ordering and verifying the domain through mailboxes, aliases, groups and masked addresses, mailing lists, rules and out-of-office replies, mail clients, logs and storage.

Transactional Email: what a site sends by itself

There is nothing to order. Activating a site enqueues provisioning of a sending account for it, and while that is still running the site's Transactional Email section says so rather than showing empty charts. It has three pages in the site's sidebar:

The account is keyed to the site's primary domain, and the stored signing key records which domain it was issued for. Promote a different domain and the account is re-keyed: a fresh signing key is minted and the authorising DNS rewritten, because a key issued for the old domain fails at receivers.

Suspension, and why it happens

A sending account can be suspended, and where you see that depends on the page. The Overview opens with a red banner giving the date and the reason, and no more. Log Search shows nothing at all — a suspended account looks like an ordinary quiet one there. The full picture is at the bottom of DNS Setup: the suspension card with the unblock control, and, when there is one, the triggering message with its event type shown as a Spam complaint, a Hard bounce, or Dropped. That is the only page that loads the triggering event, so it is where a suspension is diagnosed.

Suspensions come from two directions and behave differently:

• Sending-reputation suspensions you can lift yourself. The card offers an Unblock account button and states how many unblocks remain — the allowance is two per 30-day period, and the window resets rather than topping up gradually. Once spent, the button is replaced by You have reached the self-unblock limit. Please contact support.
• Suspensions the platform applies — currently Site deleted and Payment overdue — offer no button at all. They are released automatically when the underlying situation is: restoring the site, or settling the invoice. Neither consumes a self-unblock.

DNS: who writes the records

Both systems need DNS on the domain, and for both, one variable decides who writes it: do we host that domain's DNS zone?

Three details worth knowing:

• Hosting the zone is what counts, not delegation. A zone we host whose nameservers still point elsewhere is treated as ours and gets its records written, ready for the cutover. On the transactional side that in-between state gets its own notice — Your domain's nameservers haven't fully propagated… — rather than being mistaken for external DNS.
• We write alongside, not over. Where a name may legitimately hold several records — the apex mail exchangers, the mail-host CAA — ours is added next to whatever is there. Where only one record may occupy a name, such as the mail host or a signing selector, and something we didn't write is sitting there, the mailspace side writes nothing and records a conflict instead: overwriting a signing key you still use elsewhere would break mail that is currently flowing. The visible effect is that the record stays reported as wrong or missing until you remove the old one.
• One record is an exception to that. When transactional DNS setup needs to publish a changed signing key, it creates the new record at mailchannels._domainkey and then deletes every other record at that exact name, without checking who wrote it — yours or another provider's. It is a name we define ourselves, so in practice nothing else is there; if you do publish something there, expect it not to survive.

Mail authentication

Both systems check their own DNS continuously and both surface a verdict, but they cover different record sets and grade them on different vocabularies.

Mailspace puts a Mail Authentication card on the mailspace Overview. It loads a moment after the rest of the page because it runs a live DNS query rather than reading a stored verdict, and it covers six rows:

Each row grades ✓ Detected, ! Mismatch, ✕ Not found, Unknown or Not checked; an absent optional record reads Optional rather than as a fault, and a domain with no CAA policy passes, because no policy means any authority may issue.

The row that earns its keep is Mismatch. These checks compare values, not presence, and a mismatch is graded as a failure — which is what catches the two states a presence check waves through: mail routed to a different provider, and a signing key that was rotated but never republished.

Transactional Email puts a DNS Health card on its Overview covering three rows — SPF, DKIM, and Lock, the _mailchannels domain-lockdown record that pins sending on the domain to your account specifically. Each reads Verified, Failed or Pending, where Pending is the fallback for anything not yet confirmed rather than a diagnosis. The same three appear with their exact values on DNS Setup.

Running both on one domain

The two systems can serve one domain at once, and the one place they meet is the place DNS most easily goes wrong.

• They share one SPF record, necessarily. A domain may publish only one v=spf1 record — a second is a permanent error that voids the check for the whole domain — and both systems route outbound mail through the same relay, so both need the same authorisation present in it. Neither will ever add a second.
• Only one of them merges into an existing record. On a zone we host, the mailspace reconcile splices its relay include: into whatever SPF record is already at the apex, preserving the rest of the policy — the single place either system edits a record it did not author. Transactional setup does not: if any v=spf1 record already exists at the apex it publishes nothing and leaves yours untouched.
• They sign with separate keys. Each publishes under its own selector name, and the mailspace side prunes only selectors it published — third-party keys are left alone. The exception is the transactional selector described above.
• The lockdown record belongs to Transactional Email alone. Mailspace publishes no equivalent, so there is no competing value.

Related reading

• Transactional Email — the site-level pages step by step.
• Mailspace guides — ordering, verification, mailboxes, aliases, lists, rules, clients, logs and storage.
• Managing DNS — adding and editing records, whether we host the zone or you do.
• Deleting and restoring a site — what happens to a site's sending while it's pending deletion.
• Workspaces — why a mailspace belongs to the workspace and a site's sending doesn't.
• Mailspace API — listing, ordering, resizing and deleting mailspaces programmatically.