Domains

Authentication

Requires domains:read.

Worked example

curl https://spoolway.com/api/v1/domains/1 \
  -H "Authorization: Bearer spw_…"

{
  "data": {
    "id": 1,
    "name": "stale.example",
    "state": "verified",
    "status_label": "correct at last check — not yet re-verified",
    "check_is_stale": true,
    "verified_at": "2026-07-07T08:11:01+00:00",
    "failed_at": null,
    "last_checked_at": "2026-08-03T08:11:01+00:00",
    "records": [
      {
        "id": 1,
        "type": "TXT",
        "purpose": "OWNERSHIP",
        "name": "_spoolway.stale.example",
        "expected": "spoolway-verify=token",
        "observed": "spoolway-verify=token",
        "state": "ok",
        "checked_at": "2026-08-03T08:11:01+00:00",
        "verified_at": "2026-07-07T08:11:01+00:00"
      }
    ]
  }
}

DMARC reports

We read your _dmarc record daily and show the policy on the Domains screen, but that is advisory — it is your DNS, not ours. The reports themselves are the only view of your deliverability that does not come from us: mailbox providers send them, and they say what happened to mail claiming to be from your domain.

Receivers mail those reports to the address in your rua= tag. We take no inbound mail, so point rua= at a mailbox you own and forward what arrives to POST /v1/dmarc-reports with a key holding domains:read. The body is the report file itself — gzip, zip or plain XML — and ingestion is idempotent per report id, so forwarding the same file twice changes nothing.

A report about a domain nobody has added here is kept, not discarded — that is how somebody learns they are being spoofed. DMARC passes when either SPF or DKIM aligns, so a row failing one mechanism is not necessarily a failure.

24h honesty

failed_at is when the ownership check last failed; the next check that passes clears it. verified_at is when it last passed, and a failure does not clear it. While the failure is the later of the two, state is failing. Both are ISO 8601 timestamps, or null.