Verify a domain

You don't need a verified domain to start. New accounts can send immediately from a shared onboarding domain in test mode. Verifying your own domain is what lets you email anyone, from your own brand, fully white-labeled.

01 Add the domain

Add a domain in the dashboard on the Domains page, or over the API. The response is the domain plus the exact DNS records to publish — every record references only your own domain, never the underlying mail provider.

curl https://api.drin.run/v1/domains \
  -H "Authorization: Bearer $DRIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "domain": "mail.acme.com" }'

The new domain comes back with status: "pending" and a records array. Each record carries a purpose (dkim, mail_from, or dmarc) and a verified flag that starts false:

{
  "id": "dom_8a1c…",
  "domain": "mail.acme.com",
  "status": "pending",
  "records": [
    {
      "type": "TXT",
      "name": "drin1._domainkey.mail.acme.com",
      "value": "v=DKIM1; k=rsa; p=MIGfMA0GCS…",
      "purpose": "dkim",
      "verified": false
    },
    {
      "type": "MX",
      "name": "send.mail.acme.com",
      "value": "feedback-smtp.us-east-1.example",
      "priority": 10,
      "purpose": "mail_from",
      "verified": false
    },
    {
      "type": "TXT",
      "name": "send.mail.acme.com",
      "value": "v=spf1 include:amazonses.com ~all",
      "purpose": "mail_from",
      "verified": false
    },
    {
      "type": "TXT",
      "name": "_dmarc.mail.acme.com",
      "value": "v=DMARC1; p=none;",
      "purpose": "dmarc",
      "verified": false
    }
  ]
}

02 Publish the DNS records

Copy each record from the response (or the dashboard) into your DNS provider exactly as given — the type, name(host), value, and, for the MX record, the priority. The values are unique to your domain, so always take them from your own Add-domain response, never from this page.

• DKIM — a TXT (or CNAME) record at a ._domainkey host. This is what actually authorizes sending.
• MAIL FROM — an MX and a TXT (SPF) record on a send. subdomain. These align the return-path so receivers — and Gmail's "mailed-by" — see your domain, not ours.
• DMARC — a TXT record at _dmarc. Drin seeds p=none so you can monitor before you enforce.

03 Verify

DNS changes can take anywhere from a minute to a few hours to propagate. Drin checks for your records automatically on a background schedule. To check immediately after pasting them, hit Verify now in the dashboard, or call the verify endpoint — it re-checks your records right now and returns the fresh status.

curl -X POST https://api.drin.run/v1/domains/dom_8a1c…/verify \
  -H "Authorization: Bearer $DRIN_API_KEY"

1. 1

   pending

   Records are saved but not yet confirmed in DNS. We keep re-checking in the background; you can keep refreshing.
2. 2

   verified

   DKIM is confirmed and the domain can send. MAIL FROM and DMARC often confirm a beat later than DKIM — that's normal, and each record's verified flag reflects the truth independently.
3. 3

   failed

   We couldn't find the records after repeated checks. Re-check the host and value against your Add-domain response — a trailing dot or a wrapped value is the usual culprit — then verify again.

04 Send from it

Once status is verified, use any address at that domain as your from. The cleanest pattern is to look up your verified domains in code so you never hardcode an address that might not be ready yet:

// Pick a verified domain to send from, in code.
const [d] = await drin.domains.listVerified();

await drin.emails.send({
  from: { email: `hello@${d.domain}` },
  to: [{ email: "customer@example.com" }],
  subject: "Welcome to Acme",
  html: "<p>Your account is ready.</p>",
});

05 Test mode vs. your own domain

The shared onboarding domain exists so you can integrate and ship a working send before touching DNS. It runs in test mode and can only deliver to your own account's address — perfect for development, useless for production. Verifying your own domain lifts that restriction and white-labels every message.

06 White-label

Drin uses BYODKIM, so the key lives in your DNS and every customer-facing record points at your domain. Combined with the custom MAIL FROM, recipients see your domain in the mailed-by and signed-by lines — there is no mention of the sending infrastructure anywhere a recipient looks. Your customers' mail looks like it came straight from you, because as far as the receiving mail server is concerned, it did.