A domain you own is the one email address no provider can take from you. Put your aliases on it and they become portable, brandable, and killable one by one. Five DNS records, no mail server of your own, about thirty minutes of careful typing. I run AliasFleet, an email-alias service, and this is the guide for readers who already know what an email alias is and want the serious version. It follows the generic alias setup guide, that covers the methods; this is the DNS half.
Why a domain you own changes the deal
The move is portability: with the addresses on your domain, the service underneath is replaceable. Switch providers and you change five DNS records while the addresses stay the same, and nobody you ever signed up to needs to know. Try that on a shared alias domain and you find the catch: leave the service, lose the addresses. Your own domain turns the service into a commodity, which is exactly what you want.
It also removes friction at signup forms. Some reject known shared alias domains on sight; your own domain looks like any ordinary address, so most of that disappears. And for anything that invoices or emails customers, orders@yourdomain is simply more credible.
The per-alias discipline stays: one address per site, as always. The address that leaks dies on its own while the rest of the domain keeps working.
The price is that the DNS is now yours to maintain. Break a record and your mail breaks, and no alias service can fix your registrar. That is the full trade. If it sounds like too much, admit it and start on the free tier's managed subdomains instead, per the worked example below.
Before you touch your DNS
Two things before you open your registrar.
First, look up what the domain's MX records point at today. If it already receives mail somewhere, through Google Workspace, Microsoft 365, or your host, adding an alias service's MX records reroutes that inbound mail. The records hand the mail over; nothing gets added. addy.io's docs say this out loud. Decide which service owns inbound mail for the domain before adding a single record.
Second, know the five moves in order, because the order is the point:
- Register the domain in your alias service. It hands you an ownership verification record.
- Publish that TXT record at your registrar to prove the domain is yours.
- Add the two MX records, handing inbound mail to the alias service.
- Add SPF, DKIM, and DMARC, authorising sending and replies from the domain.
- Check each record as you add it, then send a test.
New to the forwarding, reply, and kill-switch mechanics? Read how email aliases actually work first. Everything below assumes you have that half.
The five records you are about to add
Every serious alias service follows the same record pattern: SimpleLogin's docs and addy.io's docs walk through it with their own hostnames, but the shape never changes. Your service's Domains page prints your account's exact values; use those, not mine. The values below are addy.io's real ones, one concrete example.
The ownership TXT record
```dns title="Ownership verification (example values from addy.io)"
Type: TXT
Host: @
Value: aa-verify=your-unique-value
The service hands you a unique string to publish in your DNS. Its checker sees the record and concludes the domain is yours. It is the anti-abuse step: it stops anyone pointing your domain at an alias service you never chose, and it can usually go once verification clears.
### The two MX records
```dns title="MX records (example values from addy.io)"
Type: MX
Host: @
Priority: 10
Value: mail.anonaddy.me.
Type: MX
Host: @
Priority: 20
Value: mail2.anonaddy.me.
The MX record is the delivery instruction for your mail. Cloudflare's DNS reference puts it plainly: without one, mail has nowhere to go. The priority field is a preference number; the lowest gets tried first, so 10 is the primary and 20 the backup. Old MX records pointing elsewhere must go first, or mail keeps landing at the old place. SimpleLogin's docs say the same about their mx1 and mx2 hosts.
The SPF record
```dns title="SPF record (example value from addy.io)"
Type: TXT
Host: @
Value: v=spf1 include:spf.anonaddy.me -all
SPF is a TXT record listing who may send mail for your domain; the `include:` mechanism authorises the alias service's servers. [easyDMARC's explainer](https://easydmarc.com/blog/what-is-an-spf-record/) covers the qualifiers: `-all` fails everything not listed, `~all` merely softfails it. Publish whichever your service specifies.
One rule bites: a domain gets exactly one SPF record. [PowerDMARC's syntax guide](https://powerdmarc.com/spf-syntax-guide/) calls a second `v=spf1` record an immediate error, so if you already have one for Google Workspace or a newsletter tool, merge the alias service's `include:` into it. Never publish a second.
### The DKIM records
```dns title="DKIM records (example values from addy.io)"
Type: CNAME
Host: dk1._domainkey
Value: dk1._domainkey.anonaddy.me.
Type: CNAME
Host: dk2._domainkey
Value: dk2._domainkey.anonaddy.me.
DKIM signs outgoing mail cryptographically. The service generates the key pair, holds the private key, and signs your sent mail with it; you publish the public key at a selector hostname like dk1._domainkey. Receiving servers fetch it and verify the signature. Two selectors is normal: it lets the service rotate keys without breaking signatures mid-flight.
The DMARC record
```dns title="DMARC record (example value from addy.io)"
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=quarantine; adkim=s
DMARC instructs receiving servers on SPF or DKIM failures; [Cloudflare's security records guide](https://developers.cloudflare.com/dmarc-management/security-records/) covers the three protocols together. Start lenient: [Cloudflare's email authentication docs](https://developers.cloudflare.com/email-service/concepts/email-authentication/) advise `p=none` to monitor first, then `quarantine`, then `reject` once legitimate mail authenticates cleanly.
Two registrar gotchas: if your DNS lives on Cloudflare, switch every mail record to DNS-only, since a proxied record will not verify, as addy.io's docs say outright. Second, some registrars expect `@` as the apex host while others want the field blank or the bare domain: same record, different label, and the panel makes it obvious which it wants.
## The AliasFleet worked example
On AliasFleet, custom domains are a Pro feature: three with catch-all routing on Pro, ten on Business. The [pricing page](https://aliasfleet.com/pricing) notes automated DNS diagnostics for MX, SPF, and DKIM that check your typing for you.
The AliasFleet flow mirrors the five moves above: you add the domain under Domains, and the page shows the exact records to publish, generated for your account, with diagnostics flagging anything wrong.
Then the [create-alias form](https://aliasfleet.com/docs/email-aliases/creating-aliases) lists your domain in the domain picker, and the new alias goes live at once.
The honest part of the pricing: the free tier has no full custom domain. It includes three managed subdomains instead, enough to run the per-site habit properly before spending anything. The [first-alias walkthrough](https://aliasfleet.com/docs/getting-started/your-first-alias) covers that route.
Two things worth knowing about how the product handles your domain. Replies and new sends go out through the [Quick Send composer](https://aliasfleet.com/docs/email-aliases/quick-send), sent from AliasFleet's servers, so the recipient never sees your real inbox address. And the kill switch is per alias: [deactivating an alias](https://aliasfleet.com/docs/email-aliases/activating-deactivating-alias) bounces mail back to the sender with nothing identifying you or the service, and flipping it back on restores it.
## How the other services do it
This is not an AliasFleet-only trick, and the shape elsewhere matters if you ever switch.
addy.io keeps custom domains behind a paid plan: free accounts cannot add them, Lite allows one, Pro allows twenty. Receiving needs only the two MX records. Sending and replies need the SPF record, both DKIM records, and DMARC. New domains ship with catch-all switched on, so unknown addresses reach your inbox unless you turn it off; all confirmed in their docs.
SimpleLogin documents the same pattern in its registrar guides: ownership TXT, two MX records at priorities 10 and 20, an SPF include, a DKIM CNAME, a DMARC record. addy.io's hostnames differ. The pattern does not.
That is the point: do this once and you can do it on any service, because the DNS half is standard and only the hostnames change.
## Test it before you trust it
Run the checks in order.
First, the MX records: [MXToolbox](https://mxtoolbox.com) queries your domain's authoritative nameserver, so you see changes without waiting on caches. If your alias service's hosts are not showing, nothing else matters yet; wait and re-check.
Send a test message to an alias on the domain from a second account. It should reach your destination inbox within seconds, labelled with the alias it arrived on. Reply and confirm the reply shows the alias as the sender, not your real address. That is SPF and DKIM proving themselves. If replies land in spam, look at the sending records first.
The failure order I see most often: MX not propagated, old MX records still winning, an unmerged SPF record, or the Cloudflare proxy left on. Memorise the order; it covers most support threads.
## The parts nobody warns you about
First, the MX handover is absolute: the moment the new MX records propagate, every address at that domain routes to the alias service, even ones you never turned into aliases. Checking your current MX records first is not optional. Catch-all behaviour decides where the unknown addresses land, so learn your service's default before the handover.
Second, the DNS debt is yours. Registrars expire, nameserver changes wipe records, and a domain moved without its record set stops receiving mail. Keep a copy of the five records somewhere outside the registrar. A text file works.
Third, nothing here fixes the past. The real address you have used for years is already sitting in breach files. Look it up on [Have I Been Pwned](https://haveibeenpwned.com) and move on. The custom domain stops the list growing and names every future leak. [Leak attribution](https://www.aliasfleet.com/blog/which-website-leaked-my-email) works on your own domain exactly as on a shared one: the alias names the source.
One more for businesses: role addresses like `orders@` and `billing@` belong on your domain as aliases, and [the small-business piece](https://www.aliasfleet.com/blog/email-aliases-for-small-business) covers the setup. Your bank does not go on an alias, on any domain. Money gets a boring permanent address.
## Start with one address
Make one alias on the domain, something low-stakes like a newsletter. Send the test, reply to it, then toggle the alias off and on and watch the kill switch work. Give the next signup its own alias, then the next.
Same [one-alias-per-site](https://www.aliasfleet.com/blog/different-email-for-every-website) system, on ground you own. Six months from now a vendor leaks the address you gave them; the spam names the vendor, you kill that one alias, and your domain carries on like nothing happened. Five DNS records for all of it. That is the payoff.
Top comments (0)