One-click DNS setup

Setting up a custom domain means publishing eight DNS records. You can copy them by hand from the dashboard, and that always works. Or you can let Maski publish them for you. On a custom domain that is not yet verified, the dashboard shows a Set up automatically panel above the manual record checklist.

​

Supported providers

Maski tries to detect your provider from your domain’s nameservers and preselects it. If the detection is wrong, or your provider is not listed, pick another one from the chooser or add the records by hand. If your provider is not listed, nothing is lost. The manual checklist below the panel has the same records, and a domain set up by hand is identical to one set up automatically.

​

Two ways to authorize

Paste an API token. You mint a token at your provider, scoped as narrowly as that provider allows, and paste it into Maski. This works on every provider listed above. The per-provider guides below walk through it. Connect directly. Where a provider offers it, you can click Connect with <provider> and approve Maski on the provider’s own consent screen. No token to mint or store. When a provider offers both, Maski leads with Connect and tucks the token field behind Prefer to paste an API token instead?

​

What Maski does with the credential

Your token is used for the one request that publishes the records, and is then discarded. It is never written to a database, a log, a background job, or the domain’s audit trail. There is no “revoke Maski’s access” screen in the dashboard because there is nothing held to revoke. This is also why the setup runs while you wait, with a loading state, rather than in the background. Queuing it would mean storing the secret somewhere. You can still revoke the token at your provider afterwards, and we recommend it. Maski does not need it again. If you later need to republish, mint a new one.

​

Review before anything is written

Pasting a token does not publish anything. Maski first reads your zone and shows you exactly what it would change:

• Add — records that do not exist yet.
• Update — records Maski manages whose value has changed.
• Leave untouched — records that are already correct, and any record of yours that Maski will not overwrite.
• Remove — mail routing that has to be replaced, and only that. See below.

Nothing is written until you press Publish records.

​

What Maski will and will not touch

Maski writes the eight records listed on custom domains: the ownership TXT, the inbound MX at your apex, up to three DKIM CNAME records, the bounce MX and bounce SPF TXT on bounces., and an advisory DMARC TXT. Two rules constrain that:

• An existing _dmarc record is never overwritten. If you already publish DMARC, Maski leaves your policy exactly as it is and reports the record as left untouched. Mail from Maski passes your DMARC through DKIM alignment either way.
• Existing mail routing at your apex is replaced only with your explicit confirmation. Maski intentionally converges your apex to one permanent MX hostname, so if another provider’s MX already sits there, Maski lists every one and asks you to tick a confirmation box before removing it. One hostname does not mean one Maski server: Maski can add active receiving-server IP addresses behind that target without asking you to change this record. Nothing else at your apex is affected: an A, AAAA, or TXT record at the same name is left alone, so your website keeps working.

Running setup twice is safe. The second run finds every record already correct and changes nothing.

​

After publishing

Publishing records is not the same as verifying them. Maski still re-checks your domain through public DNS every few minutes, and the domain only becomes active once every required record resolves and mail signing is fully in place. You can press Verify now to check immediately. A claim expires if it is not verified within 72 hours. Authorizing your provider does not shortcut that check. It only saves you the typing.

​

Guides