Verify your sending domain.

Console → Mail → Domains → Add domain. Enter the FQDN you want to send from (e.g. acme.com; the dialog also asks whether it's a root domain or a subdomain, and whether you want to send, receive, or both). Mail generates a fresh DKIM keypair and drops you on a per-domain setup checklist — one step per record, each with the exact host and value to paste at your registrar (they're also on the API as dns_instructions on every domain read).

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.

A domain has an intent — send, receive, or both (the default) — which decides which of these records are required before it goes active: the verification TXT is always required; SPF + DKIM are required for sending; MX for receiving. With the default both, publish all four.

You don't strictly have to do anything here — Mail re-checks pending domains every ~5 minutes and flips them to active on its own once the records land. To check on demand (records propagate in 5–30 minutes for most registrars), open a record from the domain's setup checklist and hit Check DNS now — or call the verify endpoint directly. Either way it's a live DNS lookup of the required records that returns the updated domain on success, or a 400 with a per-record dns_check_results diff (expected vs. actual) showing exactly which record is missing or wrong — fix at the registrar, wait, retry.

• 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 servers are allowed to send as your domain. v=spf1 mx -all authorises your domain's MX hosts — i.e. mx.productcraft.co from the record above. Already have an SPF record? Merge the mx mechanism into it (e.g. v=spf1 mx include:_spf.google.com -all) — the check accepts any SPF record that includes mx. 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.
• MX — routes inbound mail on your domain to Mail (see below), and doubles as the anchor for the SPF mx mechanism.

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:

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.

The MX record is what makes mail to your domain (support@, replies, etc.) land in Mail mailboxes. If you only ever want to send, create the domain with intent: "send" and skip it — outbound-only.

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

Optional: workspace-wide design tokens your templates can use — name, logo, colours, font stack, footer. They're addressable in any template as {{brand.*}} and drive the built-in layout + footer partials, so restyling every email is one API call. All fields are optional; unset fields fall back to platform defaults (GET returns the resolved set, DELETE resets to defaults).

More knobs — secondary/text/background colours, font_stack, button_radius, footer_html, footer_address, social_links — are in the API reference.

One subtle thing ProductCraft handles, not you: the shared outbound relay (mail.productcraft.co) keeps matching forward + reverse DNS (PTR) on its sending IP. Mentioning so you know it's in the path — without a PTR, Gmail silently spam-filters every outbound message, a real failure mode we've seen and resolved.