Use PD DNS Manager bulk operations for a deliberate record change across a reviewed group of zones. A fleet-wide SPF or MX change needs an accurate target list and before/after record plan, not just a matching word in a search.

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.

For a PowerDNS backend, module reads and zone-file snapshots omit disabled native record values. Editing an affected record set can rebuild it from the enabled values. If your hosting team uses disabled records, preserve and review the native record set with your DNS administrator before module changes; use your established native management process where those values must be retained. A module export is not a complete backup of those disabled values or other provider settings.

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.

Prepare the change

Identify the exact record type, name and intended value. Confirm that the same value is suitable for every target domain; customer-specific verification tokens and tenant destinations often are not interchangeable.

Take current snapshots for the affected zones and preserve the expected source records. Check provider credentials and quotas, and exclude zones where a managed forwarding feature owns the record. For a smaller reusable initial setup, a template may be the more appropriate tool.

Queue the reviewed operation

1. Open DNS → Maintenance → Bulk record operations.
2. Choose the intended add, update or delete operation.
3. Enter its record type, name and value as required.
4. Select the exact target zones and review the scope again.
5. Start only the reviewed operation and follow the live progress.
6. Inspect the per-zone results and read back representative records, including any reported failure.

The job runs in the background through the normal WHMCS cron. Leaving the page is not a cancellation. A stalled progress view needs a task/cron check before another job is queued.

Reconcile partial results

A batch can contain successes and failures. Review which zones changed before retrying; do not assume every target remained untouched because one provider refused a write. The completed job log and Activity help identify what ran.

For an uncertain result, compare the actual live record set with the intended change. Resolve the specific provider permission, record-format or quota refusal; separately check the customer policies and managed-record ownership that this administrative job does not enforce. Keep the job reference, action time and redacted failure for support.

Finally check the authoritative DNS result and the affected service. A successfully written MX or address record is not itself proof of working mail or HTTPS. See the maintenance guide if the queue is not progressing.

Check each target zone

Your hosting team should compare the reviewed target list and before-change snapshots with each job result and the actual live records. Check the normal cron and last task result if progress stops. Reconcile successful and failed zones before another job; do not assume customer locks or allowances prevented an administrative write.

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