Aliases
Practical PanelConfig guidance for Aliases, with safe workflow, clear records, and operational review notes.
Aliases explains how this part of PanelConfig should be used in a production hosting operation. It focuses on practical decisions, audit visibility, and safe execution rather than marketing language. Email hosting combines account records with routing and authentication records; avoid exposing mailbox passwords in tickets or notes.
Usage
Use this guide when you are configuring, reviewing, or troubleshooting aliases for a hosting provider, agency, reseller, or customer account. It is useful during initial setup, operational handover, incident review, and routine maintenance.
Workflow
- Open the related PanelConfig page: PCAdmin > Email Hosting, Email Routing, Email Authentication, Email Templates; PCUser > Email modules.
- Confirm the account, domain, user, or server context before changing anything. In provider environments, many records have similar names.
- Review current status, ownership, package limits, and any pending jobs before making a change.
- Make the smallest safe change first. For destructive or customer-visible operations, keep a ticket or internal note with the reason.
- Re-check the page, job queue, audit log, and any affected service status after the operation completes.
Checklist
| Check | Why it matters |
|---|---|
| Ownership | Prevents changes on the wrong customer, reseller, or hosting account. |
| Current status | Avoids repeating an action that is already pending, suspended, queued, failed, or completed. |
| Limits and dependencies | Shows whether package limits, DNS state, storage, service health, or credentials affect the result. |
| Audit trail | Gives support and operations teams a reliable record of who changed what and why. |
Related
PCAdmin: PCAdmin > Email Hosting, Email Routing, Email Authentication, Email Templates; PCUser > Email modules
PCUser: PCUser > Email Accounts, Aliases, Forwarders, Filters, Routing, SPF/DKIM/DMARC
Related PCCLI: php cli/pc email:aliases
Records
Typical records involved: email_accounts, email_aliases, email_forwarders, email_filters, email_routing, email_auth_records, email_default_addresses, email_templates, webmail_sessions. Some actions only read these records, while write actions may update status fields, create queue records, write audit entries, or refresh timestamps. For integration-ready areas, do not assume an external provider action has completed until the local job and provider-side evidence agree.
Notes
Security and audit notes: use least-privilege access, avoid sharing raw credentials, keep customer-impacting changes tied to a reason, and review Audit Logs or Login History when an action affects authentication, access, DNS, mail flow, backups, SSL, firewall, WAF, or account status.
Troubleshooting
- If the page is empty, confirm the related database table exists and that the user role has permission to view the module.
- If a change appears stuck, check Jobs, Job Logs, and Services before repeating the operation.
- If an external dependency is involved, verify it independently: DNS propagation, ACME challenge visibility, remote backup storage, mail DNS records, or provider API state.
- If the result is sensitive or customer-visible, capture the exact timestamp, account id, domain, and operator before escalating.
Example
php cli/pc email:aliasesRelated
php cli/pc email:accounts, php cli/pc email:forwarders, php cli/pc email:routing, php cli/pc email:auth