Use Maintenance and Activity to separate connection, native-domain, record and forwarding problems. PD Plesk DNS depends on the intended domain or subscription already existing on the selected server.

Inspect the original operation

1. Identify the provider, domain and intended Plesk account scope.
2. Review the exact action and result in Activity.
3. Open Maintenance and inspect the relevant job’s last result and time.
4. Confirm the normal Blesta cron for scheduled tasks.
5. Run only the relevant available maintenance action and inspect its result.

The connection test reads server information rather than exercising every feature. Check source-address restrictions, native domain scope and operation permission separately. When zone metadata lacks nameservers, the health check also reads apex NS records. Compare any remaining warning with native DNS and public delegation before assuming the zone is broken.

Diagnose the actual saved records

An edit adds a replacement before removing the previous record; a refused removal can leave both values. Read the complete affected record set, even after a successful-looking save.

The module does not send individual TTL changes, and its displayed TTL can be a fallback. Use the TTL guide and inspect native values before relying on a cache change. Import and restore writes can stop part-way; reconcile actual records before repeating an uncertain operation.

Keep recovery and removal distinct

The module refuses standalone zone creation and deletion. An absent native domain must be restored through the responsible administrator before record recovery. Cleanup settings cannot bypass that restriction.

Website forwarding changes native hosting mode; removal leaves no web hosting rather than restoring a previous website. Single-address email-forward removal removes the native mail name, so review any existing mailbox first. Use the forward-removal guide before acting.

Keep the account/domain reference, requested action, original time and redacted result while your hosting team checks the affected task. Never include secret keys, passwords, signing private keys or unrelated customer data. Do not remove a live domain or run guessed server repairs to hide a warning.

Check the maintenance result

Your hosting team should identify the original task, provider/zone, last-run time and relevant Activity result. Compare read-only connection/discovery/health observations separately from current DNS, customer binding and public service behaviour. Inspect partial import/restore/cleanup state and retain recovery references before retrying a write. Use your own Plesk administrator for native account ownership, domain preparation or signing configuration.

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