Set up email DNS in DNScale: review and approve the Postscale records

Automatic setup saves copying DNS values, but you still decide which mail service receives your domain's messages. Start with that decision before approving records. This guide covers the DNS review; Postscale's forwarding versus mailbox guide covers the email-service choice.

Reviewed against the integration implementation on October 6, 2026. Record examples below are illustrative, not screenshots or measurements of a live setup. Use the actual preview for your zone as the change proposal.

1. Check eligibility and choose the workflow

Use an active primary zone hosted on DNScale and an account with permission to edit it. Secondary zones and zones not yet active are not eligible. Postscale requires a verified administrator account. The services have separate plans and billing; automatic setup does not migrate DNS hosting from another provider.

Open the zone and choose Set up email with Postscale when the integration is available. Postscale receives the domain and asks which workflow to prepare:

Personal setup requires Postscale Starter or higher and a destination inbox outside the domain being configured. It provides no hosted mailbox, IMAP or webmail. Sending remains subject to Postscale approval and limits. Review the integration requirements before buying a plan.

2. Prepare in Postscale, then connect

Postscale prepares the domain, ownership proof, DKIM and return path. For personal setup it also prepares the selected forwarding address. Preparation is saved so you can resume after sign-in, plan selection or an interruption.

Choose Connect with DNScale to open the approval page. Sign in to DNScale if needed. You do not need to copy a customer API key between the services. If the automatic action is unavailable, use Postscale's manual domain instructions; do not substitute records from an unrelated domain.

3. Review an application-sending example

Suppose your domain already receives mail through another provider. A typical preview has these effects:

A compatible SPF example, using a placeholder for the existing provider:

Before: v=spf1 include:old.example -all
After:  v=spf1 include:old.example include:_spf.postscale.io -all

The merge adds authorization inside the existing policy, before its final all mechanism. It does not publish a second SPF policy. Review nested includes as well: a local record merge does not establish that every external include fits SPF's total DNS-lookup budget.

For an existing policy such as v=DMARC1; p=reject, the integration leaves DMARC in place. It does not weaken it to monitoring. Test the new sender's alignment before routing production application traffic. Postscale's sending-only walkthrough explains the before/after mail checks.

4. Review personal receiving as a cutover

Personal setup also proposes the receiving MX values supplied by Postscale. If those replace an existing provider, DNScale requires a separate confirmation. The change affects every address at that hostname, not just the one address you entered in the setup form.

Before confirming, inventory named addresses, catch-all, groups, automated intake and recovery addresses. Prepare their intended routes and check the verified destination inbox. Keep the old receiving service available through the cache transition. Stored messages and other users' mailboxes are not copied.

Do not keep an unrelated old provider as a higher-priority-number “backup.” MX priority does not select providers by recipient address. Use the provider's prescribed record set; see the MX reference.

5. Resolve conflicts before approval

For example, an existing A record at ps-bounces.example.com conflicts with the proposed CNAME. The setup stops; approval is not permission to remove that A record. Resolve its purpose before continuing. The change review checklist provides a record inventory and restoration template.

6. Approve, verify and test

Approve the exact preview with your DNScale zone permissions, including the additional MX confirmation when applicable. Return to Postscale for verification. Check DNS in two places: the assigned authoritative nameservers show the current published zone; recursive resolvers may still hold older answers.

# Replace both placeholders with your domain and assigned authoritative server.
dig @ns1.example.net example.com MX +noall +answer
dig @1.1.1.1 example.com MX +noall +answer
dig @ns1.example.net example.com TXT +noall +answer
dig @1.1.1.1 example.com TXT +noall +answer

Also check the ownership, DKIM and return-path hostnames from the preview. Successful publication does not clear resolver caches, approve sending or prove delivery. Send a real controlled application message. For personal forwarding, test incoming receipt, a new outbound message and an ordinary reply with the correct visible identity. The Postscale SMTP reference explains credentials and simulated versus live sends.

Resume an interrupted request

An expired approval link requires a fresh connection from the saved Postscale setup. Supported retries use the saved DNS plan, including after a partial application. If affected records changed independently, review the conflict instead of repeatedly retrying. A completed approval is not replayed as another DNS mutation.

If recovery requires restoring a previous value, use the saved inventory and account for both the previous and replacement TTLs. Retrying is not an automatic rollback, and restoring authoritative records cannot instantly change cached answers or recall mail already delivered elsewhere.