DNS Records

Add these records to your domain's DNS to enable DKIM signing and improve deliverability.

DKIM record

The DKIM public key is returned when you add a domain. Add it as a TXT record:

SPF

You do not need to add an SPF record on your root domain, and you should not.

SPF authenticates the envelope sender (the bounce address), not the From: header. Mail we send carries our own bounce domain, so an SPF record on acme.com is never consulted for it — it authorises nothing on your behalf.

It can also do harm. A domain may publish only one SPF record; a second one makes SPF fail for every service sending from that domain, including your own mailbox provider. If you already have an SPF record for Google Workspace, Microsoft 365 or similar, leave it exactly as it is.

If you want SPF to align with your domain for DMARC, add the two optional Return-Path records below instead. They live on the send. subdomain and cannot collide with your existing SPF.

DMARC record

Recommended. It tells inbox providers what to do with mail that fails authentication, and gives you reports on what is being sent in your name.

Start at p=none, which only collects reports and changes nothing about delivery. Move to quarantine and then reject once the reports show your legitimate mail is authenticating.

Return-Path records (optional)

Both are optional. Your domain sends fine without them — it just uses our shared bounce address, which means DMARC passes on DKIM alone.

Publish both and we switch your mail to a bounce address on your own domain. SPF then passes and aligns with your From: domain, so DMARC passes on both mechanisms instead of one, and delayed bounces come back to us per-domain so failed addresses are suppressed automatically.

This SPF record is safe: it sits on the send. subdomain, which has no mail of its own, so it cannot conflict with the SPF record on your root domain.

We detect these automatically — publish them and alignment switches on at the next verification, with no action in the dashboard.