Questions · Updated 2026-09-27

Should I send email from a subdomain or the root domain?

Send from a subdomain, not the root domain. POST /domains registers notify.example.com, GET /domains/{id} returns the records to publish in the example.com zone, and GET /deliverability/domains measures each sending domain's standing on its own.

Send from a subdomain rather than the root domain. Register notify.example.com with POST /domains, publish the records GET /domains/{id} returns in the example.com zone, and the reputation your application mail earns belongs to that subdomain alone. GET /deliverability/domains measures standing per sending domain, so the root and the subdomain are scored separately.

Why the subdomain

Domains and DNS puts it this way: "Send from mail.yourdomain.com or notifications.yourdomain.com rather than the apex. The reputation of your receipts and your password resets then cannot be damaged by anything else the company sends, and the reverse is also true." The measurement matches the advice. GET /deliverability/domains returns "Every sending domain with its standing over the window, worst first", one row per domain with bounce_rate, complaint_rate, sent and standing. A domain in trouble is its own row; it does not average into the others.

What you publish for a subdomain

POST /domains with name: "notify.example.com". The response and GET /domains/{id} return zone, which is the zone you edit at your DNS provider (example.com here), and every record with name (the full name), host (the name relative to that zone, which is what a DNS panel asks for) and value. Paste host, not name; a panel appends the zone itself.

curl -sS -X GET https://api.agentisend.com/domains/9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42 \
  -H "Authorization: Bearer $AGENTISEND_API_KEY"
200
{
  "click_tracking": true,
  "created_at": "2026-09-04T09:14:00Z",
  "dkim_selector": "string",
  "id": "9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42",
  "name": "yourdomain.com",
  "open_tracking": true,
  "provider_hints": {},
  "recent_events": []
}
Response

The rows for notify.example.com: the DKIM TXT on as1._domainkey.notify.example.com (the selector is dkim_selector on the response), the return-path MX and TXT on send.notify.example.com (return_path_subdomain is send, or bounce when send is taken), the SPF TXT on notify.example.com itself, and the DMARC TXT on _dmarc.notify.example.com. Each row carries required and status, so you can see which rows verification waits on and which are advice. POST /domains/{id}/verify re-checks them.

The root keeps its own records

Choosing a subdomain changes nothing on the root. If anything else sends as example.com, the root's SPF record stays where it is; the SPF we hand out lives on notify.example.com. Where a name already has an SPF record, merge rather than add, because two SPF records on one name invalidate both; Can I have two SPF records on one domain? has the merged form.

Pick the name you will keep. The catalogue message for domain_field_immutable is "Name, region, and return-path cannot change on an existing domain." How many sending domains a plan includes is on the pricing page, and GET /billing/plan returns it as entitlements.max_domains.

Next