Domain Setup Guide for Sending and Receiving Email

Choose automatic or manual setup

For an active primary zone hosted on DNScale, automatic DNS setup prepares records in Postscale and opens a review in DNScale before you approve them. You need a verified Postscale administrator account and permission to edit the zone. Separate accounts and billing apply. If your DNS is elsewhere or automatic setup is unavailable, use the manual steps below and the exact records shown on your domain page.

For application mail, follow sending without changing existing MX. For a personal address, first compare forwarding, SMTP and mailbox hosting. Personal setup needs Starter or higher and an existing verified inbox outside the domain. It supplies no hosted IMAP or webmail; sending approval and usage limits still apply.

Choose the domain pattern

Most teams use one of three patterns:

If your company already receives mail at the root domain, avoid changing root MX records. Use a subdomain for inbound processing instead.

Add DKIM

DKIM lets receiving mail servers verify that Postscale signed the message for your domain.

1. Open the domain in the Postscale dashboard.
2. Copy each DKIM TXT record.
3. Add the records at your DNS provider.
4. Wait for propagation.
5. Click verify in Postscale.

Keep old DKIM records during provider migrations until all old mail streams have stopped.

Add SPF

SPF tells receivers which systems may send mail for the domain.

If Postscale is the only sender on a subdomain, publish the record Postscale provides. If you also send from other services, merge includes into one SPF TXT record. A domain must not publish multiple SPF records.

mail.example.com.  TXT  "v=spf1 include:_spf.postscale.io -all"

Copy the underscore form exactly: include:_spf.postscale.io. The host spf.postscale.io without the underscore is not the Postscale SPF include.

Use -all once the domain is fully cut over. Use ~all while you are still discovering senders.

Add DMARC

DMARC tells receivers how to evaluate SPF and DKIM alignment. Start with monitoring before enforcement:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Move from p=none to p=quarantine or p=reject only after reports show legitimate mail passing alignment.

Add Return-Path routing

Delayed bounces arrive after the initial SMTP transaction. Postscale correlates those DSNs through a Return-Path host.

ps-bounces.example.com.  CNAME  bounces.postscale.io.

Do not point your visible From domain at the bounce host. Return-Path routing is separate from user-visible addressing.

Add inbound MX records only where needed

For inbound processing, publish the dashboard's MX records on the exact domain or subdomain Postscale should receive. An example is:

inbound.example.com.  MX  10 mx.postscale.io.

This routes anything@inbound.example.com to Postscale while leaving person@example.com on your current mailbox provider.

Verify before production

Before switching real traffic:

1. Verify all records in Postscale.
2. Send a test message to Gmail, Outlook, and your own mailbox.
3. Inspect authentication results in the headers.
4. Confirm DKIM passes and DMARC aligns.
5. Trigger an inbound test if you configured MX records.

See the SPF, DKIM, and DMARC setup guide for the authentication details.