## The three records

| Record | Type | What it says |
|---|---|---|
| SPF | TXT at the apex | Which servers may send mail claiming to be your domain. |
| DKIM | TXT at a provider-specified subdomain | A public key that signs each message, proving it was not altered. |
| DMARC | TXT at `_dmarc` | What receivers should do when SPF or DKIM fails. |

Resend generates the SPF and DKIM values for you when you add a domain. Copy them exactly, including
the trailing values, and wait for verification in their dashboard before testing.

## Start DMARC permissive

```
v=DMARC1; p=none; rua=mailto:you@yourdomain.com
```

`p=none` means "do not reject anything, but send me reports". That gives you the data to see what is
actually failing before you start rejecting mail. Move to `p=quarantine` and then `p=reject` once the
reports are clean. Starting at `p=reject` on a new domain is how people silently lose their own
password reset emails.

## SPF has a hard limit

Ten DNS lookups, total, across the whole record including anything it includes. Stacking providers
by adding `include:` for each one exceeds it quietly, and once over the limit the entire record fails
rather than the last entry. If you send from more than two services, check the count.

## Then the app side, which is two variables

```bash
bin/kamal app exec 'bin/rails runner "puts ActionMailer::Base.delivery_method"'
```

`RESEND_API_KEY` and `MAIL_FROM` are all the app needs. The from address has to be at the domain you
verified, or the provider rejects the send regardless of DNS.

## Verify with a real inbox

Send yourself a sign-in code at a Gmail address and open the message headers. Gmail shows SPF, DKIM
and DMARC results directly. Three passes means it is right; anything else names which record to fix.

## The delay nobody warns you about

DNS propagation plus provider verification is usually minutes and occasionally hours. A test that
fails ten minutes after you add the records has told you nothing yet.