Use PD Azure DNS to publish the mail provider’s intended MX record set. MX defines inbound mail destinations; it does not create mailboxes or transfer existing messages between mail services.

Collect the full destination set

Obtain every required mail-server hostname and priority for your domain. Review existing MX records with the mail administrator before a cutover. Keep any tenant-specific targets exactly as supplied instead of copying a generic example.

Open the authoritative zone’s Records page under Azure DNS → Zones, or use My Tools in the client portal, then the DNS manager as the customer. A saved record in a different Azure group or undelegated zone will not change public mail routing.

Publish and check

1. Find the existing MX values at the intended name.
2. Choose MX in the type-aware editor.
3. Enter name, TTL, priority and mail-server target.
4. Save every required destination and review the complete set.
5. Reload and compare hostnames/priorities with the provider instructions.
6. Verify authoritative DNS, the provider’s domain check and controlled inbound delivery.

Lower numeric priority is preferred. Azure uses one TTL for the MX record set, rather than a different TTL per mail destination. Do not leave an old provider in the set unless the intended mail-delivery design requires it.

Diagnose delivery separately

The target is a hostname, not a mailbox address or URL. If you run the target mail host, check its address and service as well. A correct MX lookup does not prove that server accepts mail for this domain.

Azure DNS does not add another provider’s CDN proxy toggle to a mail record. Keep provider-specific controls with the actual backend.

If a save is refused, inspect its lock, policy, quota or Azure permission error. If DNS is correct but mail bounces, retain a redacted bounce for the mail administrator. Use the authentication guide for SPF, DKIM and DMARC; those records serve a different task from MX.

See the PD Azure DNS Blesta guide for related tasks, or explore the module.