# Email DNS setup — a prompt for your AI agent

You are helping me set up the DNS records my domain needs before it can send and receive email reliably. Use the reference below, then ask me for what you don't have yet.

## What you already know (verified reference, not general knowledge)

Five records matter, in this order, and the order matters:

1. **MX** — goes first. Verification codes, DMARC reports, and replies all need somewhere to land before anything else is safe to touch.
2. **SPF** — a TXT record naming the servers allowed to send for the domain.
3. **DKIM** — signs outgoing mail. Publish the key before the first real send, not after.
4. **DMARC** — start at `p=none`. This satisfies Gmail's February 2024 and Microsoft's May 2025 sender requirements while the reports get read and any forgotten sender gets found.
5. **Tracking CNAME** — optional, only if the sending platform tracks clicks on a hostname the domain owner controls.

Traps to warn me about, specifically, when each one is relevant:

- Old MX records left in place beside new ones split mail between two systems by priority. Half the inbox ends up somewhere nobody is reading.
- Two SPF records on one domain is a hard error, not something DNS merges for you; the whole check can fail. Each `include`, `a`, `mx`, `exists`, and `redirect` costs one of ten allowed DNS lookups, and most providers spend more than one apiece. A single quoted SPF string caps at 255 characters.
- The DKIM selector name is arbitrary and only the sending provider knows it (Google Workspace uses `google`, Microsoft 365 uses `selector1`/`selector2`, many relays use `s1`). It needs to be written down, or the key can't be checked later. Two senders can sign for one domain at once, on different selectors.
- DMARC published before SPF and DKIM are actually correct can quarantine legitimate mail — that's why it starts at `p=none`, not enforcement.
- Tracking links should resolve on a hostname the domain owner controls, never a shortener.

## What to do

1. Ask for the domain name, the mail host (where mail is received), and the sending platform, if not already given.
2. Produce the five records in order, each with its exact `Type` / `Name` / `Value` shape filled in with the real values where known, or clearly marked "check your platform's dashboard for this exact value" where not.
3. For each record, flag the one specific trap above that applies to it.
4. Give the `dig` command to verify each record once it's added (for example `dig +short TXT _dmarc.example.com`), and describe what a healthy result looks like.
5. State the order to add these in, and don't let anyone skip straight to DMARC enforcement.

## Output format

One numbered section per record: the record shape, the trap, and the verification command. End with a short "add them in this order" summary line.

## When we're done

Ask for the output of each `dig` command once it's run. Read it and say plainly whether it's correct, and if not, exactly what's wrong.

Don't invent a value that isn't certain — say to check the provider's dashboard instead of guessing.

---
Reference: letterduck.com/downloads/email-dns-worksheet · Free to use, no attribution required.
