Use PD AWS Route 53 DNS to publish the MX set supplied by your mail provider. MX controls where inbound mail is delivered; it does not create mailboxes, transfer existing messages or configure outbound authentication.

Prepare the complete mail destination

Collect every required MX target and priority from the provider for your domain. Review existing MX records and any planned mail cutover before replacing them. A generic example from another account may not be a valid destination for your tenant.

Open AWS Route 53 DNS → Zones, select the correct hosted zone and inspect its records. A customer can use My Tools in the client portal, then the DNS manager. Check that this zone’s nameservers are authoritative for the domain.

Publish and verify the set

1. Find the current MX records at the intended name.
2. Choose MX in the editor.
3. Enter the record name, TTL, priority and target mail-server hostname.
4. Save every required destination and preserve the intended priority order.
5. Reload and compare the full saved set with the provider’s instructions.
6. Verify authoritative DNS and the mail provider’s domain check, then test delivery to a controlled mailbox.

Lower numeric priority is preferred. Several MX values with different priorities can be deliberate. Do not leave an old mail provider mixed into the set unless the intended delivery design calls for it.

Separate DNS from mail-service failures

An MX target is a hostname, not a mailbox address or web URL. If it points to your own mail host, verify that host’s address record and mail service. A correct MX response alone is not proof that the receiving server accepts mail for the domain.

Route 53 does not add a Cloudflare-style proxy setting to these records. Keep provider-specific advice with the provider that actually supplies it.

If a save is refused, inspect its lock, policy, quota or AWS permission error. If mail still bounces after DNS is correct, retain the redacted bounce for the mail administrator. Use the SPF, DKIM and DMARC guide for authentication records.

Check same-named hosted zones before changes

If your AWS account contains multiple hosted zones with the same domain name, do not assume choosing a same-named row selects a particular hosted-zone ID. This module resolves zones by name. Have your AWS administrator compare the exact hosted-zone ID, records and delegated nameservers before using module writes; use AWS’s native zone-specific controls if the target remains ambiguous. Do not create or delete another zone to diagnose that ambiguity.

See the PD AWS Route 53 DNS Blesta guide for related tasks, or explore the module.