Set content policies in PD DNS Manager when customer-submitted records must stay within your hosting policy. A policy controls what may be saved; it does not check whether the destination website or mail service actually works.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

Administrative bulk jobs and replication write directly to the provider. Customer editing locks, allowances, content rules and forwarding-record protections must not be assumed to stop these operations. Your hosting team must review the target zones and exclude records owned by another feature before running them.

Set the rules

1. Open DNS → Settings.
2. Review Blocked record content, with one intended pattern per line.
3. Set Address records may only point at if customer A/AAAA records must use particular IPs or CIDR ranges.
4. Set Address records may never point at for addresses/ranges that should be refused.
5. Save and check both an intended allowed change and an intended refused change in a controlled zone.

The deny list is checked before the allow list. Empty address restrictions have a different effect from a list that accidentally excludes a required destination, so review IPv4 and IPv6 requirements deliberately. A blocked pattern can match a record name or value; keep it narrow enough for the policy you intend.

Check ownership, locks and access

A zone Lock freezes client edits while administrators retain management access. The domain-only editing setting is a separate choice between full editing, view-only access and hidden record pages. Customers with hosting have a different entitlement context from customers with only a registered domain.

These controls should not be diagnosed by repeatedly changing the provider token. First check the client binding, saved policy, active service and actual refusal message. Imports can be subject to the same customer rules.

Respect records owned by forwarding

A record required by website or email forwarding is protected from accidental manual edits. Change or remove the forward through its own feature instead of deleting the associated record in the editor.

API writes also honour the relevant guardrails; an automation token is not a workaround for a policy refusal. Keep the exact redacted error and intended name/type/value for support, without exporting unrelated customer zones. Review the allowance guide if the refusal concerns record counts.

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