Requirements and responsibilities
Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: A store owner notices order emails are inconsistent after the site goes live.
xCloud agent capability boundaries · WordPress roles and capabilities
Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.
xCloud agent capability boundaries · WordPress plugin administration
Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: A successful form or order save does not prove message delivery.
Illustrative situation
Illustrative scenario, not a customer case study: A store owner notices order emails are inconsistent after the site goes live. A test event is recorded and reaches both intended customer and staff inboxes.
Choose the approach
Choose a supported mail delivery provider and sender domain using its own documentation. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · WordPress roles and capabilities · WordPress native automatic update settings
Keep application setup, domain/DNS ownership, mail delivery and external integrations with their named administrators. Use a plain documented path when a proposed integration cannot be demonstrated end to end.
xCloud agent capability boundaries · WordPress plugin administration
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Map transactional events
- Where
- WordPress public pages and relevant external provider
- Permissions
- Named WordPress or app administrator; business owner signs results.
- Inputs
- Owner, hostname, approved requirements, sample record and decision date. Map transactional events.
- Action
- List WordPress events that send mail: contact submissions, password reset and any store or membership notices. Name sender domain, recipient and originating record for each.
- Expected result
- The site has a test matrix for messages.
- Verify
- The owner confirms which event reaches which mailbox.
- If it fails
- If a message has no owner, keep a visible alternate contact path.
Sources: WordPress roles and capabilities · xCloud WordPress site email with an SMTP provider
Step 2 of 5
Inspect sender configuration
- Where
- xCloud Email Provider and site Email Config dashboard; SMTP provider account
- Permissions
- Named SMTP provider and xCloud email administrator; keep credentials private.
- Inputs
- Target team/site, server or plugin version, license and documented prerequisites. Inspect sender configuration.
- Action
- Inspect the WordPress mail plugin, provider account and DNS sender records with authorized access. Determine whether the site uses default PHP mail or a configured transactional service.
- Expected result
- The delivery path and domain owner are known.
- Verify
- Record provider, sender address and DNS status without exposing credentials.
- If it fails
- If the domain is unverified, resolve DNS ownership before production mail.
Step 3 of 5
Configure the mail provider
- Where
- xCloud Email Provider and site Email Config dashboard; SMTP provider account
- Permissions
- Named SMTP provider and xCloud email administrator; keep credentials private.
- Inputs
- Approved change scope, backup state, selected version and maintenance window. Configure the mail provider.
- Action
- Use the chosen provider's documented WordPress integration. Keep credentials and suppression settings with a named administrator.
- Expected result
- A controlled test event is accepted by the provider.
- Verify
- Match a unique WordPress event timestamp to the provider acceptance log.
- If it fails
- If rejected, inspect authentication or API errors before changing page copy.
Step 4 of 5
Trace the delivered message
- Where
- WordPress public pages and relevant external provider
- Permissions
- Named WordPress or app administrator; business owner signs results.
- Inputs
- Test accounts, sample content or transaction, expected result and provider access. Trace the delivered message.
- Action
- Trigger a sample form or sandbox order and inspect destination inbox, spam folder and provider trace. Compare sender, subject and recipient.
- Expected result
- The intended person receives a usable message.
- Verify
- The recipient identifies the unique test marker and originating record.
- If it fails
- If the app saved data but mail failed, treat delivery as failed and use manual follow-up.
Sources: WordPress roles and capabilities · xCloud WordPress site email with an SMTP provider
Step 5 of 5
Assign failure handling
- Where
- xCloud Email Provider and site Email Config dashboard; SMTP provider account
- Permissions
- Named SMTP provider and xCloud email administrator; keep credentials private.
- Inputs
- Observed results, unresolved failures, backup point and owner contacts. Assign failure handling.
- Action
- Give staff a procedure for bounces, suppressions and delay, plus a fallback contact route. Include mail tests after plugin and theme updates.
- Expected result
- Mail issues have a response owner after launch.
- Verify
- Have the owner locate the provider log for the latest controlled event.
- If it fails
- If delivery evidence is unavailable, repeat the integration test before relying on it.
Maintenance
Assign a cadence for selected WordPress core, theme and plugin updates, review version-based findings and retest the path in this guide. In particular, repeat: A test event is recorded and reaches both intended customer and staff inboxes. A chat prompt is not a scheduled task.
Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud
Record actual backup completion, storage access and responsible staff. Recheck connected application and provider behavior after changes rather than relying on a site health status alone.
Recovery decisions
If transactional mail fails, preserve the originating order, form or account event. Have the provider and xCloud email administrators check SMTP credentials, sender-domain records, provider rejection and suppression logs; retest with a marked message. A WordPress database restore is not a mail-delivery repair.
AI handoff
Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.
Supported scope
- Confirm requirements and inspect resources mcp · read
Discover the connected profile and operation schema first; only teams granted to the connection are visible.
Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.
Operation identifiers and scopes to discover
teams.index, servers.show, sites.show
Scopes: read:servers, read:sites
xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
- Review a WordPress business journey app · manual
Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence.
Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision.
- Configure WordPress site SMTP provider dashboard · manual
An authorized SMTP-provider account owner supplies its credentials and sender-domain setup; an xCloud administrator configures Email Provider and site Email Config in the dashboard. Mail delivery must be tested separately.
Checkpoint: Inspect provider acceptance and mailbox delivery for a marked event; never expose credentials to an agent response.
Copyable agent brief
Manual checkpoints
- The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Use the chosen provider's documented WordPress integration. Keep credentials and suppression settings with a named administrator.
- The business owner compares the controlled sample with this observable result: The intended person receives a usable message.
- Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage
- business-acceptance (covered): A test event is recorded and reaches both intended customer and staff inboxes. Trace the delivered message
- recovery (covered): A successful form or order save does not prove message delivery. Assign failure handling
Sources
- xCloud agent capability boundaries
- WordPress roles and capabilities
- WordPress plugin administration
- Site backups in xCloud
- WordPress hardening handbook
- xCloud MCP documentation and connection profiles
- WordPress native automatic update settings
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- xCloud WordPress site email with an SMTP provider