Use your own Amazon Route 53 account to serve your domains' DNS

What connecting it does for you

Connecting your own AWS account lets a domain's DNS be served from your account instead of ours. You keep the zone, the bill and the vendor dashboard; we create and update the records your sites and mailboxes need, so you do not copy them by hand.

Before you start

An AWS account. Route 53 charges per hosted zone and per query on your AWS bill.

Create an IAM user for this connection with a policy that allows route53:ListHostedZones, route53:ListResourceRecordSets and route53:ChangeResourceRecordSets.

1. Create the key at AWS

In the AWS console open IAM → Users, choose the user this connection should act as (create a dedicated one — never use your root account), open its Security credentials tab and, under Access keys, choose Create access key. Pick Other as the use case, continue, and choose Create access key. Copy the Access key ID and the Secret access key — AWS shows the secret once. Each IAM user can hold two keys at a time.

2. Connect it here

Open Integrations in your dashboard and choose Connect an account. Pick Your own DNS as the group and Amazon Route 53 as the account, fill in Access key ID and Secret access key, and press Connect account.

We test what you paste before anything is saved. A key that does not work is never stored, and the answer says what was wrong with it. A key that works is kept encrypted in our secrets vault — never in our database — and is never shown again, not even to you.

What happens next

• On any domain, open its DNS tab and choose this account as where the domain's

DNS is served from. We create the zone there if it does not exist and write the records the domain's sites and mail need.

• When something on our side changes what a record must say — you move a site, switch CDN or

add a mailbox — we update the record on your account.

• To finish the move, your domain's nameservers must point at AWS. If the domain is

registered with us, or at a registrar you have connected, we set them for you; otherwise the domain's page shows the nameservers to set.

• When you connect, we check that the key can list your zones, read records and change records.

The checklist beside the connection shows which of those we could confirm.

If it does not connect

It connects, then a record change fails. Listing zones and changing records are separate IAM permissions, and the change is only checked the first time we make one. Add route53:ChangeResourceRecordSets to the user's policy — the key itself does not change.

AWS refused the credential. The access key has been deactivated or deleted in IAM.

It says the key was rejected. Almost always one of three things: a space or a line break copied with it, a key that has expired, or a key that was revoked or regenerated after you copied it. Create a fresh one and paste it again.

It connects, but something later fails. The key authenticates but lacks a permission the action needs. Create a new key with the permissions listed above, then disconnect the old connection and connect the new key.

Disconnecting

Open Integrations, find the account and press Disconnect. That deletes the stored key at once. Anything that was using it stops at its next action, and the screens that depended on it say so rather than failing quietly.

Disconnecting does not undo what was already done — records, deployments or settings we changed on your account stay as they are. If you think the key itself may have leaked, also revoke it at the vendor; disconnecting removes our copy, not theirs.