Start

Domain Setup Guide for Sending and Receiving Email

Configure DNS records for Postscale sending, inbound routing, bounce handling, SPF, DKIM, and DMARC.

Updated

TL;DR

Add the Postscale DNS records before you send production mail: DKIM for signing, SPF for authorized senders, DMARC for policy and reports, Return-Path CNAME for delayed bounces, and MX records only on a subdomain used for inbound processing. Verify each record before switching traffic.

What you will learn

  • Understand which DNS records Postscale needs for outbound, inbound, and bounce handling
  • Choose between root-domain and subdomain setup without disrupting existing mailboxes
  • Verify SPF, DKIM, DMARC, Return-Path, and MX records before production traffic

Choose the domain pattern

Most teams use one of three patterns:

PatternBest forExample
Root domain sendingProduct emails from the main brandhello@example.com
Sending subdomainCleaner reputation isolationnotify@mail.example.com
Inbound subdomainWebhook processing without mailbox disruptionanything@inbound.example.com

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 MX records on the exact domain or subdomain Postscale should receive:

inbound.example.com.  MX  10 mx1.postscale.io.
inbound.example.com.  MX  20 mx2.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.

Frequently asked questions

Can I use Postscale without moving my existing mailbox?
Yes. Keep your current MX records on the root domain and use a sending subdomain or inbound subdomain for Postscale.
Do I need MX records for outbound-only sending?
No. Outbound sending needs authentication and bounce routing records. MX records are only required when Postscale should receive mail for a domain or subdomain.

Put the guide into production

Postscale brings sending, inbound processing, DMARC reporting, and masked addresses behind one API so the operational pieces stay connected.