Send application email without changing your existing MX records

You can add an application email provider while keeping your existing inbox. Choose application sending in Postscale. MX records select where incoming mail goes; your application's API or SMTP configuration selects how it sends.

Keep the two paths separate

Incoming mail → existing MX → current mailbox provider
Application   → Postscale API / SMTP → recipient
Delivery failure → dedicated return-path host → Postscale

For example, your team can keep support@example.com in its existing mailbox while Postscale sends receipts from receipts@example.com. Set Reply-To to a working, monitored address when receipts should accept human replies. A bounce hostname handles delivery failures, not those conversations.

If you want personal forwarding instead, first compare forwarding, SMTP and mailbox hosting.

Before setup

You need a verified Postscale administrator account, room for the domain on your plan, and control of its DNS. Automatic approval additionally requires an active primary DNScale zone and permission to edit it. The services have separate accounts and billing; check plans and limits before proceeding.

Record your current MX answers and export the relevant zone records. Inventory every sender before editing SPF; keep the mailbox provider's authorization and DKIM selectors. Check your sending approval status: DNS verification does not remove account review or volume limits.

dig example.com MX +noall +answer
dig example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Replace example.com with your own domain. Also query its assigned authoritative nameservers to distinguish published records from a resolver's cached answers.

Prepare application sending

1. Open automatic setup with DNScale and choose application sending. You can also start from the DNScale zone's Set up email with Postscale action.
2. Confirm the exact domain. A sending subdomain is also an option, but it has its own records and sender addresses.
3. Prepare the domain, DKIM and return path, then choose Connect with DNScale when available. Postscale saves the setup for resumption.
4. Review the DNS changes in DNScale. An application-sending preview should not replace the domain's receiving MX. Approve only a plan matching your intent.
5. Return to Postscale and verify the records.

For DNS hosted elsewhere, or when automatic setup is unavailable, follow manual domain setup and select Send email only. Copy the generated record names and values instead of placeholders from an article.

What a sending-only record diff looks like

This example assumes an existing mailbox provider. Names ending in .example are placeholders; the dashboard supplies the real selectors and values.

When no DMARC policy exists, setup can propose v=DMARC1; p=none for monitoring. Review it separately from an existing enforcement policy. A compatible SPF merge preserves the old sender and final all mechanism; multiple SPF policies or a redirect need manual review. Expanded includes must still fit SPF's lookup budget. See authentication setup.

The return-path CNAME occupies a separate hostname. Do not create it at the root of your domain or replace a hostname already serving something else. A conflict is a reason to review the plan, not delete unrelated records.

Prove both mail paths still work

Use controlled addresses and a small number of uniquely titled messages:

1. Compare authoritative and recursive MX answers with your saved inventory. The receiving record set should match.
2. Send a new message from an external account to an existing company address. Confirm it arrives in the original mailbox, then test its usual reply path.
3. Send through your application using Postscale API or SMTP. A ps_test_ key simulates sending; real delivery needs an appropriate ps_live_ key and an eligible sending account.
4. Inspect the received message's From, Reply-To and authentication results. Confirm the expected domain signs it and DMARC passes. Record the actual result; an API success or SMTP acceptance alone does not prove inbox receipt.
5. Reply to the application message and confirm the monitored reply address receives it. Test delayed-bounce handling separately if your application uses it.

When setup needs attention

Keep the old sending configuration until the replacement passes your checks. Switching the application's sender back is separate from restoring DNS, and DNS restoration is not immediate for cached answers. DNScale's record approval walkthrough explains the DNS side of the handoff.

Set up application sending →