> ## Documentation Index
> Fetch the complete documentation index at: https://docs.onchainsuite.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Domain Verification

> Verify your sending domain — every DNS record, its live status, and exact fix instructions when records clash with what's already in your DNS.

## How verification works

Sending email from your own domain requires proving ownership and authenticating your mail. Onchain Suite provisions your domain and gives you **five DNS records** to add at your DNS provider:

| Record     | Type                              | Purpose                                | Required to send? |
| ---------- | --------------------------------- | -------------------------------------- | ----------------- |
| Ownership  | TXT at `@`                        | Proves you control the domain          | Yes               |
| SPF        | TXT at `@`                        | Authorizes our servers to send for you | Yes               |
| DKIM 1 & 2 | CNAME at `selector1/2._domainkey` | Cryptographically signs your mail      | Yes               |
| DMARC      | TXT at `_dmarc`                   | Tells inboxes how to treat failures    | Recommended       |

A domain is **send-ready** when Ownership, SPF, and both DKIM records verify. Ownership alone is not enough.

## The flow

1. **Register** — `POST /domain` with your domain. The response includes the complete `dns` record set immediately, so you can add everything in one DNS session.
2. **Add the records** at your DNS provider.
3. **Verify** — `POST /domain/{id}/verify`, or watch `GET /domain/{id}/dns` update live as records propagate.
4. **Done** — on completion your `noreply@yourdomain` sender is created automatically and campaigns can send from your domain.

## Live status for every record

`GET /domain/{id}/dns` returns each record with its live verification state:

```json theme={"dark"}
{
  "sendReady": false,
  "verificationStates": {
    "domain": "Verified",
    "spf": "NotStarted",
    "dkim": "VerificationFailed",
    "dkim2": "NotStarted",
    "dmarc": "NotStarted"
  },
  "records": [
    {
      "type": "CNAME",
      "host": "selector1._domainkey",
      "value": "selector1-....azurecomm.net",
      "verification": "VerificationFailed",
      "conflict": {
        "reason": "A CNAME already exists at selector1._domainkey pointing to \"selector1.mailprovider.example\" (likely a previous email provider).",
        "resolution": "Edit ONLY the CNAME at \"selector1._domainkey\" from \"selector1.mailprovider.example\" to \"selector1-....azurecomm.net\" — change nothing else.",
        "actions": [
          {
            "action": "edit",
            "type": "CNAME",
            "host": "selector1._domainkey",
            "currentValue": "selector1.mailprovider.example",
            "newValue": "selector1-....azurecomm.net"
          }
        ]
      }
    }
  ],
  "fixes": [
    "DKIM Record 1: Edit ONLY the CNAME at \"selector1._domainkey\" from \"selector1.mailprovider.example\" to \"selector1-....azurecomm.net\" — change nothing else."
  ]
}
```

## Conflict detection — when a record "won't verify"

Most stuck verifications aren't missing records — they're **clashes with records that already exist**. Onchain Suite checks your live DNS and tells you exactly what to change:

* **Two SPF records** — multiple `v=spf1` records make SPF fail entirely. We compute the exact merged record to publish, tell you which record to keep and edit, and name the specific record(s) to delete — everything else in your DNS is left alone.
* **Existing SPF without our include** — never add a second SPF record; we return the merged value to edit into your existing one.
* **DKIM name occupied** — a previous email provider's CNAME (edit it to our value) or an old TXT key squatting the selector name (delete only that TXT, then add the CNAME).
* **Existing DMARC** — informational only; your existing policy is fine.

Every fix is **surgical**: instructions quote the exact record values to edit or delete, so you never risk removing unrelated records (site verifications, other providers' tokens).

## Tips

* Your registrar may show the host as `selector1._domainkey` or `selector1._domainkey.yourdomain.com` — both are the same record.
* SPF and Ownership both live at `@` (the domain root) as TXT records — they coexist fine; only a *second* `v=spf1` record is a problem.
* DNS changes usually propagate in minutes but can take up to an hour depending on your provider's TTL.