Questions · Updated 2026-09-27

What is the return-path record for?

The return-path record is a pair of DNS rows on send.yourdomain.com (or bounce.yourdomain.com), an MX and an SPF TXT, that let bounces come back to us and keep the envelope sender aligned with your domain. Both rows are required on a new domain; GET /domains/{id} lists them and POST /domains/{id}/verify checks them.

The return-path record is for two things: bounces and alignment. It is a pair of rows on a subdomain of your own domain, send.<domain> by default: an MX and an SPF TXT. The fix on each row says "Publish both records on this host so bounces come back to us and SPF stays aligned with your domain." Domains and DNS adds when it takes effect: "Return-path is used for the envelope sender only after both of its records resolve." Both rows are required on a new domain, so GET /domains/{id} lists them and the domain does not verify without them.

The two rows

Every email carries two sender addresses: the From your recipient sees, and the envelope sender that receiving servers answer to. Bounces go to the envelope sender, and SPF is checked against its domain. The return-path rows put that address on your domain instead of ours.

  • The MX on send.<domain> points at feedback.agentisend-dns.com, with the priority on the row. The guide says "The MX lets bounces come back to us", which is how a refusal turns into an email.bounced event and a verdict on GET /emails/{id}/explain. mta1.agentisend.com is the earlier target; the guide says it "still verifies if that is what is already published", and the row's fix then reads "This still points at mta1.agentisend.com, which we still accept. Point it at feedback.agentisend-dns.com when you next change DNS."
  • The TXT on send.<domain> is v=spf1 include:_spf.agentisend-dns.com -all. The guide says "the TXT keeps SPF aligned with your domain": the envelope sender's domain publishes an SPF record that authorises us, and that domain is yours. The timeline on GET /domains/{id}/events calls this row the "return-path SPF record".

Until both resolve, the guide says, "the envelope sender stays your From address. After they resolve, it becomes a signed address on send.notify.example.com." This is also why the SPF record on the sending domain itself is advice rather than a requirement: the SPF row's fix opens "Recommended, not required — the domain verifies and sends without a root SPF once the return-path records resolve."

send or bounce

return_path_subdomain on POST /domains is send or bounce. POST /domains reads the MX on the chosen host first. When it already points somewhere else, the request is refused with return_path_subdomain_in_use; the catalogue message is "The return-path host already has an MX record pointing somewhere else." and the fix is "Pass return_path_subdomain: "bounce" on POST /domains. send is the default; bounce is the alternative when send is taken." The choice is permanent: the catalogue message for domain_field_immutable is "Name, region, and return-path cannot change on an existing domain."

If the return-path host already has an SPF record of its own, merge rather than add; the guide says "The same merge rule applies on send. if that name already has an SPF record", and Can I have two SPF records on one domain? has the merge.

Publishing it

GET /domains/{id}/setup gives both rows with host relative to the zone you edit: send.notify for notify.example.com inside example.com, send when you send from the apex. Paste host, not name. The MX row carries priority; the TXT row carries value_strings. Then POST /domains/{id}/verify, and the timeline records "The return-path MX record was found." and "The return-path SPF record was found." One page per DNS host has the clicks: Cloudflare, Namecheap, GoDaddy, Route 53, Google Domains, Porkbun, Hostinger.

curl -sS -X GET https://api.agentisend.com/domains/9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42/setup \
  -H "Authorization: Bearer $AGENTISEND_API_KEY"
200
{
  "commands": {},
  "deep_link": "string",
  "detected": true,
  "domain": "string",
  "nameservers": [],
  "provider": {},
  "provider_hints": {},
  "records": []
}
Response

Next