Group
  • Deployment

    Set up my domain and DNS without shooting my email in the foot

    Point the domain at the app, keep email working, and lock down DNS with the right records and TTLs.

    • Ship faster
    • Plan & validate
    • Intermediate
    • General

Free Prompt

Set up DNS and domain configuration for my app. I want the domain pointing at production, email still working, and the DNS records set up so I don't lock myself into a bad state. Do each of these: 1. Configure the base records: A/AAAA (or ALIAS/ANAME if the host recommends it) for the apex domain pointing at the app, CNAME for www pointing at apex (or the platform's recommended target), and any subdomain records I need (staging, api, docs). Verify each resolves correctly with a lookup. 2. Keep email working. If I'm using this domain for email (Google Workspace, Fastmail, an email API like Postmark/SendGrid), verify MX records are correct, add SPF (TXT), DKIM (per provider), and DMARC (start with p=none to observe, then tighten). Deliverability failures because someone overwrote MX records are common and painful. 3. Set TTLs sensibly. Long TTLs (24 hours) after things are stable; drop to five to fifteen minutes before making any planned change so cutovers are fast. Note current TTLs so I know how long a mistake will linger. 4. Register or verify domain ownership with any service that needs it (Google Search Console, error tracking, email verification). Do this now so it's not a launch-day scramble. 5. Lock the domain and enable registrar-level 2FA and registrar lock. Domain hijacks are rare but catastrophic and take an insultingly long time to reverse. 6. Document the full DNS record set somewhere I can check into the repo (a dns.md or similar). If a record disappears mysteriously, I want to know what was there. Don't touch existing MX records unless you're sure you understand them. The deliverable is the DNS records set up and verified, email deliverability sanity-checked (send a test to a Gmail address and check the headers show SPF/DKIM/DMARC pass), TTLs documented, and the record set snapshotted in the repo.

What This Does / How This Helps

This gets your domain pointing at the app, keeps email deliverability intact with SPF/DKIM/DMARC, sets TTLs that let you fix mistakes fast, and locks the registrar so nobody hijacks the domain. DNS is a category of change that's easy to break and slow to fix. The specific horror stories: someone overwrites MX and email disappears silently for hours, TTLs are set to a day so a wrong record haunts users far past when you fixed it, or the registrar account isn't locked and someone social-engineers the transfer away. None of these are complicated to prevent, and all of them ruin launches.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts