Publish the MX hosts and priorities supplied by the mail provider in PD DirectAdmin DNS. An MX record routes inbound mail towards a mail server; it does not create mailboxes or configure outgoing-message signing.

Prepare the complete mail configuration

Keep the current MX set and obtain the replacement provider’s exact hostnames, priorities and any supporting records. Confirm the destination mail service is ready before a cutover. An MX target is a mail-server hostname, not a mailbox address or web URL.

Update the zone

1. Open the intended zone’s Records view and filter for MX.
2. Review every current MX value at the affected name.
3. Add or edit each intended record using Name, Priority, mail-server hostname and TTL.
4. Remove obsolete destinations only as part of the agreed mail move.
5. Read back the full resulting MX set and the actual server-reported TTLs.

Lower numeric priority is preferred; equal priorities can offer multiple destinations. Leaving an old MX in place can continue routing some mail there. Review the mail provider’s complete intended set rather than treating one new row as a replacement for all existing values.

Check delivery

Verify authoritative MX answers and then test actual delivery after the expected cache transition. Confirm the mail hosts resolve and accept mail separately from DNS publication.

If DNS is correct but mail fails, retain a redacted bounce or delivery result for the mail administrator. Repeatedly changing MX does not repair a missing mailbox, relay restriction or signing problem. Use the SPF, DKIM and DMARC guide for sender-authentication records.

Verify the saved change

Read back the actual server values after saving. An edit adds the new value before removing the old one, so a failed removal can leave both values present. A requested TTL is not sent by this version of the module; see the TTL guide before relying on a TTL change.

See the PD DirectAdmin DNS WHMCS guide for related tasks, or explore the module.