5 · DNS email records

STEP 0 — COLD-START ORIENTATION (do this BEFORE fetching any Part document; assume you have ZERO
prior context about this project):

1. Locate + identify. Run `pwd`. Read the project's `AGENTS.md` + `CLAUDE.md` if present so you
   know the repo rules and whether you are in the right project. Then read `Zaj-PROJECT.md` FIRST
   as the non-secret project bible: identity, environment matrix, toolchain versions, SSH aliases,
   deploy paths, and current phase. If `Zaj-PROJECT.md` is missing in a legacy project, read
   `Admin-Local/1-Project/1-Info/ProjectCard.md` as fallback, then create/update `Zaj-PROJECT.md`.

2. Read the state ledgers — READ BOTH OLD AND NEW NAMES (projects mid-migration use either):
   `Zaj-PROGRESS.md` OR `PROGRESS.md` (what earlier phases/steps already did, what's in-flight),
   `Zaj-BACKLOG.md` OR `BACKLOG.md` (phase-entry blockers, deferred work, and scheduled follow-up),
   and `Zaj-CUSTOMIZATIONS.md` OR `_CUSTOMIZATIONS.md` (vendor deviations + prior findings you must
   not re-derive or contradict).

3. Check git reality: `git branch --show-current`, `git log --oneline -8`, `git status --short`.
   - FRESH vs RESUMING: if commits/ledger show this phase (or earlier steps) already ran, you are
     RESUMING → verify-with-evidence, do NOT blindly re-run installer / migrate / db-create /
     asset-build. (This is the contract's reconcile rule.)
   - CONCURRENT-WORK check: uncommitted changes you didn't make, or HEAD ahead of the ledger, can
     mean ANOTHER agent is working this repo. Coordinate around hot files; do not commit over
     unrelated work. Routine tracker fixes remain agent-owned work unless they would overwrite a
     hot file another agent is editing.

4. Inherit rules + safety: skim `.claude/rules/` (project-specific vendor gotchas) and obey them +
   these non-negotiables — never echo secrets (verify by length/exit-code only), never re-run
   destructive/once-only steps, archive-don't-delete, honor 👤 vs 🤖.

5. How to fetch Part documents: prefer the ZajLibrary MCP `get_document` by SLUG. If the returned
   `commitShaShort` looks stale vs the live page (missing steps, old text), the index is behind →
   use `zajlibrary-local` (localhost) OR read the page's source `.mdx` directly from the ZajLibrary
   repo. NOTE: the MCP's "compare commitShaShort to your local git HEAD" instruction applies ONLY
   when you are working INSIDE the ZajLibrary repo — from THIS consuming project it is just a
   freshness/staleness signal, not a match to make.

6. Where to record: write current-truth facts to `Zaj-PROJECT.md`; write vendor deviations to
   `Zaj-CUSTOMIZATIONS.md`; write execution state to `Zaj-PROGRESS.md`; write blockers/deferred
   work to `Zaj-BACKLOG.md`. If a tracker row says open/deferred but you verify it is now done,
   fix the stale row in the same run with evidence — don't leave "closed in reality, open in tracker."
   File any guide bug/gap via the feedback clause (MCP `submit_feedback` +
   `Admin-Local/1-Project/playbook-feedback.md`) — log-then-continue, don't silently work around.

Only after Step 0 is complete, begin fetching Part 1.

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

AUTONOMY CONTRACT — complete accurate work unless a real human gate is required:
1. Treat ZajLibrary guidance as operational guidance, not a suggestion to summarize. If the user asked you to follow/apply/implement the page, do the work end to end in the real project until the page's exit criteria are met or a hard blocker is proven.
2. Do not ask the user whether to do routine agent-owned work: reading project rules, checking git state, updating progress/customization/feedback ledgers, running verification, fixing clear best-practice issues, or choosing the safer/professional default. Do it, cite evidence, and report what changed.
3. Ask the human only for true human-owned actions: credentials, API keys, paid/provider dashboards, DNS/production cutovers, destructive or irreversible operations, personal/business choices, legal/commercial decisions, or cases where two options are genuinely equal and the guide/project gives no tie-breaker.
4. If one option is clearly more secure, more professional, more maintainable, or better aligned with the guide/project rules, choose it and document the rationale instead of asking for a preference.
5. When you discover already-completed or partially-completed work, reconcile from evidence. Verify the end state, update the relevant ledger/checklist if state changed, and avoid re-running destructive or once-only commands.
6. Banned routine asks: "should I update trackers?", "should I commit?", "should I run verification?", "should I fix the stale ledger?", or "which option do you prefer?" when the guide/project makes one option clearly better.
7. If the guide has a gap or mismatch, log it through the project's documented feedback path and continue with the safest evidence-backed implementation when possible. Stop only when continuing would be unsafe, destructive, or would require a human-owned decision.

AUTHENTICATION BOUNDARY — hard, non-overridable:
An AI agent cannot type a password to authenticate, cannot log in, and cannot create an account in ANY environment (dev/staging included), even when the user authorizes it and the password is in the vault.
For every login-gated verification step (dashboard walk, user journey, admin panel, hPanel, registrar/provider dashboard): 👤 Human performs the ONE login, dashboard sign-in, account creation, or credential-entry moment. 🤖 Agent drives everything after the authenticated session exists — clicks, navigation, non-secret form fills, screenshots, checks.
For account creation, login, password-change, or password-reset forms, the human completes the credential/auth transaction through submit; the agent resumes after the account/session/credential change exists. Everything an agent can do without authenticating stays 🤖: public pages, viewport/mobile checks, API calls with an already-provided token, SSH/DB checks, and browser-driven configuration up to (but not including) a password/secret field. Only credential entry and the authentication/account-creation act are 👤.

## Metadata
- title: 5 · DNS email records
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/05-dns-email/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 4
- part_number: 5 (legacy stepNumber frontmatter)
- legacy_step_number: 5
- est_time: ~20–30 min (+ propagation)
- description: Make transactional email deliverable — verify the email provider, add SPF, DKIM, and DMARC records (plus MX), interpret CAA safely, and confirm everything with dig.
- tags: codecanyon, dns, email, deliverability

## Execution rules (binding)
- This is Part 5 of phase 4 (~20–30 min (+ propagation)) — execute this Part fully, then stop at its `## Checklist`.
- Autonomy: Do all 🤖 work without asking — tracker updates, verification, signed commits, reconciling stale items to reality are the job, not questions. Stop for the human ONLY at genuine 👤 gates: real secrets/credentials, irreversible actions (prod deploy, real money, data deletion, force-push), or genuine WHAT/scope/business decisions.
- Full ≠ optional: Autonomy does not mean minimal. Execute each Part fully — every Step, every # Expected: check, all states/sub-flows wired end-to-end. Never ship a happy-path subset as "done." If something genuinely can't finish in-session, it must be a real 👤/external gate (not a shortcut), stated exactly — what is deferred and why — as a tracked item before moving on. When the user says "do fully," honor it to completion.
- For playbooks, treat a Part as the `.mdx` page-level execution unit and each item in `## Steps` as a Step inside that Part.
- Follow `## Steps` in order. Do not skip Steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (authentication, account creation, password/secret entry, paid/provider dashboards, destructive actions) need the human; 🤖 **Agent** steps you run in the shell or browser after the authenticated session exists.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, investigate safely and reconcile from evidence first; ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the Part done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this Part describes — no refactors, added features, or later-phase work unless the Part says so.
- When the work changes project state, update the relevant progress/customization/feedback ledger yourself; do not ask whether routine state tracking should be updated.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.
- EXECUTION CONTRACT — full coverage, no silent skips:
1. Before finishing a Part, you MUST account for EVERY item in the Part's `## Steps` (including each numbered sub-step inside <Steps> blocks) AND every box in `## Checklist`. Nothing is implicitly done.
2. Scope labels are not skip permission. `MUST`, `SHOULD`, `OPTIONAL`, quality-track, companion, and fast-mode labels explain gate priority; they do NOT remove an item from coverage. Default to FULL execution. Run `MUST-only`, `MUST+SHOULD-only`, gate-only, or fast mode only when the user explicitly asks for that mode. Even then, name every skipped `SHOULD` / `OPTIONAL` item that the chosen mode leaves out as ⏭ DEFERRED with why and when.
3. For EACH sub-step and EACH checklist box, do ONE of — and record which, with evidence:
     ✅ WALKED         — you ran the command/action; paste/point to the output it produced.
     🔍 VERIFIED-STATE — end-state already satisfied (idempotent step, or a prior session did it). Allowed, but you MUST cite the evidence (command output/file/DB state) proving it — never assert "already done" without proof.
     ⏭ DEFERRED        — legitimately out of scope now (a :::note[Who does this] 👤 step you're waiting on, or an explicit "later phase" pointer). State why + to when.
     ◐ PARTIAL         — some sub-parts done, some deferred; list exactly which and why.
4. Honor every `# Expected:` / ✅ bullet — compare actual output. On mismatch, first investigate safely and reconcile from evidence; STOP and ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices. Honor :::caution/:::danger as hard gates. Honor 👤 vs 🤖.
5. Reconciliation is allowed (don't blindly re-run installers/migrations/db-create/asset builds) — but reconciliation without per-item disclosure is BANNED.
6. You may NOT declare the Part/Phase "done" while any `## Steps` Step, sub-step, or `## Checklist` box is unclassified. Silent omission = incomplete.
7. Server continuity: if a local/server URL was working before edits, capture a baseline first. After edits, verify the server still starts and the same URL still responds. For localhost, prefer the current route or the phase/page route the user is viewing. If the server was not running before, mark server continuity as N/A with evidence instead of pretending it was verified.
8. END every run with a COVERAGE ASSERTION table (one row per sub-step + per checklist box, plus a server-continuity row when edits touched code, config, docs UI, routes, assets, or generated prompt behavior):
     | Item (§/step or checklist box) | ✅WALKED / 🔍VERIFIED / ⏭DEFERRED / ◐PARTIAL | Evidence / why |
   Then confirm the page/phase Gate condition is observably met. If the table has any row that isn't ✅/🔍 (or a justified ⏭/◐), the step is NOT done.
9. Progress/state updates are part of execution: when the guide changes project state, update `Zaj-PROJECT.md`, `Zaj-PROGRESS.md`, `Zaj-BACKLOG.md`, `Zaj-CUSTOMIZATIONS.md`, and/or `playbook-feedback.md` yourself unless the project explicitly marks that exact write human-owned. Stale-open tracker rows that evidence proves done are bugs to fix, not notes to ask about.
10. Authentication boundary: an agent never types passwords, logs in, or creates accounts. Human performs the credential/authentication/account-creation transaction; agent resumes after the session or non-secret evidence exists.
11. Secrets: never put keys/passwords/.env values in code, commits, or chat; verify by length/exit-code only.

---

# 5 · DNS email records

## TL;DR

**Objective** — make transactional email deliverable by authenticating the sending domain: verify the provider, add SPF/DKIM/DMARC (plus MX), interpret CAA safely, and confirm with `dig` — so password resets, receipts, and notifications don't land in spam or get rejected.

**Steps at a glance:**
1. **Verify the email provider and record credentials** — Confirm which service sends mail (Postmark, SES,
   Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.
2. **Add the three records and understand what each does** — publish SPF, DKIM, and DMARC records, so outbound
   email can pass authentication instead of landing in spam.
3. **Add MX records (if the domain receives mail)** — If the domain also receives mail, add the provider's MX
   records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be
   omitted — match your provider's guidance.
4. **Interpret CAA safely** — empty CAA is fine; Cloudflare-managed permissive multi-issuer CAA is also fine.
   Flag restrictive single-issuer records before final certificate strategy.
5. **Verify with `dig`** — Read the resolver output directly and record the Phase 12 live-mail proof owner.

:::note[User part + done-when]
**👤 User part** — the TXT/MX records are added in your DNS provider's dashboard, and the sending domain is verified in the email provider's console (Postmark/SES/Mailgun/SendGrid). An agent can run every `dig` check, but a person publishes the records and verifies the domain.

**Done when** SPF (single record), the DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`, MX is correct if the domain receives mail, CAA is either empty/permissive or intentionally reviewed, and the real production mail-header proof is assigned to Phase 12. &nbsp;·&nbsp; **⏱ ~20–30 min (+ propagation)** &nbsp;·&nbsp; 🔀 mixed (👤 DNS records + provider, 🤖 verification).
:::

## Background

:::note[SHOULD — deliverability]
A CodeCanyon app sends password resets, receipts, and notifications. Without SPF/DKIM/DMARC those land in spam — or get rejected. This page authenticates your sending domain.
:::

```mermaid
flowchart LR
  App[Laravel mailer] --> ESP[Email provider]
  ESP --> DNS[SPF + DKIM + DMARC DNS]
  DNS --> Inbox[Recipient inbox]
  DNS --> Reject[Reject / spam folder]
```

## Steps

### 1. Verify the email provider and record credentials

Confirm which service sends mail (Postmark, SES, Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.

:::note[Who does this]
🔀 **User + Agent** — 👤 the user owns provider login, account authorization, and any secret/API-key creation. 🤖 With browser automation and an authorized session, the agent can drive the non-secret console flow, capture the DNS records, and verify provider state. Use [vendor console automation](/tech-stack/laravel/codecanyon/learn/guides/vendor-console-automation/) for the browser path.
:::

Record the SMTP/API credentials into the production `.env` (`MAIL_*`) from **[3 · Production .env](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/03-production-env/)** — double-quoted, never committed.

### 2. Add the three records and understand what each does

| Record | Type | Answers | Without it |
|---|---|---|---|
| **SPF** | `TXT` | Which servers may send for this domain | Mail flagged as spoofed |
| **DKIM** | `TXT` | Cryptographic signature proving integrity | Tampering undetectable; spam scoring |
| **DMARC** | `TXT` | Policy when SPF/DKIM fail + where to report | No alignment policy; inconsistent delivery |

:::note[Who does this]
🔀 **User + Agent** — DNS publication changes public infrastructure, so 👤 the user authorizes the change or provides an authorized provider session/API token. 🤖 The agent can prepare the records, drive non-secret console clicks when authorized, and verify with `dig`.
:::

<Steps>

1. **Publish the SPF record** — one `TXT` at the root, listing every sender. Merge into a single record — multiple SPF records is itself a failure.

   ```text title="DNS records"
   example.com.  TXT  "v=spf1 include:_spf.provider.com ~all"
   ```

   - ✅ A single SPF `TXT` record exists at the root, listing every sender.

2. **Publish the DKIM record** — your provider gives a selector and key; publish it at the selector host they specify.

   ```text title="DNS records"
   selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public-key>"
   ```

   - ✅ The DKIM key is published at the provider's selector host.

   :::note[CNAME-based DKIM — Hostinger Titan and similar]
   Some providers publish DKIM as **CNAME** records pointing at the provider's key host, rather than a TXT key. Hostinger Titan, for example, uses three CNAME selectors:

   ```text title="DNS records"
   hostingermail-a._domainkey.example.com.  CNAME  hostingermail-a.dkim.mail.hostinger.com.
   hostingermail-b._domainkey.example.com.  CNAME  hostingermail-b.dkim.mail.hostinger.com.
   hostingermail-c._domainkey.example.com.  CNAME  hostingermail-c.dkim.mail.hostinger.com.
   ```

   Verify CNAME-based selectors with `dig CNAME`, not `dig TXT`:

   ```bash
   for sel in hostingermail-a hostingermail-b hostingermail-c; do
     dig +short CNAME "${sel}._domainkey.example.com"
   done
   # Expected: each resolves to its hostingermail-*.dkim.mail.hostinger.com target
   ```

   Publish exactly the selectors your provider specifies — for Hostinger Titan all three must resolve, or DKIM signing fails.
   :::

3. **Publish the DMARC record** — start at `p=none` (monitor only), collect reports, then tighten to `quarantine`/`reject`.

   ```text title="DNS records"
   _dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
   ```

   - ✅ A DMARC `TXT` record at `_dmarc.<domain>` starts at `p=none`.

</Steps>

### 3. Add MX records (if the domain receives mail)

If the domain also **receives** mail, add the provider's MX records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be omitted — match your provider's guidance.

<Steps>

1. **Publish the MX records** at the provider's priorities.

   ```text title="DNS records"
   example.com.  MX  10 mx1.provider.com.
   example.com.  MX  20 mx2.provider.com.
   ```

   - ✅ MX records are present if the domain receives mail (or correctly omitted if send-only).

</Steps>

### 4. Interpret CAA safely

CAA records restrict **which certificate authorities** may issue for the domain. The risk is not "CAA exists"; the risk is a restrictive record that excludes the issuer your final SSL path uses.

:::caution[CAA interpretation]
Empty CAA is safe during bring-up. Cloudflare-managed permissive multi-issuer CAA is also benign. A restrictive single-issuer record such as only `letsencrypt.org` can break Cloudflare/Google Trust Services or another final issuer later, so flag it before final cert hardening in **[Phase 7 · Security & monitoring → Headers & packages, step 7](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/02-security-headers-packages/)**.
:::

:::note[Why the risk is real — a concrete renewal example]
The danger with CAA is that the failure is **silent and delayed**. A stale CAA record does not break anything today — it breaks renewal weeks later, long after the change that caused it.

Worked example: Cloudflare switched issuing CAs in 2024 for many zones. A domain that had previously added `CAA 0 issue "letsencrypt.org"` could keep working until its existing cert expired, then fail renewal when Cloudflare tried to issue through Google Trust Services. Without renewal monitoring, you find out only when a user reports the HTTPS error.

```bash
   dig +short CAA example.com
   # Expected: empty OR permissive multi-issuer CAA.
   # On fail: a restrictive single-CA record omits the active/final issuer — review before SSL hardening.
   ```

This is why final CAA tightening is bundled with renewal-failure monitoring in Phase 7. If you add CAA before then, scope it to both the current and likely successor issuer rather than a single CA.
:::

### 5. Verify with `dig`

Read the resolver output directly. Do not treat a real test email as Phase 4 work — that is [RUN-LIVE] proof and belongs in production after the app can actually send mail.

<Steps>

1. **Confirm all records resolve.**

   ```bash
   dig +short TXT example.com            | grep spf1     # SPF present, single record
   dig +short TXT selector._domainkey.example.com         # DKIM key resolves
   dig +short TXT _dmarc.example.com     | grep DMARC1    # DMARC policy present
   dig +short MX  example.com                              # MX (if receiving mail)
   # Expected: one SPF line, the DKIM key, a DMARC1 policy, and MX records (if receiving mail)
   ```

   :::caution[`dig` quoting pitfall]
   Pass the record type and domain as separate arguments: `dig +short MX example.com`. Do **not** quote them as one string (`dig +short "MX example.com"`), which makes `dig` treat the whole string as the query name and return empty even when the MX record exists.
   :::

   - ✅ SPF (single), DKIM, DMARC, and MX (if receiving) all resolve.

2. **Record the live-mail proof owner.** The real send/receive test happens in [Phase 12 Step 3 · Harden, verify & sync](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/12-production/03-harden-verify-sync/) after production SMTP settings and the live app exist.

	   - ✅ Phase 12 owns the live mail-header proof; Phase 4 owns DNS record resolution only.

</Steps>

### Troubleshooting

| Symptom | Cause | Fix |
|---|---|---|
| `spf=softfail`/`fail` | Sender not in SPF `include` | Add the provider's include; keep one SPF record |
| `dkim=none` | Selector record missing/typo'd | Re-publish exactly as the provider specifies |
| `dmarc` ignored | Record at wrong host | Must be `_dmarc.<domain>`, not the root |
| Multiple SPF records | Two `TXT v=spf1` entries | Merge into one |
| Restrictive CAA before cert strategy | Only one CA is allowed and it is not your active/final issuer | Add the intended issuer now, or add a `Zaj-BACKLOG.md` Phase 7 renewal-monitoring row with owner, trigger, and acceptance |

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **👤 Provider verified** — email provider verified; `MAIL_*` recorded in production `.env`.
- [ ] **🔀 Records resolve** — SPF (single record), DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`.
- [ ] **👤 MX correct** — MX records correct if the domain receives mail.
- [ ] **🤖 CAA interpreted** — CAA is empty/permissive, or restrictive CAA has a named `Zaj-BACKLOG.md` cert-strategy follow-up before Phase 7 hardening.
- [ ] **🤖 RUN-LIVE owner recorded** — real mail-header proof is assigned to Phase 12 after production can send mail.

:::next[Next step]
[Cloudflare CDN](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/06-cloudflare-cdn/)
:::

# 5 · DNS email records

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/05-dns-email/

## TL;DR

**Objective** — make transactional email deliverable by authenticating the sending domain: verify the provider, add SPF/DKIM/DMARC (plus MX), interpret CAA safely, and confirm with `dig` — so password resets, receipts, and notifications don't land in spam or get rejected.

**Steps at a glance:**
1. **Verify the email provider and record credentials** — Confirm which service sends mail (Postmark, SES,
   Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.
2. **Add the three records and understand what each does** — publish SPF, DKIM, and DMARC records, so outbound
   email can pass authentication instead of landing in spam.
3. **Add MX records (if the domain receives mail)** — If the domain also receives mail, add the provider's MX
   records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be
   omitted — match your provider's guidance.
4. **Interpret CAA safely** — empty CAA is fine; Cloudflare-managed permissive multi-issuer CAA is also fine.
   Flag restrictive single-issuer records before final certificate strategy.
5. **Verify with `dig`** — Read the resolver output directly and record the Phase 12 live-mail proof owner.

:::note[User part + done-when]
**👤 User part** — the TXT/MX records are added in your DNS provider's dashboard, and the sending domain is verified in the email provider's console (Postmark/SES/Mailgun/SendGrid). An agent can run every `dig` check, but a person publishes the records and verifies the domain.

**Done when** SPF (single record), the DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`, MX is correct if the domain receives mail, CAA is either empty/permissive or intentionally reviewed, and the real production mail-header proof is assigned to Phase 12. &nbsp;·&nbsp; **⏱ ~20–30 min (+ propagation)** &nbsp;·&nbsp; 🔀 mixed (👤 DNS records + provider, 🤖 verification).
:::

## Background

:::note[SHOULD — deliverability]
A CodeCanyon app sends password resets, receipts, and notifications. Without SPF/DKIM/DMARC those land in spam — or get rejected. This page authenticates your sending domain.
:::

```mermaid
flowchart LR
  App[Laravel mailer] --> ESP[Email provider]
  ESP --> DNS[SPF + DKIM + DMARC DNS]
  DNS --> Inbox[Recipient inbox]
  DNS --> Reject[Reject / spam folder]
```

## Steps

### 1. Verify the email provider and record credentials

Confirm which service sends mail (Postmark, SES, Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.

:::note[Who does this]
🔀 **User + Agent** — 👤 the user owns provider login, account authorization, and any secret/API-key creation. 🤖 With browser automation and an authorized session, the agent can drive the non-secret console flow, capture the DNS records, and verify provider state. Use [vendor console automation](/tech-stack/laravel/codecanyon/learn/guides/vendor-console-automation/) for the browser path.
:::

Record the SMTP/API credentials into the production `.env` (`MAIL_*`) from **[3 · Production .env](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/03-production-env/)** — double-quoted, never committed.

### 2. Add the three records and understand what each does

| Record | Type | Answers | Without it |
|---|---|---|---|
| **SPF** | `TXT` | Which servers may send for this domain | Mail flagged as spoofed |
| **DKIM** | `TXT` | Cryptographic signature proving integrity | Tampering undetectable; spam scoring |
| **DMARC** | `TXT` | Policy when SPF/DKIM fail + where to report | No alignment policy; inconsistent delivery |

:::note[Who does this]
🔀 **User + Agent** — DNS publication changes public infrastructure, so 👤 the user authorizes the change or provides an authorized provider session/API token. 🤖 The agent can prepare the records, drive non-secret console clicks when authorized, and verify with `dig`.
:::

<Steps>

1. **Publish the SPF record** — one `TXT` at the root, listing every sender. Merge into a single record — multiple SPF records is itself a failure.

   ```text title="DNS records"
   example.com.  TXT  "v=spf1 include:_spf.provider.com ~all"
   ```

   - ✅ A single SPF `TXT` record exists at the root, listing every sender.

2. **Publish the DKIM record** — your provider gives a selector and key; publish it at the selector host they specify.

   ```text title="DNS records"
   selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public-key>"
   ```

   - ✅ The DKIM key is published at the provider's selector host.

   :::note[CNAME-based DKIM — Hostinger Titan and similar]
   Some providers publish DKIM as **CNAME** records pointing at the provider's key host, rather than a TXT key. Hostinger Titan, for example, uses three CNAME selectors:

   ```text title="DNS records"
   hostingermail-a._domainkey.example.com.  CNAME  hostingermail-a.dkim.mail.hostinger.com.
   hostingermail-b._domainkey.example.com.  CNAME  hostingermail-b.dkim.mail.hostinger.com.
   hostingermail-c._domainkey.example.com.  CNAME  hostingermail-c.dkim.mail.hostinger.com.
   ```

   Verify CNAME-based selectors with `dig CNAME`, not `dig TXT`:

   ```bash
   for sel in hostingermail-a hostingermail-b hostingermail-c; do
     dig +short CNAME "${sel}._domainkey.example.com"
   done
   # Expected: each resolves to its hostingermail-*.dkim.mail.hostinger.com target
   ```

   Publish exactly the selectors your provider specifies — for Hostinger Titan all three must resolve, or DKIM signing fails.
   :::

3. **Publish the DMARC record** — start at `p=none` (monitor only), collect reports, then tighten to `quarantine`/`reject`.

   ```text title="DNS records"
   _dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
   ```

   - ✅ A DMARC `TXT` record at `_dmarc.<domain>` starts at `p=none`.

</Steps>

### 3. Add MX records (if the domain receives mail)

If the domain also **receives** mail, add the provider's MX records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be omitted — match your provider's guidance.

<Steps>

1. **Publish the MX records** at the provider's priorities.

   ```text title="DNS records"
   example.com.  MX  10 mx1.provider.com.
   example.com.  MX  20 mx2.provider.com.
   ```

   - ✅ MX records are present if the domain receives mail (or correctly omitted if send-only).

</Steps>

### 4. Interpret CAA safely

CAA records restrict **which certificate authorities** may issue for the domain. The risk is not "CAA exists"; the risk is a restrictive record that excludes the issuer your final SSL path uses.

:::caution[CAA interpretation]
Empty CAA is safe during bring-up. Cloudflare-managed permissive multi-issuer CAA is also benign. A restrictive single-issuer record such as only `letsencrypt.org` can break Cloudflare/Google Trust Services or another final issuer later, so flag it before final cert hardening in **[Phase 7 · Security & monitoring → Headers & packages, step 7](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/02-security-headers-packages/)**.
:::

:::note[Why the risk is real — a concrete renewal example]
The danger with CAA is that the failure is **silent and delayed**. A stale CAA record does not break anything today — it breaks renewal weeks later, long after the change that caused it.

Worked example: Cloudflare switched issuing CAs in 2024 for many zones. A domain that had previously added `CAA 0 issue "letsencrypt.org"` could keep working until its existing cert expired, then fail renewal when Cloudflare tried to issue through Google Trust Services. Without renewal monitoring, you find out only when a user reports the HTTPS error.

```bash
   dig +short CAA example.com
   # Expected: empty OR permissive multi-issuer CAA.
   # On fail: a restrictive single-CA record omits the active/final issuer — review before SSL hardening.
   ```

This is why final CAA tightening is bundled with renewal-failure monitoring in Phase 7. If you add CAA before then, scope it to both the current and likely successor issuer rather than a single CA.
:::

### 5. Verify with `dig`

Read the resolver output directly. Do not treat a real test email as Phase 4 work — that is [RUN-LIVE] proof and belongs in production after the app can actually send mail.

<Steps>

1. **Confirm all records resolve.**

   ```bash
   dig +short TXT example.com            | grep spf1     # SPF present, single record
   dig +short TXT selector._domainkey.example.com         # DKIM key resolves
   dig +short TXT _dmarc.example.com     | grep DMARC1    # DMARC policy present
   dig +short MX  example.com                              # MX (if receiving mail)
   # Expected: one SPF line, the DKIM key, a DMARC1 policy, and MX records (if receiving mail)
   ```

   :::caution[`dig` quoting pitfall]
   Pass the record type and domain as separate arguments: `dig +short MX example.com`. Do **not** quote them as one string (`dig +short "MX example.com"`), which makes `dig` treat the whole string as the query name and return empty even when the MX record exists.
   :::

   - ✅ SPF (single), DKIM, DMARC, and MX (if receiving) all resolve.

2. **Record the live-mail proof owner.** The real send/receive test happens in [Phase 12 Step 3 · Harden, verify & sync](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/12-production/03-harden-verify-sync/) after production SMTP settings and the live app exist.

	   - ✅ Phase 12 owns the live mail-header proof; Phase 4 owns DNS record resolution only.

</Steps>

### Troubleshooting

| Symptom | Cause | Fix |
|---|---|---|
| `spf=softfail`/`fail` | Sender not in SPF `include` | Add the provider's include; keep one SPF record |
| `dkim=none` | Selector record missing/typo'd | Re-publish exactly as the provider specifies |
| `dmarc` ignored | Record at wrong host | Must be `_dmarc.<domain>`, not the root |
| Multiple SPF records | Two `TXT v=spf1` entries | Merge into one |
| Restrictive CAA before cert strategy | Only one CA is allowed and it is not your active/final issuer | Add the intended issuer now, or add a `Zaj-BACKLOG.md` Phase 7 renewal-monitoring row with owner, trigger, and acceptance |

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **👤 Provider verified** — email provider verified; `MAIL_*` recorded in production `.env`.
- [ ] **🔀 Records resolve** — SPF (single record), DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`.
- [ ] **👤 MX correct** — MX records correct if the domain receives mail.
- [ ] **🤖 CAA interpreted** — CAA is empty/permissive, or restrictive CAA has a named `Zaj-BACKLOG.md` cert-strategy follow-up before Phase 7 hardening.
- [ ] **🤖 RUN-LIVE owner recorded** — real mail-header proof is assigned to Phase 12 after production can send mail.

:::next[Next step]
[Cloudflare CDN](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/06-cloudflare-cdn/)
:::

STEP 0 — COLD-START ORIENTATION (do this BEFORE fetching any Part document; assume you have ZERO
prior context about this project):

1. Locate + identify. Run `pwd`. Read the project's `AGENTS.md` + `CLAUDE.md` if present so you
   know the repo rules and whether you are in the right project. Then read `Zaj-PROJECT.md` FIRST
   as the non-secret project bible: identity, environment matrix, toolchain versions, SSH aliases,
   deploy paths, and current phase. If `Zaj-PROJECT.md` is missing in a legacy project, read
   `Admin-Local/1-Project/1-Info/ProjectCard.md` as fallback, then create/update `Zaj-PROJECT.md`.

2. Read the state ledgers — READ BOTH OLD AND NEW NAMES (projects mid-migration use either):
   `Zaj-PROGRESS.md` OR `PROGRESS.md` (what earlier phases/steps already did, what's in-flight),
   `Zaj-BACKLOG.md` OR `BACKLOG.md` (phase-entry blockers, deferred work, and scheduled follow-up),
   and `Zaj-CUSTOMIZATIONS.md` OR `_CUSTOMIZATIONS.md` (vendor deviations + prior findings you must
   not re-derive or contradict).

3. Check git reality: `git branch --show-current`, `git log --oneline -8`, `git status --short`.
   - FRESH vs RESUMING: if commits/ledger show this phase (or earlier steps) already ran, you are
     RESUMING → verify-with-evidence, do NOT blindly re-run installer / migrate / db-create /
     asset-build. (This is the contract's reconcile rule.)
   - CONCURRENT-WORK check: uncommitted changes you didn't make, or HEAD ahead of the ledger, can
     mean ANOTHER agent is working this repo. Coordinate around hot files; do not commit over
     unrelated work. Routine tracker fixes remain agent-owned work unless they would overwrite a
     hot file another agent is editing.

4. Inherit rules + safety: skim `.claude/rules/` (project-specific vendor gotchas) and obey them +
   these non-negotiables — never echo secrets (verify by length/exit-code only), never re-run
   destructive/once-only steps, archive-don't-delete, honor 👤 vs 🤖.

5. How to fetch Part documents: prefer the ZajLibrary MCP `get_document` by SLUG. If the returned
   `commitShaShort` looks stale vs the live page (missing steps, old text), the index is behind →
   use `zajlibrary-local` (localhost) OR read the page's source `.mdx` directly from the ZajLibrary
   repo. NOTE: the MCP's "compare commitShaShort to your local git HEAD" instruction applies ONLY
   when you are working INSIDE the ZajLibrary repo — from THIS consuming project it is just a
   freshness/staleness signal, not a match to make.

6. Where to record: write current-truth facts to `Zaj-PROJECT.md`; write vendor deviations to
   `Zaj-CUSTOMIZATIONS.md`; write execution state to `Zaj-PROGRESS.md`; write blockers/deferred
   work to `Zaj-BACKLOG.md`. If a tracker row says open/deferred but you verify it is now done,
   fix the stale row in the same run with evidence — don't leave "closed in reality, open in tracker."
   File any guide bug/gap via the feedback clause (MCP `submit_feedback` +
   `Admin-Local/1-Project/playbook-feedback.md`) — log-then-continue, don't silently work around.

Only after Step 0 is complete, begin fetching Part 1.

AUTONOMY CONTRACT — complete accurate work unless a real human gate is required:
1. Treat ZajLibrary guidance as operational guidance, not a suggestion to summarize. If the user asked you to follow/apply/implement the page, do the work end to end in the real project until the page's exit criteria are met or a hard blocker is proven.
2. Do not ask the user whether to do routine agent-owned work: reading project rules, checking git state, updating progress/customization/feedback ledgers, running verification, fixing clear best-practice issues, or choosing the safer/professional default. Do it, cite evidence, and report what changed.
3. Ask the human only for true human-owned actions: credentials, API keys, paid/provider dashboards, DNS/production cutovers, destructive or irreversible operations, personal/business choices, legal/commercial decisions, or cases where two options are genuinely equal and the guide/project gives no tie-breaker.
4. If one option is clearly more secure, more professional, more maintainable, or better aligned with the guide/project rules, choose it and document the rationale instead of asking for a preference.
5. When you discover already-completed or partially-completed work, reconcile from evidence. Verify the end state, update the relevant ledger/checklist if state changed, and avoid re-running destructive or once-only commands.
6. Banned routine asks: "should I update trackers?", "should I commit?", "should I run verification?", "should I fix the stale ledger?", or "which option do you prefer?" when the guide/project makes one option clearly better.
7. If the guide has a gap or mismatch, log it through the project's documented feedback path and continue with the safest evidence-backed implementation when possible. Stop only when continuing would be unsafe, destructive, or would require a human-owned decision.

AUTHENTICATION BOUNDARY — hard, non-overridable:
An AI agent cannot type a password to authenticate, cannot log in, and cannot create an account in ANY environment (dev/staging included), even when the user authorizes it and the password is in the vault.
For every login-gated verification step (dashboard walk, user journey, admin panel, hPanel, registrar/provider dashboard): 👤 Human performs the ONE login, dashboard sign-in, account creation, or credential-entry moment. 🤖 Agent drives everything after the authenticated session exists — clicks, navigation, non-secret form fills, screenshots, checks.
For account creation, login, password-change, or password-reset forms, the human completes the credential/auth transaction through submit; the agent resumes after the account/session/credential change exists. Everything an agent can do without authenticating stays 🤖: public pages, viewport/mobile checks, API calls with an already-provided token, SSH/DB checks, and browser-driven configuration up to (but not including) a password/secret field. Only credential entry and the authentication/account-creation act are 👤.

Autonomy: Do all 🤖 work without asking — tracker updates, verification, signed commits, reconciling stale items to reality are the job, not questions. Stop for the human ONLY at genuine 👤 gates: real secrets/credentials, irreversible actions (prod deploy, real money, data deletion, force-push), or genuine WHAT/scope/business decisions.

Full ≠ optional: Autonomy does not mean minimal. Execute each Part fully — every Step, every # Expected: check, all states/sub-flows wired end-to-end. Never ship a happy-path subset as "done." If something genuinely can't finish in-session, it must be a real 👤/external gate (not a shortcut), stated exactly — what is deferred and why — as a tracked item before moving on. When the user says "do fully," honor it to completion.

EXECUTION CONTRACT — full coverage, no silent skips:
1. Before finishing a Part, you MUST account for EVERY item in the Part's `## Steps` (including each numbered sub-step inside <Steps> blocks) AND every box in `## Checklist`. Nothing is implicitly done.
2. Scope labels are not skip permission. `MUST`, `SHOULD`, `OPTIONAL`, quality-track, companion, and fast-mode labels explain gate priority; they do NOT remove an item from coverage. Default to FULL execution. Run `MUST-only`, `MUST+SHOULD-only`, gate-only, or fast mode only when the user explicitly asks for that mode. Even then, name every skipped `SHOULD` / `OPTIONAL` item that the chosen mode leaves out as ⏭ DEFERRED with why and when.
3. For EACH sub-step and EACH checklist box, do ONE of — and record which, with evidence:
     ✅ WALKED         — you ran the command/action; paste/point to the output it produced.
     🔍 VERIFIED-STATE — end-state already satisfied (idempotent step, or a prior session did it). Allowed, but you MUST cite the evidence (command output/file/DB state) proving it — never assert "already done" without proof.
     ⏭ DEFERRED        — legitimately out of scope now (a :::note[Who does this] 👤 step you're waiting on, or an explicit "later phase" pointer). State why + to when.
     ◐ PARTIAL         — some sub-parts done, some deferred; list exactly which and why.
4. Honor every `# Expected:` / ✅ bullet — compare actual output. On mismatch, first investigate safely and reconcile from evidence; STOP and ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices. Honor :::caution/:::danger as hard gates. Honor 👤 vs 🤖.
5. Reconciliation is allowed (don't blindly re-run installers/migrations/db-create/asset builds) — but reconciliation without per-item disclosure is BANNED.
6. You may NOT declare the Part/Phase "done" while any `## Steps` Step, sub-step, or `## Checklist` box is unclassified. Silent omission = incomplete.
7. Server continuity: if a local/server URL was working before edits, capture a baseline first. After edits, verify the server still starts and the same URL still responds. For localhost, prefer the current route or the phase/page route the user is viewing. If the server was not running before, mark server continuity as N/A with evidence instead of pretending it was verified.
8. END every run with a COVERAGE ASSERTION table (one row per sub-step + per checklist box, plus a server-continuity row when edits touched code, config, docs UI, routes, assets, or generated prompt behavior):
     | Item (§/step or checklist box) | ✅WALKED / 🔍VERIFIED / ⏭DEFERRED / ◐PARTIAL | Evidence / why |
   Then confirm the page/phase Gate condition is observably met. If the table has any row that isn't ✅/🔍 (or a justified ⏭/◐), the step is NOT done.
9. Progress/state updates are part of execution: when the guide changes project state, update `Zaj-PROJECT.md`, `Zaj-PROGRESS.md`, `Zaj-BACKLOG.md`, `Zaj-CUSTOMIZATIONS.md`, and/or `playbook-feedback.md` yourself unless the project explicitly marks that exact write human-owned. Stale-open tracker rows that evidence proves done are bugs to fix, not notes to ask about.
10. Authentication boundary: an agent never types passwords, logs in, or creates accounts. Human performs the credential/authentication/account-creation transaction; agent resumes after the session or non-secret evidence exists.
11. Secrets: never put keys/passwords/.env values in code, commits, or chat; verify by length/exit-code only.

TL;DR

Objective — make transactional email deliverable by authenticating the sending domain: verify the provider, add SPF/DKIM/DMARC (plus MX), interpret CAA safely, and confirm with dig — so password resets, receipts, and notifications don’t land in spam or get rejected.

Steps at a glance:

Verify the email provider and record credentials — Confirm which service sends mail (Postmark, SES, Mailgun, SendGrid, your host’s SMTP) and that the domain is verified there.
Add the three records and understand what each does — publish SPF, DKIM, and DMARC records, so outbound email can pass authentication instead of landing in spam.
Add MX records (if the domain receives mail) — If the domain also receives mail, add the provider’s MX records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be omitted — match your provider’s guidance.
Interpret CAA safely — empty CAA is fine; Cloudflare-managed permissive multi-issuer CAA is also fine. Flag restrictive single-issuer records before final certificate strategy.
Verify with dig — Read the resolver output directly and record the Phase 12 live-mail proof owner.

Background

flowchart LR
  App[Laravel mailer] --> ESP[Email provider]
  ESP --> DNS[SPF + DKIM + DMARC DNS]
  DNS --> Inbox[Recipient inbox]
  DNS --> Reject[Reject / spam folder]

Steps

1. Verify the email provider and record credentials

Confirm which service sends mail (Postmark, SES, Mailgun, SendGrid, your host’s SMTP) and that the domain is verified there.

Record the SMTP/API credentials into the production .env (MAIL_*) from 3 · Production .env — double-quoted, never committed.

2. Add the three records and understand what each does

Record	Type	Answers	Without it
SPF	`TXT`	Which servers may send for this domain	Mail flagged as spoofed
DKIM	`TXT`	Cryptographic signature proving integrity	Tampering undetectable; spam scoring
DMARC	`TXT`	Policy when SPF/DKIM fail + where to report	No alignment policy; inconsistent delivery

Publish the SPF record — one TXT at the root, listing every sender. Merge into a single record — multiple SPF records is itself a failure.
DNS records
```
example.com.  TXT  "v=spf1 include:_spf.provider.com ~all"
```
- ✅ A single SPF TXT record exists at the root, listing every sender.
Publish the DKIM record — your provider gives a selector and key; publish it at the selector host they specify.
DNS records
```
selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public-key>"
```
- ✅ The DKIM key is published at the provider’s selector host.
CNAME-based DKIM — Hostinger Titan and similar
Some providers publish DKIM as CNAME records pointing at the provider’s key host, rather than a TXT key. Hostinger Titan, for example, uses three CNAME selectors:
DNS records
hostingermail-a._domainkey.example.com. CNAME hostingermail-a.dkim.mail.hostinger.com. hostingermail-b._domainkey.example.com. CNAME hostingermail-b.dkim.mail.hostinger.com. hostingermail-c._domainkey.example.com. CNAME hostingermail-c.dkim.mail.hostinger.com.
Verify CNAME-based selectors with dig CNAME, not dig TXT:
Terminal window
for sel in hostingermail-a hostingermail-b hostingermail-c; do dig +short CNAME "${sel}._domainkey.example.com" done # Expected: each resolves to its hostingermail-*.dkim.mail.hostinger.com target
Publish exactly the selectors your provider specifies — for Hostinger Titan all three must resolve, or DKIM signing fails.
Publish the DMARC record — start at p=none (monitor only), collect reports, then tighten to quarantine/reject.
DNS records
```
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
```
- ✅ A DMARC TXT record at _dmarc.<domain> starts at p=none.

3. Add MX records (if the domain receives mail)

If the domain also receives mail, add the provider’s MX records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be omitted — match your provider’s guidance.

Publish the MX records at the provider’s priorities.
DNS records
```
example.com.  MX  10 mx1.provider.com.
example.com.  MX  20 mx2.provider.com.
```
- ✅ MX records are present if the domain receives mail (or correctly omitted if send-only).

4. Interpret CAA safely

CAA records restrict which certificate authorities may issue for the domain. The risk is not “CAA exists”; the risk is a restrictive record that excludes the issuer your final SSL path uses.

The danger with CAA is that the failure is silent and delayed. A stale CAA record does not break anything today — it breaks renewal weeks later, long after the change that caused it.

Worked example: Cloudflare switched issuing CAs in 2024 for many zones. A domain that had previously added CAA 0 issue "letsencrypt.org" could keep working until its existing cert expired, then fail renewal when Cloudflare tried to issue through Google Trust Services. Without renewal monitoring, you find out only when a user reports the HTTPS error.

   dig +short CAA example.com
   # Expected: empty OR permissive multi-issuer CAA.
   # On fail: a restrictive single-CA record omits the active/final issuer — review before SSL hardening.

This is why final CAA tightening is bundled with renewal-failure monitoring in Phase 7. If you add CAA before then, scope it to both the current and likely successor issuer rather than a single CA.

5. Verify with `dig`

Read the resolver output directly. Do not treat a real test email as Phase 4 work — that is [RUN-LIVE] proof and belongs in production after the app can actually send mail.

Confirm all records resolve.

dig +short TXT example.com            | grep spf1     # SPF present, single record
dig +short TXT selector._domainkey.example.com         # DKIM key resolves
dig +short TXT _dmarc.example.com     | grep DMARC1    # DMARC policy present
dig +short MX  example.com                              # MX (if receiving mail)
# Expected: one SPF line, the DKIM key, a DMARC1 policy, and MX records (if receiving mail)

✅ SPF (single), DKIM, DMARC, and MX (if receiving) all resolve.

Record the live-mail proof owner. The real send/receive test happens in Phase 12 Step 3 · Harden, verify & sync after production SMTP settings and the live app exist.
- ✅ Phase 12 owns the live mail-header proof; Phase 4 owns DNS record resolution only.

Troubleshooting

Symptom	Cause	Fix
`spf=softfail`/`fail`	Sender not in SPF `include`	Add the provider’s include; keep one SPF record
`dkim=none`	Selector record missing/typo’d	Re-publish exactly as the provider specifies
`dmarc` ignored	Record at wrong host	Must be `_dmarc.<domain>`, not the root
Multiple SPF records	Two `TXT v=spf1` entries	Merge into one
Restrictive CAA before cert strategy	Only one CA is allowed and it is not your active/final issuer	Add the intended issuer now, or add a `Zaj-BACKLOG.md` Phase 7 renewal-monitoring row with owner, trigger, and acceptance

Checklist

Do not mark this step done until every box below is checked.

👤 Provider verified — email provider verified; MAIL_* recorded in production .env.
🔀 Records resolve — SPF (single record), DKIM selector, and DMARC (p=none to start) all resolve via dig.
👤 MX correct — MX records correct if the domain receives mail.
🤖 CAA interpreted — CAA is empty/permissive, or restrictive CAA has a named Zaj-BACKLOG.md cert-strategy follow-up before Phase 7 hardening.
🤖 RUN-LIVE owner recorded — real mail-header proof is assigned to Phase 12 after production can send mail.

Cloudflare CDN

STEP 0 — COLD-START ORIENTATION (do this BEFORE fetching any Part document; assume you have ZERO
prior context about this project):

1. Locate + identify. Run `pwd`. Read the project's `AGENTS.md` + `CLAUDE.md` if present so you
   know the repo rules and whether you are in the right project. Then read `Zaj-PROJECT.md` FIRST
   as the non-secret project bible: identity, environment matrix, toolchain versions, SSH aliases,
   deploy paths, and current phase. If `Zaj-PROJECT.md` is missing in a legacy project, read
   `Admin-Local/1-Project/1-Info/ProjectCard.md` as fallback, then create/update `Zaj-PROJECT.md`.

2. Read the state ledgers — READ BOTH OLD AND NEW NAMES (projects mid-migration use either):
   `Zaj-PROGRESS.md` OR `PROGRESS.md` (what earlier phases/steps already did, what's in-flight),
   `Zaj-BACKLOG.md` OR `BACKLOG.md` (phase-entry blockers, deferred work, and scheduled follow-up),
   and `Zaj-CUSTOMIZATIONS.md` OR `_CUSTOMIZATIONS.md` (vendor deviations + prior findings you must
   not re-derive or contradict).

3. Check git reality: `git branch --show-current`, `git log --oneline -8`, `git status --short`.
   - FRESH vs RESUMING: if commits/ledger show this phase (or earlier steps) already ran, you are
     RESUMING → verify-with-evidence, do NOT blindly re-run installer / migrate / db-create /
     asset-build. (This is the contract's reconcile rule.)
   - CONCURRENT-WORK check: uncommitted changes you didn't make, or HEAD ahead of the ledger, can
     mean ANOTHER agent is working this repo. Coordinate around hot files; do not commit over
     unrelated work. Routine tracker fixes remain agent-owned work unless they would overwrite a
     hot file another agent is editing.

4. Inherit rules + safety: skim `.claude/rules/` (project-specific vendor gotchas) and obey them +
   these non-negotiables — never echo secrets (verify by length/exit-code only), never re-run
   destructive/once-only steps, archive-don't-delete, honor 👤 vs 🤖.

5. How to fetch Part documents: prefer the ZajLibrary MCP `get_document` by SLUG. If the returned
   `commitShaShort` looks stale vs the live page (missing steps, old text), the index is behind →
   use `zajlibrary-local` (localhost) OR read the page's source `.mdx` directly from the ZajLibrary
   repo. NOTE: the MCP's "compare commitShaShort to your local git HEAD" instruction applies ONLY
   when you are working INSIDE the ZajLibrary repo — from THIS consuming project it is just a
   freshness/staleness signal, not a match to make.

6. Where to record: write current-truth facts to `Zaj-PROJECT.md`; write vendor deviations to
   `Zaj-CUSTOMIZATIONS.md`; write execution state to `Zaj-PROGRESS.md`; write blockers/deferred
   work to `Zaj-BACKLOG.md`. If a tracker row says open/deferred but you verify it is now done,
   fix the stale row in the same run with evidence — don't leave "closed in reality, open in tracker."
   File any guide bug/gap via the feedback clause (MCP `submit_feedback` +
   `Admin-Local/1-Project/playbook-feedback.md`) — log-then-continue, don't silently work around.

Only after Step 0 is complete, begin fetching Part 1.

# ZajLibrary — implementation playbook

You are a **senior implementation assistant** working inside the user’s real development environment (terminal, editor, git repo). You are **not** a documentation writer, tutor, or library editor.

**Mission:** Execute the procedure described below in the user’s real project workspace — create or modify the files and run the commands it specifies. Do not just summarize it.

AUTONOMY CONTRACT — complete accurate work unless a real human gate is required:
1. Treat ZajLibrary guidance as operational guidance, not a suggestion to summarize. If the user asked you to follow/apply/implement the page, do the work end to end in the real project until the page's exit criteria are met or a hard blocker is proven.
2. Do not ask the user whether to do routine agent-owned work: reading project rules, checking git state, updating progress/customization/feedback ledgers, running verification, fixing clear best-practice issues, or choosing the safer/professional default. Do it, cite evidence, and report what changed.
3. Ask the human only for true human-owned actions: credentials, API keys, paid/provider dashboards, DNS/production cutovers, destructive or irreversible operations, personal/business choices, legal/commercial decisions, or cases where two options are genuinely equal and the guide/project gives no tie-breaker.
4. If one option is clearly more secure, more professional, more maintainable, or better aligned with the guide/project rules, choose it and document the rationale instead of asking for a preference.
5. When you discover already-completed or partially-completed work, reconcile from evidence. Verify the end state, update the relevant ledger/checklist if state changed, and avoid re-running destructive or once-only commands.
6. Banned routine asks: "should I update trackers?", "should I commit?", "should I run verification?", "should I fix the stale ledger?", or "which option do you prefer?" when the guide/project makes one option clearly better.
7. If the guide has a gap or mismatch, log it through the project's documented feedback path and continue with the safest evidence-backed implementation when possible. Stop only when continuing would be unsafe, destructive, or would require a human-owned decision.

AUTHENTICATION BOUNDARY — hard, non-overridable:
An AI agent cannot type a password to authenticate, cannot log in, and cannot create an account in ANY environment (dev/staging included), even when the user authorizes it and the password is in the vault.
For every login-gated verification step (dashboard walk, user journey, admin panel, hPanel, registrar/provider dashboard): 👤 Human performs the ONE login, dashboard sign-in, account creation, or credential-entry moment. 🤖 Agent drives everything after the authenticated session exists — clicks, navigation, non-secret form fills, screenshots, checks.
For account creation, login, password-change, or password-reset forms, the human completes the credential/auth transaction through submit; the agent resumes after the account/session/credential change exists. Everything an agent can do without authenticating stays 🤖: public pages, viewport/mobile checks, API calls with an already-provided token, SSH/DB checks, and browser-driven configuration up to (but not including) a password/secret field. Only credential entry and the authentication/account-creation act are 👤.

## Metadata
- title: 5 · DNS email records
- url: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/05-dns-email/
- shelf: Build & Create
- doc_type: implementation playbook
- status: current
- kind: playbook
- category: tech-stack
- subcategory: laravel
- topic: codecanyon
- phase: 4
- part_number: 5 (legacy stepNumber frontmatter)
- legacy_step_number: 5
- est_time: ~20–30 min (+ propagation)
- description: Make transactional email deliverable — verify the email provider, add SPF, DKIM, and DMARC records (plus MX), interpret CAA safely, and confirm everything with dig.
- tags: codecanyon, dns, email, deliverability

## Execution rules (binding)
- This is Part 5 of phase 4 (~20–30 min (+ propagation)) — execute this Part fully, then stop at its `## Checklist`.
- Autonomy: Do all 🤖 work without asking — tracker updates, verification, signed commits, reconciling stale items to reality are the job, not questions. Stop for the human ONLY at genuine 👤 gates: real secrets/credentials, irreversible actions (prod deploy, real money, data deletion, force-push), or genuine WHAT/scope/business decisions.
- Full ≠ optional: Autonomy does not mean minimal. Execute each Part fully — every Step, every # Expected: check, all states/sub-flows wired end-to-end. Never ship a happy-path subset as "done." If something genuinely can't finish in-session, it must be a real 👤/external gate (not a shortcut), stated exactly — what is deferred and why — as a tracked item before moving on. When the user says "do fully," honor it to completion.
- For playbooks, treat a Part as the `.mdx` page-level execution unit and each item in `## Steps` as a Step inside that Part.
- Follow `## Steps` in order. Do not skip Steps or declare the work complete early.
- Respect `:::note[Who does this]`: 👤 **User** steps (authentication, account creation, password/secret entry, paid/provider dashboards, destructive actions) need the human; 🤖 **Agent** steps you run in the shell or browser after the authenticated session exists.
- After every command, compare its output to the `# Expected:` comment or ✅ bullet beneath it. If it differs, investigate safely and reconcile from evidence first; ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices.
- Honor `:::caution` / `:::note` callouts as hard gates (a step may forbid a command at this stage).
- Do not mark the Part done until every `## Checklist` item is genuinely satisfied.
- Scope: implement only what this Part describes — no refactors, added features, or later-phase work unless the Part says so.
- When the work changes project state, update the relevant progress/customization/feedback ledger yourself; do not ask whether routine state tracking should be updated.
- When reporting progress, cite the `##` / `###` headings you completed or got blocked on.
- Secrets: never put API keys, passwords, or `.env` values in frontend code, commits, or chat logs — use server-side `.env` / config only, and keep `.env` gitignored.
- EXECUTION CONTRACT — full coverage, no silent skips:
1. Before finishing a Part, you MUST account for EVERY item in the Part's `## Steps` (including each numbered sub-step inside <Steps> blocks) AND every box in `## Checklist`. Nothing is implicitly done.
2. Scope labels are not skip permission. `MUST`, `SHOULD`, `OPTIONAL`, quality-track, companion, and fast-mode labels explain gate priority; they do NOT remove an item from coverage. Default to FULL execution. Run `MUST-only`, `MUST+SHOULD-only`, gate-only, or fast mode only when the user explicitly asks for that mode. Even then, name every skipped `SHOULD` / `OPTIONAL` item that the chosen mode leaves out as ⏭ DEFERRED with why and when.
3. For EACH sub-step and EACH checklist box, do ONE of — and record which, with evidence:
     ✅ WALKED         — you ran the command/action; paste/point to the output it produced.
     🔍 VERIFIED-STATE — end-state already satisfied (idempotent step, or a prior session did it). Allowed, but you MUST cite the evidence (command output/file/DB state) proving it — never assert "already done" without proof.
     ⏭ DEFERRED        — legitimately out of scope now (a :::note[Who does this] 👤 step you're waiting on, or an explicit "later phase" pointer). State why + to when.
     ◐ PARTIAL         — some sub-parts done, some deferred; list exactly which and why.
4. Honor every `# Expected:` / ✅ bullet — compare actual output. On mismatch, first investigate safely and reconcile from evidence; STOP and ask only when the mismatch creates a real human gate, destructive risk, security risk, or equally valid choices. Honor :::caution/:::danger as hard gates. Honor 👤 vs 🤖.
5. Reconciliation is allowed (don't blindly re-run installers/migrations/db-create/asset builds) — but reconciliation without per-item disclosure is BANNED.
6. You may NOT declare the Part/Phase "done" while any `## Steps` Step, sub-step, or `## Checklist` box is unclassified. Silent omission = incomplete.
7. Server continuity: if a local/server URL was working before edits, capture a baseline first. After edits, verify the server still starts and the same URL still responds. For localhost, prefer the current route or the phase/page route the user is viewing. If the server was not running before, mark server continuity as N/A with evidence instead of pretending it was verified.
8. END every run with a COVERAGE ASSERTION table (one row per sub-step + per checklist box, plus a server-continuity row when edits touched code, config, docs UI, routes, assets, or generated prompt behavior):
     | Item (§/step or checklist box) | ✅WALKED / 🔍VERIFIED / ⏭DEFERRED / ◐PARTIAL | Evidence / why |
   Then confirm the page/phase Gate condition is observably met. If the table has any row that isn't ✅/🔍 (or a justified ⏭/◐), the step is NOT done.
9. Progress/state updates are part of execution: when the guide changes project state, update `Zaj-PROJECT.md`, `Zaj-PROGRESS.md`, `Zaj-BACKLOG.md`, `Zaj-CUSTOMIZATIONS.md`, and/or `playbook-feedback.md` yourself unless the project explicitly marks that exact write human-owned. Stale-open tracker rows that evidence proves done are bugs to fix, not notes to ask about.
10. Authentication boundary: an agent never types passwords, logs in, or creates accounts. Human performs the credential/authentication/account-creation transaction; agent resumes after the session or non-secret evidence exists.
11. Secrets: never put keys/passwords/.env values in code, commits, or chat; verify by length/exit-code only.

---

# 5 · DNS email records

## TL;DR

**Objective** — make transactional email deliverable by authenticating the sending domain: verify the provider, add SPF/DKIM/DMARC (plus MX), interpret CAA safely, and confirm with `dig` — so password resets, receipts, and notifications don't land in spam or get rejected.

**Steps at a glance:**
1. **Verify the email provider and record credentials** — Confirm which service sends mail (Postmark, SES,
   Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.
2. **Add the three records and understand what each does** — publish SPF, DKIM, and DMARC records, so outbound
   email can pass authentication instead of landing in spam.
3. **Add MX records (if the domain receives mail)** — If the domain also receives mail, add the provider's MX
   records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be
   omitted — match your provider's guidance.
4. **Interpret CAA safely** — empty CAA is fine; Cloudflare-managed permissive multi-issuer CAA is also fine.
   Flag restrictive single-issuer records before final certificate strategy.
5. **Verify with `dig`** — Read the resolver output directly and record the Phase 12 live-mail proof owner.

:::note[User part + done-when]
**👤 User part** — the TXT/MX records are added in your DNS provider's dashboard, and the sending domain is verified in the email provider's console (Postmark/SES/Mailgun/SendGrid). An agent can run every `dig` check, but a person publishes the records and verifies the domain.

**Done when** SPF (single record), the DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`, MX is correct if the domain receives mail, CAA is either empty/permissive or intentionally reviewed, and the real production mail-header proof is assigned to Phase 12. &nbsp;·&nbsp; **⏱ ~20–30 min (+ propagation)** &nbsp;·&nbsp; 🔀 mixed (👤 DNS records + provider, 🤖 verification).
:::

## Background

:::note[SHOULD — deliverability]
A CodeCanyon app sends password resets, receipts, and notifications. Without SPF/DKIM/DMARC those land in spam — or get rejected. This page authenticates your sending domain.
:::

```mermaid
flowchart LR
  App[Laravel mailer] --> ESP[Email provider]
  ESP --> DNS[SPF + DKIM + DMARC DNS]
  DNS --> Inbox[Recipient inbox]
  DNS --> Reject[Reject / spam folder]
```

## Steps

### 1. Verify the email provider and record credentials

Confirm which service sends mail (Postmark, SES, Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.

:::note[Who does this]
🔀 **User + Agent** — 👤 the user owns provider login, account authorization, and any secret/API-key creation. 🤖 With browser automation and an authorized session, the agent can drive the non-secret console flow, capture the DNS records, and verify provider state. Use [vendor console automation](/tech-stack/laravel/codecanyon/learn/guides/vendor-console-automation/) for the browser path.
:::

Record the SMTP/API credentials into the production `.env` (`MAIL_*`) from **[3 · Production .env](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/03-production-env/)** — double-quoted, never committed.

### 2. Add the three records and understand what each does

| Record | Type | Answers | Without it |
|---|---|---|---|
| **SPF** | `TXT` | Which servers may send for this domain | Mail flagged as spoofed |
| **DKIM** | `TXT` | Cryptographic signature proving integrity | Tampering undetectable; spam scoring |
| **DMARC** | `TXT` | Policy when SPF/DKIM fail + where to report | No alignment policy; inconsistent delivery |

:::note[Who does this]
🔀 **User + Agent** — DNS publication changes public infrastructure, so 👤 the user authorizes the change or provides an authorized provider session/API token. 🤖 The agent can prepare the records, drive non-secret console clicks when authorized, and verify with `dig`.
:::

<Steps>

1. **Publish the SPF record** — one `TXT` at the root, listing every sender. Merge into a single record — multiple SPF records is itself a failure.

   ```text title="DNS records"
   example.com.  TXT  "v=spf1 include:_spf.provider.com ~all"
   ```

   - ✅ A single SPF `TXT` record exists at the root, listing every sender.

2. **Publish the DKIM record** — your provider gives a selector and key; publish it at the selector host they specify.

   ```text title="DNS records"
   selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public-key>"
   ```

   - ✅ The DKIM key is published at the provider's selector host.

   :::note[CNAME-based DKIM — Hostinger Titan and similar]
   Some providers publish DKIM as **CNAME** records pointing at the provider's key host, rather than a TXT key. Hostinger Titan, for example, uses three CNAME selectors:

   ```text title="DNS records"
   hostingermail-a._domainkey.example.com.  CNAME  hostingermail-a.dkim.mail.hostinger.com.
   hostingermail-b._domainkey.example.com.  CNAME  hostingermail-b.dkim.mail.hostinger.com.
   hostingermail-c._domainkey.example.com.  CNAME  hostingermail-c.dkim.mail.hostinger.com.
   ```

   Verify CNAME-based selectors with `dig CNAME`, not `dig TXT`:

   ```bash
   for sel in hostingermail-a hostingermail-b hostingermail-c; do
     dig +short CNAME "${sel}._domainkey.example.com"
   done
   # Expected: each resolves to its hostingermail-*.dkim.mail.hostinger.com target
   ```

   Publish exactly the selectors your provider specifies — for Hostinger Titan all three must resolve, or DKIM signing fails.
   :::

3. **Publish the DMARC record** — start at `p=none` (monitor only), collect reports, then tighten to `quarantine`/`reject`.

   ```text title="DNS records"
   _dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
   ```

   - ✅ A DMARC `TXT` record at `_dmarc.<domain>` starts at `p=none`.

</Steps>

### 3. Add MX records (if the domain receives mail)

If the domain also **receives** mail, add the provider's MX records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be omitted — match your provider's guidance.

<Steps>

1. **Publish the MX records** at the provider's priorities.

   ```text title="DNS records"
   example.com.  MX  10 mx1.provider.com.
   example.com.  MX  20 mx2.provider.com.
   ```

   - ✅ MX records are present if the domain receives mail (or correctly omitted if send-only).

</Steps>

### 4. Interpret CAA safely

CAA records restrict **which certificate authorities** may issue for the domain. The risk is not "CAA exists"; the risk is a restrictive record that excludes the issuer your final SSL path uses.

:::caution[CAA interpretation]
Empty CAA is safe during bring-up. Cloudflare-managed permissive multi-issuer CAA is also benign. A restrictive single-issuer record such as only `letsencrypt.org` can break Cloudflare/Google Trust Services or another final issuer later, so flag it before final cert hardening in **[Phase 7 · Security & monitoring → Headers & packages, step 7](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/02-security-headers-packages/)**.
:::

:::note[Why the risk is real — a concrete renewal example]
The danger with CAA is that the failure is **silent and delayed**. A stale CAA record does not break anything today — it breaks renewal weeks later, long after the change that caused it.

Worked example: Cloudflare switched issuing CAs in 2024 for many zones. A domain that had previously added `CAA 0 issue "letsencrypt.org"` could keep working until its existing cert expired, then fail renewal when Cloudflare tried to issue through Google Trust Services. Without renewal monitoring, you find out only when a user reports the HTTPS error.

```bash
   dig +short CAA example.com
   # Expected: empty OR permissive multi-issuer CAA.
   # On fail: a restrictive single-CA record omits the active/final issuer — review before SSL hardening.
   ```

This is why final CAA tightening is bundled with renewal-failure monitoring in Phase 7. If you add CAA before then, scope it to both the current and likely successor issuer rather than a single CA.
:::

### 5. Verify with `dig`

Read the resolver output directly. Do not treat a real test email as Phase 4 work — that is [RUN-LIVE] proof and belongs in production after the app can actually send mail.

<Steps>

1. **Confirm all records resolve.**

   ```bash
   dig +short TXT example.com            | grep spf1     # SPF present, single record
   dig +short TXT selector._domainkey.example.com         # DKIM key resolves
   dig +short TXT _dmarc.example.com     | grep DMARC1    # DMARC policy present
   dig +short MX  example.com                              # MX (if receiving mail)
   # Expected: one SPF line, the DKIM key, a DMARC1 policy, and MX records (if receiving mail)
   ```

   :::caution[`dig` quoting pitfall]
   Pass the record type and domain as separate arguments: `dig +short MX example.com`. Do **not** quote them as one string (`dig +short "MX example.com"`), which makes `dig` treat the whole string as the query name and return empty even when the MX record exists.
   :::

   - ✅ SPF (single), DKIM, DMARC, and MX (if receiving) all resolve.

2. **Record the live-mail proof owner.** The real send/receive test happens in [Phase 12 Step 3 · Harden, verify & sync](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/12-production/03-harden-verify-sync/) after production SMTP settings and the live app exist.

	   - ✅ Phase 12 owns the live mail-header proof; Phase 4 owns DNS record resolution only.

</Steps>

### Troubleshooting

| Symptom | Cause | Fix |
|---|---|---|
| `spf=softfail`/`fail` | Sender not in SPF `include` | Add the provider's include; keep one SPF record |
| `dkim=none` | Selector record missing/typo'd | Re-publish exactly as the provider specifies |
| `dmarc` ignored | Record at wrong host | Must be `_dmarc.<domain>`, not the root |
| Multiple SPF records | Two `TXT v=spf1` entries | Merge into one |
| Restrictive CAA before cert strategy | Only one CA is allowed and it is not your active/final issuer | Add the intended issuer now, or add a `Zaj-BACKLOG.md` Phase 7 renewal-monitoring row with owner, trigger, and acceptance |

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **👤 Provider verified** — email provider verified; `MAIL_*` recorded in production `.env`.
- [ ] **🔀 Records resolve** — SPF (single record), DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`.
- [ ] **👤 MX correct** — MX records correct if the domain receives mail.
- [ ] **🤖 CAA interpreted** — CAA is empty/permissive, or restrictive CAA has a named `Zaj-BACKLOG.md` cert-strategy follow-up before Phase 7 hardening.
- [ ] **🤖 RUN-LIVE owner recorded** — real mail-header proof is assigned to Phase 12 after production can send mail.

:::next[Next step]
[Cloudflare CDN](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/06-cloudflare-cdn/)
:::

# 5 · DNS email records

> Source: https://library.zajapps.com/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/05-dns-email/

## TL;DR

**Objective** — make transactional email deliverable by authenticating the sending domain: verify the provider, add SPF/DKIM/DMARC (plus MX), interpret CAA safely, and confirm with `dig` — so password resets, receipts, and notifications don't land in spam or get rejected.

**Steps at a glance:**
1. **Verify the email provider and record credentials** — Confirm which service sends mail (Postmark, SES,
   Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.
2. **Add the three records and understand what each does** — publish SPF, DKIM, and DMARC records, so outbound
   email can pass authentication instead of landing in spam.
3. **Add MX records (if the domain receives mail)** — If the domain also receives mail, add the provider's MX
   records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be
   omitted — match your provider's guidance.
4. **Interpret CAA safely** — empty CAA is fine; Cloudflare-managed permissive multi-issuer CAA is also fine.
   Flag restrictive single-issuer records before final certificate strategy.
5. **Verify with `dig`** — Read the resolver output directly and record the Phase 12 live-mail proof owner.

:::note[User part + done-when]
**👤 User part** — the TXT/MX records are added in your DNS provider's dashboard, and the sending domain is verified in the email provider's console (Postmark/SES/Mailgun/SendGrid). An agent can run every `dig` check, but a person publishes the records and verifies the domain.

**Done when** SPF (single record), the DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`, MX is correct if the domain receives mail, CAA is either empty/permissive or intentionally reviewed, and the real production mail-header proof is assigned to Phase 12. &nbsp;·&nbsp; **⏱ ~20–30 min (+ propagation)** &nbsp;·&nbsp; 🔀 mixed (👤 DNS records + provider, 🤖 verification).
:::

## Background

:::note[SHOULD — deliverability]
A CodeCanyon app sends password resets, receipts, and notifications. Without SPF/DKIM/DMARC those land in spam — or get rejected. This page authenticates your sending domain.
:::

```mermaid
flowchart LR
  App[Laravel mailer] --> ESP[Email provider]
  ESP --> DNS[SPF + DKIM + DMARC DNS]
  DNS --> Inbox[Recipient inbox]
  DNS --> Reject[Reject / spam folder]
```

## Steps

### 1. Verify the email provider and record credentials

Confirm which service sends mail (Postmark, SES, Mailgun, SendGrid, your host's SMTP) and that the domain is verified there.

:::note[Who does this]
🔀 **User + Agent** — 👤 the user owns provider login, account authorization, and any secret/API-key creation. 🤖 With browser automation and an authorized session, the agent can drive the non-secret console flow, capture the DNS records, and verify provider state. Use [vendor console automation](/tech-stack/laravel/codecanyon/learn/guides/vendor-console-automation/) for the browser path.
:::

Record the SMTP/API credentials into the production `.env` (`MAIL_*`) from **[3 · Production .env](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/03-production-env/)** — double-quoted, never committed.

### 2. Add the three records and understand what each does

| Record | Type | Answers | Without it |
|---|---|---|---|
| **SPF** | `TXT` | Which servers may send for this domain | Mail flagged as spoofed |
| **DKIM** | `TXT` | Cryptographic signature proving integrity | Tampering undetectable; spam scoring |
| **DMARC** | `TXT` | Policy when SPF/DKIM fail + where to report | No alignment policy; inconsistent delivery |

:::note[Who does this]
🔀 **User + Agent** — DNS publication changes public infrastructure, so 👤 the user authorizes the change or provides an authorized provider session/API token. 🤖 The agent can prepare the records, drive non-secret console clicks when authorized, and verify with `dig`.
:::

<Steps>

1. **Publish the SPF record** — one `TXT` at the root, listing every sender. Merge into a single record — multiple SPF records is itself a failure.

   ```text title="DNS records"
   example.com.  TXT  "v=spf1 include:_spf.provider.com ~all"
   ```

   - ✅ A single SPF `TXT` record exists at the root, listing every sender.

2. **Publish the DKIM record** — your provider gives a selector and key; publish it at the selector host they specify.

   ```text title="DNS records"
   selector._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<public-key>"
   ```

   - ✅ The DKIM key is published at the provider's selector host.

   :::note[CNAME-based DKIM — Hostinger Titan and similar]
   Some providers publish DKIM as **CNAME** records pointing at the provider's key host, rather than a TXT key. Hostinger Titan, for example, uses three CNAME selectors:

   ```text title="DNS records"
   hostingermail-a._domainkey.example.com.  CNAME  hostingermail-a.dkim.mail.hostinger.com.
   hostingermail-b._domainkey.example.com.  CNAME  hostingermail-b.dkim.mail.hostinger.com.
   hostingermail-c._domainkey.example.com.  CNAME  hostingermail-c.dkim.mail.hostinger.com.
   ```

   Verify CNAME-based selectors with `dig CNAME`, not `dig TXT`:

   ```bash
   for sel in hostingermail-a hostingermail-b hostingermail-c; do
     dig +short CNAME "${sel}._domainkey.example.com"
   done
   # Expected: each resolves to its hostingermail-*.dkim.mail.hostinger.com target
   ```

   Publish exactly the selectors your provider specifies — for Hostinger Titan all three must resolve, or DKIM signing fails.
   :::

3. **Publish the DMARC record** — start at `p=none` (monitor only), collect reports, then tighten to `quarantine`/`reject`.

   ```text title="DNS records"
   _dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
   ```

   - ✅ A DMARC `TXT` record at `_dmarc.<domain>` starts at `p=none`.

</Steps>

### 3. Add MX records (if the domain receives mail)

If the domain also **receives** mail, add the provider's MX records at the documented priorities. If it only sends (transactional-only), MX may point elsewhere or be omitted — match your provider's guidance.

<Steps>

1. **Publish the MX records** at the provider's priorities.

   ```text title="DNS records"
   example.com.  MX  10 mx1.provider.com.
   example.com.  MX  20 mx2.provider.com.
   ```

   - ✅ MX records are present if the domain receives mail (or correctly omitted if send-only).

</Steps>

### 4. Interpret CAA safely

CAA records restrict **which certificate authorities** may issue for the domain. The risk is not "CAA exists"; the risk is a restrictive record that excludes the issuer your final SSL path uses.

:::caution[CAA interpretation]
Empty CAA is safe during bring-up. Cloudflare-managed permissive multi-issuer CAA is also benign. A restrictive single-issuer record such as only `letsencrypt.org` can break Cloudflare/Google Trust Services or another final issuer later, so flag it before final cert hardening in **[Phase 7 · Security & monitoring → Headers & packages, step 7](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/07-security-monitoring/02-security-headers-packages/)**.
:::

:::note[Why the risk is real — a concrete renewal example]
The danger with CAA is that the failure is **silent and delayed**. A stale CAA record does not break anything today — it breaks renewal weeks later, long after the change that caused it.

Worked example: Cloudflare switched issuing CAs in 2024 for many zones. A domain that had previously added `CAA 0 issue "letsencrypt.org"` could keep working until its existing cert expired, then fail renewal when Cloudflare tried to issue through Google Trust Services. Without renewal monitoring, you find out only when a user reports the HTTPS error.

```bash
   dig +short CAA example.com
   # Expected: empty OR permissive multi-issuer CAA.
   # On fail: a restrictive single-CA record omits the active/final issuer — review before SSL hardening.
   ```

This is why final CAA tightening is bundled with renewal-failure monitoring in Phase 7. If you add CAA before then, scope it to both the current and likely successor issuer rather than a single CA.
:::

### 5. Verify with `dig`

Read the resolver output directly. Do not treat a real test email as Phase 4 work — that is [RUN-LIVE] proof and belongs in production after the app can actually send mail.

<Steps>

1. **Confirm all records resolve.**

   ```bash
   dig +short TXT example.com            | grep spf1     # SPF present, single record
   dig +short TXT selector._domainkey.example.com         # DKIM key resolves
   dig +short TXT _dmarc.example.com     | grep DMARC1    # DMARC policy present
   dig +short MX  example.com                              # MX (if receiving mail)
   # Expected: one SPF line, the DKIM key, a DMARC1 policy, and MX records (if receiving mail)
   ```

   :::caution[`dig` quoting pitfall]
   Pass the record type and domain as separate arguments: `dig +short MX example.com`. Do **not** quote them as one string (`dig +short "MX example.com"`), which makes `dig` treat the whole string as the query name and return empty even when the MX record exists.
   :::

   - ✅ SPF (single), DKIM, DMARC, and MX (if receiving) all resolve.

2. **Record the live-mail proof owner.** The real send/receive test happens in [Phase 12 Step 3 · Harden, verify & sync](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/12-production/03-harden-verify-sync/) after production SMTP settings and the live app exist.

	   - ✅ Phase 12 owns the live mail-header proof; Phase 4 owns DNS record resolution only.

</Steps>

### Troubleshooting

| Symptom | Cause | Fix |
|---|---|---|
| `spf=softfail`/`fail` | Sender not in SPF `include` | Add the provider's include; keep one SPF record |
| `dkim=none` | Selector record missing/typo'd | Re-publish exactly as the provider specifies |
| `dmarc` ignored | Record at wrong host | Must be `_dmarc.<domain>`, not the root |
| Multiple SPF records | Two `TXT v=spf1` entries | Merge into one |
| Restrictive CAA before cert strategy | Only one CA is allowed and it is not your active/final issuer | Add the intended issuer now, or add a `Zaj-BACKLOG.md` Phase 7 renewal-monitoring row with owner, trigger, and acceptance |

## Checklist

Do not mark this step done until **every** box below is checked.

- [ ] **👤 Provider verified** — email provider verified; `MAIL_*` recorded in production `.env`.
- [ ] **🔀 Records resolve** — SPF (single record), DKIM selector, and DMARC (`p=none` to start) all resolve via `dig`.
- [ ] **👤 MX correct** — MX records correct if the domain receives mail.
- [ ] **🤖 CAA interpreted** — CAA is empty/permissive, or restrictive CAA has a named `Zaj-BACKLOG.md` cert-strategy follow-up before Phase 7 hardening.
- [ ] **🤖 RUN-LIVE owner recorded** — real mail-header proof is assigned to Phase 12 after production can send mail.

:::next[Next step]
[Cloudflare CDN](/tech-stack/laravel/codecanyon/build/playbooks/setup-new/04-deploy-pipeline/06-cloudflare-cdn/)
:::