Connecting AWS Route 53 for one-click DNS fixes

What connecting actually gives you

Without a connection, trustyourinbox tells you what record to publish and you paste it into Route 53 yourself. With a connection, the same recommendation becomes a Fix this button. Every one-click fix runs through the same safety pipeline:

• a 5-minute delay before anything is written, during which you can cancel,
• an email paper trail telling you exactly what will change and what it was before,
• a read-back check in public DNS after the write, so you know it really landed,
• and a 24-hour undo that restores the previous value with one click.

The fixes cover DMARC (publishing a record, tightening policy), SPF, DKIM, and TLS-RPT. Newly added Route 53 domains also verify in one click: we publish the small ownership-proof TXT record for you instead of making you paste it.

The security model, before you create anything

You won't be handing us your AWS password or root credentials. The setup below creates a dedicated API-only IAM user in your AWS account with exactly three permissions: list your hosted zones, read and write records inside them, and check whether a change has propagated. It cannot create or delete zones, touch any other AWS service, see your bill, or sign in to the console.

We store the access key encrypted (AES-256-GCM, with the key held in infrastructure secrets, not the database) and never show it back to anyone, including you. You can kill the connection at any time from either side: click Disconnect in trustyourinbox, or deactivate the access key in AWS. Either one stops all writes immediately.

Step 1: Create an API-only IAM user

1. Open the AWS IAM console, Users page and click Create user.
2. Name it something you'll recognize later, for example trustyourinbox-dns.
3. Leave Provide user access to the AWS Management Console unchecked. This user only ever talks to the Route 53 API; it has no password and can't sign in to anything.
4. On the permissions step there's nothing to attach yet. Click through and create the user. (We'll add the policy directly to the user in the next step.)

Step 2: Attach the least-privilege policy

1. Open the user you just created and go to the Permissions tab.
2. Choose Add permissions, then Create inline policy.
3. Click the JSON tab and replace its contents with the policy below.
4. Save it, giving it a name like TrustYourInboxRoute53.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DiscoverZones",
      "Effect": "Allow",
      "Action": ["route53:ListHostedZones"],
      "Resource": "*"
    },
    {
      "Sid": "ReadWriteRecords",
      "Effect": "Allow",
      "Action": [
        "route53:ListResourceRecordSets",
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": "arn:aws:route53:::hostedzone/*"
    },
    {
      "Sid": "PollChangeStatus",
      "Effect": "Allow",
      "Action": ["route53:GetChange"],
      "Resource": "arn:aws:route53:::change/*"
    }
  ]
}

Reading it top to bottom: ListHostedZones lets us find which zone holds your domain, ListResourceRecordSets and ChangeResourceRecordSets let us read and write the records inside your zones, and GetChange lets us poll AWS until a change has propagated to Route 53's nameservers. That last one is how the read-back check works. There is deliberately no CreateHostedZone, no DeleteHostedZone, and nothing outside Route 53.

Step 3: Create the access key

1. On the user's Security credentials tab, click Create access key.
2. For the use case, choose Application running outside AWS. AWS will show a recommendation banner suggesting alternatives; acknowledge it and continue. (The alternatives it suggests are for code running inside AWS, which doesn't apply here.)
3. Copy both halves: the access key ID (starts with AKIA) and the secret access key. AWS shows the secret only once, on this screen. If you navigate away without copying it, just delete that key and create another.

Step 4: Paste it into trustyourinbox

In the dashboard, go to Settings, then Integrations, then AWS Route 53, paste the access key ID and secret access key, and click Connect. We immediately test the credentials against the Route 53 API and show you the list of hosted zones the key can see, so you know it works before you ever click a fix.

Two things you don't need to worry about: there is no region to pick (Route 53 is a global AWS service), and the key starts working within a few seconds of creation.

If your company uses IAM Identity Center (SSO)

Some AWS organizations sign in through IAM Identity Center and discourage or block long-lived access keys for human users. The setup here doesn't conflict with that: the key belongs to a dedicated service user with one narrow job, not to a person. If your organization's policy blocks creating IAM users entirely, ask your AWS admin to create this user in the account that owns the hosted zones. The whole setup is the three steps above and takes them about two minutes.

Troubleshooting the connect step

"This access key ID isn't recognized." The key ID was mistyped, the key was deleted, or it belongs to a different AWS account than you expect. Re-copy the ID, or mint a fresh key.

"The secret doesn't match." The secret access key was copied incompletely (it's long, and a trailing character is easy to drop). Create a new key and copy it with the copy button on the AWS screen rather than selecting the text.

"The key works but isn't allowed to list zones." The inline policy from Step 2 isn't attached to this user, or was edited. Re-check the user's Permissions tab against the JSON above.

"No public hosted zones." The key is valid but the account it belongs to has no public zones, only private ones (or none at all). DMARC and SPF live in public DNS, so connect a key from the account that actually hosts your domain's public zone. If you manage multiple AWS accounts, this is usually the sign you created the user in the wrong one.

Rotating or revoking later

If the key is ever compromised, or a fix fails because the key was deactivated, the integration page will flag the connection and ask you to reconnect. Rotation is the same flow again: create a new access key on the same IAM user, paste it in (the page has a "Replace these credentials" section), then deactivate the old key in AWS. Disconnecting in trustyourinbox deletes our encrypted copy but does not delete the key in AWS, so for a full teardown also delete the access key (or the whole IAM user) in the AWS console.