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 newly launched site saves contact requests but the owner reports missing email.
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: Sending from an unverified domain can reduce delivery.
Illustrative situation
Illustrative scenario, not a customer case study: A newly launched site saves contact requests but the owner reports missing email. The event reaches the expected mailbox and failure state is visible.
Choose the approach
Trace one named test event end to end through WordPress and mail provider. 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
Record sender, recipient, event and timestamp
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Record sender, recipient, event and timestamp; exact site identity, named approver and controlled sample data.
- Action
- Select one form or order message and record originating event, sender, recipient and timestamp.
- Expected result
- The trace has a unique marker.
- Verify
- The trace has a unique marker. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If no event record exists, first verify the application action actually saved.
Sources: WordPress roles and capabilities · xCloud WordPress site email with an SMTP provider
Step 2 of 5
Inspect configured WordPress mail integration and dns
- Where
- xCloud Email Config and SMTP provider account
- Permissions
- Named xCloud team/site administrator; confirm target and scope.
- Inputs
- Inspect configured wordpress mail integration and dns; exact site identity, named approver and controlled sample data.
- Action
- Inspect xCloud Email Config, chosen provider credentials and sender-domain DNS with the authorized account owners.
- Expected result
- The configured route and domain identity are visible.
- Verify
- The configured route and domain identity are visible. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If domain authentication fails, correct DNS before repeating delivery tests.
Step 3 of 5
Send a controlled form or order message
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Send a controlled form or order message; exact site identity, named approver and controlled sample data.
- Action
- Trigger a controlled message through the real WordPress action, not a standalone SMTP button alone.
- Expected result
- The application creates an outbound event.
- Verify
- The application creates an outbound event. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If WordPress never calls the mail integration, inspect plugin configuration.
Sources: WordPress roles and capabilities · xCloud WordPress site email with an SMTP provider
Step 4 of 5
Check provider log, mailbox and spam handling
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Check provider log, mailbox and spam handling; exact site identity, named approver and controlled sample data.
- Action
- Compare provider acceptance/rejection log with the inbox and spam folder, using the unique marker.
- Expected result
- Delivery result has evidence from both ends.
- Verify
- Delivery result has evidence from both ends. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If provider accepts but inbox lacks it, inspect suppression and recipient filtering.
Sources: WordPress roles and capabilities · xCloud WordPress site email with an SMTP provider
Step 5 of 5
Assign bounce monitoring and alternate contact method
- Where
- xCloud Email Config and SMTP provider account
- Permissions
- Named xCloud team/site administrator; confirm target and scope.
- Inputs
- Assign bounce monitoring and alternate contact method; exact site identity, named approver and controlled sample data.
- Action
- Assign a bounce-monitoring owner and manual contact alternative; retest after plugin or provider changes.
- Expected result
- The business can handle delayed mail.
- Verify
- The business can handle delayed mail. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- Do not restore a WordPress database as a substitute for fixing SMTP delivery.
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: The event reaches the expected mailbox and failure state is visible. 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 site mail fails, preserve the originating application record and inspect SMTP provider, sender-domain settings, rejections and mailbox filters. Correct the approved configuration and retest; an old WordPress database 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: Trigger a controlled message through the real WordPress action, not a standalone SMTP button alone.
- The business owner compares the controlled sample with this observable result: Delivery result has evidence from both ends.
- 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): The event reaches the expected mailbox and failure state is visible. Check provider log, mailbox and spam handling
- recovery (covered): Sending from an unverified domain can reduce delivery. Assign bounce monitoring and alternate contact method
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