# Sending domains
> Every domain your mailboxes send from, with its SPF, DKIM and DMARC state, a custom tracking domain and a root redirect to your company website.
Source: https://docs.ayinbox.com/guides/sending-domains/
A sending domain is any domain one of your mailboxes has an address on. AY Inbox lists them for you, and from here you give each one a tracking host and a redirect for visitors to the bare domain.
Set up your domains [#set-up-your-domains]
Tick the domains in the list, or the box in the header for every domain shown.
In the bar at the bottom, choose **Tracking domain** or **Redirect**.
Set the tracking subdomain (`link` unless you change it) and the website to send visitors to.
Add the DNS records the dialog lists at your DNS provider, unless an inbox vendor sets them up for you.
Good to know [#good-to-know]
* There is nothing to add: connect a mailbox on `acme.io` and `acme.io` appears here.
* A tracking host is saved before its DNS record exists. Links keep using the shared tracking host until the record resolves.
* A redirect sends visitors to the bare domain on to your company's website, so the domain looks like part of a real business.
* Mail is unaffected: `MX`, SPF, DKIM and DMARC records live beside these and nothing here changes them.
* When an inbox vendor holds the domain, AY Inbox can forward it or write the tracking record there for you.
What a sending domain is [#what-a-sending-domain-is]
Browsing filters, searches and view choices are [remembered in your browser tab](/guides/browsing/) across refreshes and navigation, separately for each user and workspace.
A sending domain is any domain one of the workspace's mailboxes has an address on. AY Inbox builds the list from the mailboxes themselves, so there is nothing to add: connect a mailbox on `acme.io` and `acme.io` is here.
The same choices are offered per domain while [importing mailboxes](/guides/mailbox-import/#tracking-domains-and-root-redirects), so a new domain can be set up in one pass.
The domains list [#the-domains-list]
Each domain shows:
| Column | What it holds |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Mailboxes | How many of the workspace's mailboxes are on the domain, and who hosts their mail |
| Authentication | Whether SPF, DKIM and DMARC are published, and the domain's overall state. See [domain authentication](/guides/deliverability/#domain-authentication) |
| Tracking hosts | The [custom tracking domains](/guides/mailboxes/#custom-tracking-domain) the domain's mailboxes use, how many mailboxes use each, and whether each is verified |
| Redirect | Where visitors to the bare domain are sent, and whether the redirect is live |
| Vendor | The [inbox vendor](/guides/mailbox-import/#import-from-an-inbox-vendor) account that holds the domain, when one of the workspace's connected vendor accounts does, with its current forwarding and what its API can do for the domain |
One tracking host for a whole domain [#one-tracking-host-for-a-whole-domain]
A tracking host is normally set per mailbox. From the domain you can set one for every mailbox on it in one step, or clear it for all of them.
AY Inbox suggests a host: one a verified mailbox on the domain already uses, else one whose DNS already points at this instance (it tries `link`, `links`, `track`, `t`, `click`, `go`, `email` and `trk`), else `link.`. The suggestion comes with the `CNAME` value to add. A host the workspace has not verified before also needs the ownership `TXT` record; the `_ayinbox.` record a root redirect uses on the same domain covers it, and the result of saving the host shows the record when it is missing. `link` is the default because it reads as an ordinary link when a recipient hovers one.
The host is saved even before its DNS record exists. Until the record resolves, links keep using the shared tracking host, so nothing breaks; the hourly tracking check verifies the host by itself, and new sends switch to it from then on. Setting the same host again changes nothing.
When an inbox vendor account holds the domain and can write DNS records for it, AY Inbox can add the `CNAME` for you instead; see [domains held by an inbox vendor](#domains-held-by-an-inbox-vendor).
Set up many domains at once [#set-up-many-domains-at-once]
Tick domains in the list (or the box in the header for every domain shown; hold Shift to tick every row between two clicks) and a bar appears at the bottom:
| Action | What it does |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Tracking domain** | Opens the setup dialog below with the tracking domain on |
| **Redirect** | Opens the setup dialog below with the redirect on |
| **More > Check DNS now** | Re-checks every tracking host and redirect still waiting for DNS, instead of waiting for the next automatic check |
| **More > Copy DNS records to add** | Copies every record the picked domains still need, one per line with the domain, type, name and value, ready to paste into a sheet or a DNS provider's bulk import |
| **More > Export as CSV** | Downloads the picked domains with their mailboxes, authentication, tracking host, redirect and vendor |
| **More > Clear tracking domain** | After a confirmation, puts every mailbox on the picked domains back on the shared tracking host |
| **More > Remove redirect** | After a confirmation, stops each redirect, and removes vendor forwarding where the vendor's API allows it |
The setup dialog takes one base value for every picked domain:
* **Own tracking domain.** A subdomain, `link` unless you change it, set on each domain as `link.` for every mailbox on it. A domain whose tracking domain is already verified keeps it, unless you tick the option to replace those too.
* **Redirect the root to your website.** One website for every picked domain. It is filled in with the website most of your domains already redirect to, when there is one.
**Change per domain** opens a list of the picked domains, each with its own tracking host and website filled in from the base values. Type over either to give one domain something else, untick it to leave that domain out, or press **Reset** to put it back on the base values. Changing a base value later updates every domain nobody changed and leaves the changed ones alone.
The dialog says up front how many domains an [inbox vendor](#domains-held-by-an-inbox-vendor) sets up for you and how many need DNS you add. Each domain takes the easiest path on its own: the vendor writes the `CNAME` or forwards the root when its API can, and otherwise the host or redirect is saved and waits for DNS exactly as it would when set one domain at a time. When it finishes, the dialog lists the `CNAME` records still to add (with **Copy all**), the redirects waiting for DNS, and any domain that was refused and why. A refusal on one domain never stops the others, and running the same setup again changes nothing that is already in place.
While any domain still uses the shared tracking host or has no redirect, the top of the page says how many and offers **Set up all**, which opens the same dialog for exactly those domains. Dismissing it hides it until another domain needs setting up.
Root redirects [#root-redirects]
A domain bought for cold email usually answers nothing when someone types it into a browser. A recipient who checks who wrote to them, or a filter that looks at the domain, finds an empty page or an error, which reads as a throwaway domain. A redirect sends visitors to the bare domain (and its `www`) on to your company's main website instead, so the domain looks like what it is: part of a real business.
AY Inbox serves the redirect from this instance's tracking service once DNS proves two things: that you control the domain, and that its root points here. A self-hosted instance linked to AY Inbox Cloud can [have Cloud serve it](#serve-it-from-ay-inbox-cloud) instead, with nothing to set up on its own server.
Set one up [#set-one-up]
Enter the website to send visitors to, such as `https://yourcompany.com`. It must be an `http` or `https` address on one of your workspace's own domains: a domain you have a mailbox on, a verified tracking host, your verified [forms domain](/guides/forms/), a website you [confirmed](#confirm-your-website), or a subdomain of one of them. A redirect back to the same domain or its `www` is refused. A destination saved earlier that no longer qualifies, for example after the last mailbox on its domain is removed, is kept but shows **Not in use**, and the domain answers as if it had no redirect until you change it or confirm the website. **Include www** is on by default. AY Inbox then lists the records to add at your DNS provider:
| Purpose | Type | Name | Value | Needed to verify |
| --------- | -------------- | ------------------- | ----------------------------------------------- | ---------------- |
| Ownership | `TXT` | `_ayinbox.` | `ayinbox-verify=` | Yes |
| Root | `A` and `AAAA` | `` | The tracking host's public addresses, as listed | Yes |
| www | `CNAME` | `www.` | The tracking host | No |
The ownership value is unique to your workspace and the domain on this instance, so a record another workspace published proves nothing for yours. It is the same record a [Google Workspace admin grant](/guides/mailbox-import/#prove-the-workspace-controls-the-domain) accepts as proof, so a domain that has one for either needs nothing more for the other.
When the tracking host has no public address to list, the root record is shown as an `ALIAS` to the tracking host instead. A provider that offers `ALIAS`, `ANAME` or a flattened `CNAME` at the root can use that in place of the address records either way: AY Inbox compares the addresses the root resolves to.
The root of a domain has to point here for the redirect to work, so a domain whose root already serves a website is not a candidate. Mail is unaffected: `MX`, SPF, DKIM and DMARC records live beside these and nothing here changes them.
Confirm your website [#confirm-your-website]
Most teams keep their main website's domain out of cold outreach, so it is usually not a domain the workspace sends from. Confirm it once with a `TXT` record at that website's DNS provider:
| Type | Name | Value |
| ----- | --------------------------- | ------------------------ |
| `TXT` | `_ayinbox.` | `ayinbox-verify=` |
The record goes on the website's registrable domain (`yourcompany.com` for `https://www.yourcompany.com`), and confirming it covers every page and subdomain under it. Saving a redirect to a website that is not confirmed yet shows the record to add instead of saving; once it is in place, **Check and save** saves it. The value is unique to your workspace on this instance, like the ownership value, so another workspace's record confirms nothing for yours. Adding it changes nothing about how your website is served. One confirmation covers every sending domain that redirects there, and [form redirects](/guides/forms/#settings) too.
AY Inbox looks for the record again every 6 hours. When it is definitively gone, the website is no longer confirmed and redirects to it stop, showing the record to add again; a DNS lookup that fails or times out changes nothing. While a website is not confirmed, the redirect's progress shows that step with the record, and AY Inbox does not open the domain to check what visitors get, since it is holding the redirect back itself.
Verification [#verification]
A redirect verifies when the `TXT` record and the root record are both in place. The `www` record is optional; without it, only the bare domain redirects.
Verified DNS proves the domain points here, not that a visitor gets the redirect: a proxy in front of AY Inbox can still answer in its place. So once DNS verifies, AY Inbox opens the domain over `http` and `https` the way a visitor does, and the redirect shows **Live** when both lead to your website. When something answers in AY Inbox's place, it shows **Not reaching visitors**, says what answered, and counts under **Needs attention**. Two cases stay **Live** with a note instead, because the check cannot tell them from a working redirect: nothing answered the check at all, or the tracking service is still picking up a redirect that has just verified. See [when visitors do not get it](#when-visitors-do-not-get-it).
AY Inbox checks the records as soon as you save, whenever you press **Check now**, and on its own: every 10 minutes while the redirect is pending (for its first 14 days, then every 6 hours), every 10 minutes while it is verified but not reaching visitors (for 14 days after it verified, then every 6 hours), and every 6 hours once it is live. A verified redirect only stops when a check finds the records definitively gone or pointing elsewhere; a DNS lookup that fails or times out leaves it running, and so does a failed visit.
Saving the redirect again, to change the website or the `www` setting, keeps the same ownership value, so the `TXT` record you already added stays valid.
What visitors get [#what-visitors-get]
A visit to the domain (and to its `www` when included) answers with a `302` to the website you entered, cacheable for five minutes. The path they asked for is not carried over: every visit lands on that one address. The answer is temporary on purpose, so a change or a deletion reaches every visitor within minutes instead of lingering in browsers.
HTTPS needs a certificate for your domain. AY Inbox Cloud issues one on demand the first time someone visits, and only for a domain whose redirect is verified, including redirects it serves for a linked instance. A self-hosted instance installed with the bundled Caddy does the same. Behind an operator's own proxy, the proxy has to route the domain to the tracking service and hold a certificate for it; see [custom tracking domain](/guides/mailboxes/#custom-tracking-domain) for the same caveat.
When visitors do not get it [#when-visitors-do-not-get-it]
The redirect's tab says what the check saw and, for the usual causes, what to change:
| What the check saw | What it usually means | What to do |
| ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Another web server answered, often a `404`, and the tab names it when it can tell (Traefik, nginx, Caddy, Apache) | A proxy in front of AY Inbox only answers for the hostnames it was set up with | Add the domain wherever the tracking host is set up, since that one already reaches AY Inbox. The tab shows the exact change for Traefik, Coolify, Dokploy, nginx and Caddy |
| The tracking service answered but did not recognise the domain | The proxy sends the visit on under a different hostname | Pass the original `Host` header through, for example `proxy_set_header Host $host;` in nginx |
| The domain redirects somewhere else | Another redirect answers first: a proxy rule, or forwarding at the domain or DNS provider | Remove that redirect |
| `https` has no valid certificate | The proxy has no certificate for the domain | Add the domain to the proxy's configuration so it gets one |
| Nothing answers on port 80 or 443 | A firewall, or nothing listening | Open the port and make the proxy serve the domain |
When nothing answered the check at all, the redirect still shows **Live**, with a note to open the domain yourself: some networks do not let a server open its own public address, so the check cannot tell that apart from a working redirect. The same goes for the first minute after DNS verifies, while the tracking service picks the redirect up: the tab says so and checks again within 10 minutes.
For a proxy you run yourself, the change is the same wherever the tracking host is configured. With Traefik, extend the router rule that already routes the tracking host:
```text
Host(`t.example.com`) || Host(`acme.io`) || Host(`www.acme.io`)
```
With nginx, add the names to the server block that proxies the tracking service, keep the original hostname, and give it a certificate:
```nginx
server_name t.example.com acme.io www.acme.io;
proxy_set_header Host $host;
```
On a self-hosted instance linked to AY Inbox Cloud, the same tab also offers to skip all of this and [serve the redirect from AY Inbox Cloud](#serve-it-from-ay-inbox-cloud).
Serve it from AY Inbox Cloud [#serve-it-from-ay-inbox-cloud]
On a self-hosted instance [linked to AY Inbox Cloud](/guides/ayinbox-cloud/), a redirect has a **Served from** choice: **This server** or **AY Inbox Cloud**. Cloud serves the redirect and its certificate from its own tracking service, so nothing on your server has to route the domain. You point the root at the addresses Cloud lists and publish the ownership value it lists, which is Cloud's own and differs from your instance's.
* An instance that is not linked yet can link from right there: **Connect AY Inbox Cloud** under **Served from**, or in the fix for a redirect that is not reaching visitors, shows the code to approve on AY Inbox Cloud, and approving it moves on to serving the redirect from Cloud. When redirects are not reaching visitors, the top of the page offers the same for all of them at once.
* While the instance is linked, the dashboard picks AY Inbox Cloud for a new redirect (the API keeps this instance unless `served_by` says otherwise). Bulk setup has the same choice; there, a domain that already has a redirect keeps where it is served from unless you pick a server, and the dashboard asks before moving a live one.
* Cloud checks the records and opens the domain on its own schedule, the same one described above. Your instance shows Cloud's verdict, records and last visit, and reads them again on its own schedule and on **Check now**.
* Moving a redirect between this server and Cloud changes its root records, so a live redirect pauses until the new records are in place. The dashboard asks before it moves one.
* Your instance checks the website against your workspace's own domains, both when you save and on every check. A redirect Cloud serves whose website no longer qualifies is released from Cloud and stops until you change it.
* Only the domain, the website and the `www` setting go to Cloud. See [data control](/development/data-control/#outbound-calls).
* If Cloud cannot be reached when you save, the redirect is kept as waiting for Cloud and sent as soon as it answers. A redirect Cloud still serves that no workspace here has any more, after a workspace is deleted for example, is released within about half an hour.
* Disconnecting the instance, or unlinking it from AY Inbox Cloud, stops every redirect Cloud served for it. Each one then says so and can be moved back to this server. A redirect Cloud no longer has while the link is still up is put back by the next check.
Limits [#limits]
* The workspace must have a mailbox on the domain.
* The website must be on one of the workspace's own domains or a [confirmed website](#confirm-your-website), as described in [set one up](#set-one-up).
* Domains of shared email providers, such as `gmail.com` or `outlook.com`, are refused.
* One workspace per domain on an instance. While one workspace's redirect for a domain is verified, another workspace's redirect for it is refused with `domain_redirect_taken` and does not verify.
* The instance needs a tracking host (`TRACKING_DOMAIN`), because the tracking service is what answers. Without one, redirects are not offered, except from AY Inbox Cloud on a linked instance.
* AY Inbox Cloud serves up to 200 redirects for one linked instance.
Domains held by an inbox vendor [#domains-held-by-an-inbox-vendor]
A domain bought from an [inbox vendor](/guides/mailbox-import/#import-from-an-inbox-vendor) usually has its DNS hosted by that vendor, and most vendors can forward the domain themselves. When one of the workspace's connected vendor accounts holds a domain, the domain shows that vendor, and two shortcuts replace the DNS work above:
* **Forward through the vendor.** Enter the website, and AY Inbox asks the vendor to forward the domain's root to it. Nothing needs adding at a DNS provider and nothing is served by this instance. The website has the same rules as a redirect: an `http` or `https` address on one of your workspace's own domains, other than the domain itself. Clearing the website removes the forwarding where the vendor allows it.
* **Write the tracking record through the vendor.** Pick a tracking host under the domain, and AY Inbox writes its `CNAME` at the vendor, then sets the host on every mailbox on the domain. Where the vendor can write `TXT` records, AY Inbox writes the host's ownership record there too; those are the only records it writes. A record of the same name and type is replaced, and one the vendor manages itself is left alone and the write refused.
What each vendor's API allows:
| Vendor | Forwarding | Remove forwarding | Tracking `CNAME` |
| ------------- | ------------------------------------------------ | ----------------- | ---------------- |
| InboxKit | Yes | Yes | Yes |
| Zapmail | Yes | Yes | Yes |
| Cheap Inboxes | Yes | Yes | Yes |
| Maildoso | Yes | Yes | No |
| ScaledMail | Yes, as a request ScaledMail's staff apply later | Yes | No |
| Mailforge | Yes | No | No |
| Infraforge | Yes | No | No |
Mailforge and Infraforge replace a domain's whole record set on every DNS change, so AY Inbox writes no records there: one write could drop the domain's mail records. Add the tracking `CNAME` in their dashboard instead.
A [mailbox import](/guides/mailbox-import/#tracking-domains-and-root-redirects) uses these automatically. A root redirect chosen during an import uses the vendor's forwarding when a vendor account holds the domain and can forward it, and a redirect served by this instance otherwise. A tracking host chosen during an import has its `CNAME` written through the vendor when the vendor can, and waits for you to add it otherwise.
The vendor's domain list is read with the workspace's own API key, only for connections that are active, and kept for five minutes. A vendor that does not answer is left out, so its domains show without a vendor until it does.
What travels in an export [#what-travels-in-an-export]
Redirects travel in a [workspace export](/guides/workspace-export-import/). They arrive unverified and are served once the destination's own check sees both records. One AY Inbox Cloud served for the source arrives served by the destination itself. The ownership value belongs to the workspace on the instance that issued it, so the destination lists its own value: publish that value in the `TXT` record, and point the root at the destination. A tracking host is part of each mailbox's settings and travels with the mailbox; it arrives unverified, and the destination's hourly check verifies it once the `CNAME` points at the destination and the destination's ownership value is published. Forwarding set through a vendor lives at the vendor and is unaffected by a move. [Confirmed websites](#confirm-your-website) do not travel: their record is bound to the source workspace, so the destination shows its own record to add for each website its redirects point at.
API [#api]
The routes under `/emails/domains` take a session or an API key: `READ_EMAILS` to list domains and read a tracking suggestion, `WRITE_EMAILS` for every change, and the member behind the key needs **Manage mailboxes**. They act on every domain in the workspace, so a key limited to some mailboxes is refused with `403 api_key_mailbox_limited`. See [sending domains](/api/endpoints/#sending-domains).
Related guides [#related-guides]
## Frequently asked questions
### Do I need to add my sending domains to AY Inbox?
No. AY Inbox builds the list from your mailboxes: connect a mailbox on a domain and that domain appears under Sending domains.
### What is a custom tracking domain?
A subdomain of your own, such as link.yourdomain.com, that carries your open and click tracking instead of the shared tracking host. You add a CNAME record at your DNS provider, plus an ownership TXT record for a host the workspace has not verified before, and links keep using the shared host until the record resolves.
### What does the root redirect do?
It sends visitors who type your bare sending domain into a browser on to your company's website, so a domain bought for cold email looks like part of a real business. It needs an ownership TXT record and the root pointed at AY Inbox.
### Does setting a tracking domain or redirect change my SPF, DKIM or DMARC?
No. MX, SPF, DKIM and DMARC records live beside these records, and nothing on the Sending domains page changes them.