--- title: Getting DNS records published when you do not control DNS metaTitle: DNS delegation and subdomain setup for agent email description: The technical setup takes ten minutes and the organisational one takes three weeks. Delegation, CNAME flattening, apex limitations, and how to hand records to whoever owns the zone. date: 2026-08-06 author: MCPmailer tags: Deliverability --- Publishing the records for an agent sending domain is a small technical task wrapped in an organisational one. In a company of any size, DNS belongs to a team that is not you, changes go through a queue, and the person who applies them has no context for what a DKIM CNAME is. ![Records that take ten minutes to write and three weeks to publish](/blog/dns-delegation-for-agent-domains/hero.webp "The technical part is minutes. The queue is the project.") Most of the delay in getting an agent live is here rather than anywhere in the software. ## Ask for a subdomain, not records on the apex The single change that makes this easier. Rather than requesting several records on `yourcompany.com`, ask for control of `agents.yourcompany.com`, delegated to you. Delegation means the DNS team adds NS records for that subdomain once, pointing at a zone you administer, and then never has to be involved again. You publish and change everything inside it, and their exposure is one change to a name they can reason about. The security argument usually lands: a delegated subdomain cannot affect the apex, cannot break the corporate mail flow, and can be revoked by deleting one record. ## When delegation is not possible Plenty of organisations will not delegate, so the fallback is publishing records in their zone. Make it easy to say yes. Hand over a table with exactly four columns: type, name, value, and purpose in one sentence. No screenshots, no instructions that assume a particular provider, and no ambiguity about whether the name is fully qualified. Most rejected DNS tickets are rejected for ambiguity rather than policy. | Type | Name | Purpose | | --- | --- | --- | | TXT | `_mcpmailer.agents.example.com` | Proves we control the subdomain | | MX | `agents.example.com` | Routes inbound mail for agents only | | TXT | `agents.example.com` | SPF, authorises the sending servers | | TXT | `_dmarc.agents.example.com` | Policy for mail failing alignment | | CNAME | three `._domainkey...` names | DKIM signing keys | Say explicitly that nothing here touches the apex domain or existing mail flow, because that is the question the DNS owner is actually asking. ## The apex problems, if you must use one Two constraints that bite when someone insists on sending from the root domain. **CNAME at the apex is not allowed** by the DNS specification, which matters because DKIM records are CNAMEs. Some providers offer flattening or ALIAS records that work around it, and behaviour varies, so this is worth testing rather than assuming. **The MX is already in use.** Adding an inbound MX to a domain that already receives mail competes with the existing provider, so skip it: inbound will not route, sending still works, and the domain still verifies. **SPF must be merged, not duplicated.** A domain may only have one SPF record. Fold the new include into the existing one rather than publishing a second, which is the most common way a working setup is broken by an addition. All three disappear on a subdomain, which is the practical argument for it beyond reputation isolation, per [deliverability for agent senders](/blog/agent-email-deliverability). ## Verification is not instant, and that is normal Propagation takes minutes to hours depending on the previous TTL, and DKIM confirmation can lag the DNS by a few more. A domain showing published records and pending DKIM is waiting rather than broken. Two practical habits. Lower the TTL before making changes if you can, so mistakes are cheap to correct. And do not repeatedly re-check in the first fifteen minutes, because a cached negative answer is exactly what you will keep getting. ![One delegated subdomain against five records in a corporate zone](/blog/dns-delegation-for-agent-domains/delegation.webp "One change they understand, or five they have to review.") ## Who owns this afterwards The part nobody plans. DNS records for a sending domain need an owner, because they will eventually be touched by someone doing something unrelated: a migration, a security review, a cleanup of records nobody recognises. Two cheap protections. Document what each record is for somewhere the DNS team can find it, since an undocumented TXT record is a deletion candidate during the next audit. And monitor them, so removal is noticed by you rather than by a customer whose mail stopped arriving, per [what to monitor in production](/blog/monitoring-email-agents-in-production). The failure this prevents is specific and common: authentication silently breaks, placement degrades over days, and nobody connects it to a DNS change made a fortnight earlier. ## Questions ### Should I ask for DNS delegation or individual records? Delegation of a subdomain, if you can get it. One NS change gives you control of everything inside it, and it cannot affect the apex or existing mail flow. ### What if the DNS team will not delegate? Hand them a table of type, name, value, and a one-sentence purpose per record, stating explicitly that nothing touches the apex or current mail routing. Ambiguity is what gets tickets rejected. ### Why can I not put DKIM CNAMEs on the apex? CNAME records are not permitted at a zone apex. Some providers offer flattening or ALIAS records, with varying behaviour, which is why a subdomain avoids the whole question. ### Can I add an MX record to a domain that already receives mail? You can, and it will compete with the existing provider. Skip it instead: inbound will not route to the agent, but sending works and the domain still verifies. ### Why did adding SPF break our email? Almost certainly a second SPF record. A domain may only have one, so the new include must be merged into the existing record rather than published separately. ### Verification says pending. Is something wrong? Usually not. Propagation takes minutes to hours and DKIM confirmation can lag it. Lower TTLs before changes, and avoid re-checking constantly, which caches negative answers. ## Related - [SPF, DKIM, and DMARC for an agent subdomain](/blog/dmarc-record-generator-agents) - [Deliverability for agent senders](/blog/agent-email-deliverability) - [What DMARC reports are actually telling you](/blog/reading-dmarc-reports) - [Domains in the docs](/docs/domains)