Publish the mail provider’s complete MX set through PD Google Cloud DNS. MX selects inbound mail destinations; it does not create mailboxes, move stored messages or configure outbound signing.

Collect the intended mail route

Obtain every required destination and priority for your domain. Keep tenant-specific targets exactly as supplied and review any planned cutover with the mail administrator. Do not mix an old provider into the set unless the intended delivery design calls for it.

Open the authoritative managed zone’s records in the module, or use My Tools in the client portal, then the DNS manager. Check that the project and registrar delegation refer to the zone you are editing.

Publish and inspect

1. Find the current MX values at the intended name.
2. Select MX in the record editor.
3. Enter the name, TTL, priority and mail-server target.
4. Save all required destinations and preserve the intended priority order.
5. Reload and compare the complete set with the provider instructions.
6. Check authoritative DNS, the mail provider’s domain validation and controlled inbound delivery.

Lower numeric priority is preferred. Google Cloud DNS uses one TTL for the record set. A mail-server target is a hostname, not a mailbox address or URL; the editor handles required fully qualified presentation.

Separate DNS and delivery failures

If the target is a mail server you operate, verify its own address and mail service. A correct MX lookup alone does not prove the server accepts mail for the domain.

Do not apply another DNS provider’s CDN proxy advice to Google Cloud DNS. Review the controls actually available for this backend.

For a refused save, retain the exact redacted lock, quota, policy or provider response. If DNS is correct but messages bounce, keep a redacted bounce for the mail administrator rather than repeatedly replacing working records. SPF, DKIM and DMARC are a separate authentication task.

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