Set up

How-to Reviewed · not yet fact-checked

Goal

A sending domain that passes authentication: MX records that receive mail, one valid SPF record, a DKIM signature, and a DMARC policy — all green in Reply's Email Health Checker. Authentication is mandatory territory: mail providers reject or spam-folder unauthenticated email, and the Gmail and Yahoo sender requirements introduced in 2024 make it explicit. What each record proves is explained in SPF, DKIM, DMARC.

Before you start

• Know your two providers apart: the mail provider runs the mailboxes (Google Workspace, Office 365, Zoho, GoDaddy Mail, Namecheap Mail); the hosting provider / registrar holds the DNS (Namecheap, GoDaddy, IONOS, OVH, Cloudflare). Some companies do both. Records are always added at the DNS host, but the values come from the mail provider.
• Reply is not an email service provider — it does not issue SPF or DKIM values. Get them from your mail provider.
• These are domain-level settings: they propagate to every mailbox on the domain.
• If you lack DNS access or confidence, hand this page to your IT person, or ask your hosting or mail provider's support — they configure these records routinely.

Where the records live: provider × registrar

Most hosting sites follow the same structure — Domains → select a domain → Manage DNS or DNS zone editor → add the record — so the generic path covers registrars not named here.

Steps

1. Test the domain before touching anything: Mail-tester (the "You are (not) fully authenticated" section), EmailStuff, or Dmarcian show what already passes. In Reply, the Domain Setup tab of the email account shows the same picture.
2. Set the MX records with the values your mail provider publishes. The common failures: records absent, records still pointing at an old mail provider after a switch, or records mixing two providers. When switching providers, delete the old MX records — otherwise incoming mail breaks. If you use a spam-filtering service such as Proofpoint or Mimecast, your MX records point to it by design.
3. Add the SPF record as one TXT record. The rules: correct syntax, exactly one SPF record per domain, no more than 10 DNS lookups, and every server or tool that sends on behalf of the domain included. Multiple SPF records cause checks to fail — consolidate into one line.
4. Add the DKIM record. DKIM is a key pair: the private half stays with your mail provider, the public half goes into your DNS as a TXT record. Google Workspace issues it in the Admin Panel; Office 365 in the admin center; other providers via their support.
5. Add a DMARC record. Start soft and tighten as you validate your sending sources: p=none, then p=quarantine, then p=reject. Do not jump to a strict policy until every legitimate sending server is covered by SPF and DKIM — otherwise mail from unauthenticated servers gets quarantined or rejected.
6. A and rDNS records: Google Workspace, Office 365, and other major providers have these preset. Only self-hosted mail servers need to verify them.
7. Re-test with the same tools, then re-run Reply's Health Checker.

Reference shapes for the three authentication records:

SPF    v=spf1 mx include:_spf.google.com ip4:65.254.224.19 -all
DKIM   v=DKIM1; k=rsa; p=<public key>
DMARC  v=DMARC1; p=none; pct=100; rua=mailto:reports@yourdomain.com

DMARC policy options:

Expected result

MX lookups resolve to the current mail provider, one SPF record passes within the lookup budget, DKIM verifies, and DMARC publishes a policy. A test email from an outside address arrives in the domain's inbox (proving MX), and authentication testers report the domain fully authenticated.

Verify

Reply verifies the domain itself: open Settings → Email Accounts, click the domain, and check the Domain Setup tab. The Email Health Checker tests SPF, DKIM, DMARC, domain age, MX records, A records, and rDNS; every failing check expands into details and a fix path. After fixing records, re-run the check — fixed several domains at once, retest them in bulk. Once a domain passes cleanly, Reply stops re-checking it automatically, so re-run the check yourself after any later DNS change.

If it doesn't work

• Multiple SPF records — merge them into a single TXT record; more than one fails the check.
• SPF exceeds 10 DNS lookups — flatten includes or remove tools that no longer send for the domain.
• No incoming mail — MX records absent or still routing to the previous provider; remove stale records and add the current provider's values.
• DKIM missing — Reply cannot issue it; get the public key from the mail provider (Admin Panel for Google Workspace, admin center for Office 365, support for others).
• Deliverability dropped after tightening DMARC — a strict policy is punishing senders not covered by SPF and DKIM; fall back to p=none, authenticate every source, then tighten again.
• Domain age is red — it cannot be fixed by DNS; a young domain needs warm-up time instead — see Warm up new mailboxes and domains.
• Still stuck — your hosting or mail provider's support configures these records daily; that escalation is the documented path.

Related

• SPF, DKIM, DMARC — the mechanism behind each record
• Email deliverability — where authentication fits among filtering signals
• Deliverability — the Health Checker in the full protective stack
• Warm up new mailboxes and domains — the step that follows DNS
• Connect a mailbox

Do this via API instead

DNS records are edited at your domain host, outside Reply — there is no Reply API that writes them. What agents can do is read the Reply side: email account details, settings, and connection state over the REST API and MCP, to confirm which accounts and domains need attention. Entry points: docs.reply.io and agents.reply.io/mcp.