Mail guides
02 · Domain setup

Verify your sending domain.

Three DNS records — DKIM, SPF, verification — and you're ready to send. Plus the optional MX record if you also want to receive.

1

Add the domain

Console → Mail → Domains → Add domain. Enter the FQDN you want to send from (e.g. acme.com). Mail generates a fresh DKIM keypair and shows you the records to set at your registrar.

DNS records to set
# Required for outbound (any of these failing → domain stays 'pending')
TXT  productcraft._domainkey.acme.com   v=DKIM1; k=rsa; p=MIIBIjANBgk...
TXT  acme.com                            v=spf1 ip4:129.212.252.254 -all
TXT  _productcraft-verify.acme.com       productcraft-verify=<token>

# Optional — only if you want INBOUND mail on this domain
MX   acme.com                            10 mx.productcraft.co

The exact values are in the console after you create the domain. Don't copy them from here — the DKIM public key + verify token are per-domain.

2

Verify

Once the records are propagated (5-30 minutes for most registrars; an hour for some), hit Verify. Mail does a live DNS lookup, checks all three records (DKIM, SPF, verify token), and flips the domain to active. Failure shows the specific record that didn't resolve — fix at the registrar, wait for propagation, retry.

Or via API
curl -X POST https://api.mail.productcraft.co/v1/workspaces/<ws>/domains/<id>/verify \
  -H 'authorization: Bearer pcft_live_...'

3

Why these three records?

  • DKIM — cryptographic signature on every message. Lets Gmail / Outlook / corporate filters verify the message hasn't been tampered with and was authorised by your domain. Without it, your delivery rate tanks.
  • SPF — declares which IPs are allowed to send as your domain. Our outbound IP is 129.212.252.254. Without SPF passing, receivers may still accept the mail but it's a strong spam signal.
  • Verify token — proves to Mail that you control the domain. Pure ownership check; not visible to recipients. Without it, anyone could add your domain to their own workspace.

4

DMARC (recommended, not required)

DMARC is the policy layer that tells receivers what to do when SPF or DKIM fail. Mail doesn't generate a DMARC record for you — your operations team owns this for the domain. A safe starting policy:

TXT  _dmarc.acme.com   v=DMARC1; p=quarantine; rua=mailto:dmarc@acme.com; pct=100

p=quarantine means receivers send unauthenticated mail to spam. p=reject means they bin it entirely. Start with quarantine, watch the aggregate reports at rua=, then tighten if nothing breaks.

5

Inbound — the MX record

Add the MX record only if you want mail to your domain (support@, replies, etc.) to land in Mail mailboxes. Without MX, your domain is outbound-only.

Inbound mail hits mx.productcraft.co → mx-receiver service → parsed + stored under the destination mailbox. Listable via GET /workspaces/:ws/mailboxes/:id/messages.

6

Brand

Optionally customise the appearance of operational emails — email-verify, password-reset, transactional senders. Per-workspace, set in /workspaces/:ws/brand: display name, logo URL, accent colour, the support email shown in footers.

PUT /workspaces/:ws/brand
curl -X PUT https://api.mail.productcraft.co/v1/workspaces/<ws>/brand \
  -H 'authorization: Bearer pcft_live_...' \
  -H 'content-type: application/json' \
  -d '{
    "display_name":  "Acme",
    "logo_url":      "https://cdn.acme.com/logo.png",
    "accent_color":  "#1E40AF",
    "support_email": "support@acme.com"
  }'

7

Reverse DNS (PTR)

One subtle thing the ops team handles, not you: the outbound IP 129.212.252.254 needs a PTR record pointing to mail.productcraft.co. ProductCraft handles this; mentioning so you know it's in the path. Without it Gmail silently spam-filters every outbound message — a real failure mode we've seen and resolved.

Next: Send your first email →