Sending domains

Browsing filters, searches and view choices are remembered in your browser tab 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. Warmbly 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, so a new domain can be set up in one pass.

Each domain shows:

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.

Warmbly 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.<domain>. The suggestion comes with the CNAME value to add. 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, Warmbly can add the CNAME for you instead; see domains held by an inbox vendor.

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:

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.<domain> 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 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.

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.

Warmbly 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 Warmbly Cloud can have Cloud serve it instead, with nothing to set up on its own server.

Set one up

Enter the website to send visitors to, such as https://yourcompany.com. It must be an http or https address on another host; a redirect back to the same domain or its www is refused. Include www is on by default. Warmbly then lists the records to add at your DNS provider:

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 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: Warmbly 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.

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 Warmbly can still answer in its place. So once DNS verifies, Warmbly 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 Warmbly'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.

Warmbly 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

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. Warmbly 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 for the same caveat.

When visitors do not get it

The redirect's tab says what the check saw and, for the usual causes, what to change:

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:

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:

server_name t.example.com acme.io www.acme.io;
proxy_set_header Host $host;

On a self-hosted instance linked to Warmbly Cloud, the same tab also offers to skip all of this and serve the redirect from Warmbly Cloud.

Serve it from Warmbly Cloud

On a self-hosted instance linked to Warmbly Cloud, a redirect has a Served from choice: This server or Warmbly 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 Warmbly Cloud under Served from, or in the fix for a redirect that is not reaching visitors, shows the code to approve on Warmbly 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 Warmbly 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.
• Only the domain, the website and the www setting go to Cloud. See data control.
• 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 Warmbly 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

• The workspace must have a mailbox on the domain.
• 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 Warmbly Cloud on a linked instance.
• Warmbly Cloud serves up to 200 redirects for one linked instance.

A domain bought 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 Warmbly 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 another host. 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 Warmbly writes its CNAME at the vendor, then sets the host on every mailbox on the domain. It is the only record Warmbly 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:

Mailforge and Infraforge replace a domain's whole record set on every DNS change, so Warmbly writes no records there: one write could drop the domain's mail records. Add the tracking CNAME in their dashboard instead.

A mailbox import 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.

Redirects travel in a workspace export. They arrive unverified and are served once the destination's own check sees both records. One Warmbly 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. Forwarding set through a vendor lives at the vendor and is unaffected by a move.