Documentation / Domains and DNS / MX Records

MX Records

Practical PanelConfig guidance for MX Records, with safe workflow, clear records, and operational review notes.

MX Records 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. DNS work should be handled with clear zone ownership and conservative TTL changes because external propagation is not immediate.

Usage

Use this guide when you are configuring, reviewing, or troubleshooting mx records for a hosting provider, agency, reseller, or customer account. It is useful during initial setup, operational handover, incident review, and routine maintenance.

Workflow

  1. Open the related PanelConfig page: PCAdmin > Domains, DNS, Subdomains, Redirects; PCUser > Domains and DNS.
  2. Confirm the account, domain, user, or server context before changing anything. In provider environments, many records have similar names.
  3. Review current status, ownership, package limits, and any pending jobs before making a change.
  4. Make the smallest safe change first. For destructive or customer-visible operations, keep a ticket or internal note with the reason.
  5. Re-check the page, job queue, audit log, and any affected service status after the operation completes.

Checklist

CheckWhy it matters
OwnershipPrevents changes on the wrong customer, reseller, or hosting account.
Current statusAvoids repeating an action that is already pending, suspended, queued, failed, or completed.
Limits and dependenciesShows whether package limits, DNS state, storage, service health, or credentials affect the result.
Audit trailGives support and operations teams a reliable record of who changed what and why.

Related

PCAdmin: PCAdmin > Domains, DNS, Subdomains, Redirects; PCUser > Domains and DNS

PCUser: PCUser > Domains, DNS, Subdomains, Redirects

Related PCCLI: php cli/pc dns:records

Records

Typical records involved: domains, dns_zones, dns_records, nameserver_settings, domain_events, subdomains, redirects, audit_logs. 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 dns:records

Related

php cli/pc dns:zones

← A Records TXT Records →