qm doctor rejects a working Resend key and tells you to get one you already have

[shekharkadyan]

What happens

You create a Resend API key for sending sign-in emails. Sensibly, you choose a
sending-only key rather than one with full account access.

qm doctor rejects it:

Resend rejected RESEND_API_KEY — mint a key with send access at
https://resend.com/api-keys

But it is a key with send access. That's exactly what you made.

Why

The check doesn't test sending. It asks Resend to list your domains:

GET https://api.resend.com/domains

A sending-only key can't read that, by design, so Resend answers:

{ "statusCode": 401, "message": "This API key is restricted to only send emails",
  "name": "restricted_api_key" }

qm doctor sees a 401 and concludes the key is bad. The same key sends
perfectly well — verified by actually sending with it:

POST https://api.resend.com/emails  ->  HTTP 200

Why this matters

It blocks qm doctor, and therefore qm up. And the advice it gives — go get a
key with more access — pushes people to replace a correctly-scoped key with a
broader one, purely to satisfy a check. That's a security downgrade caused by a
test looking at the wrong thing.

What would fix it

Treat "name": "restricted_api_key" as a pass. It's positive proof: the key
is valid and correctly scoped to sending, which is all the deployment needs.

You could optionally note that domain verification can't be confirmed with such
a key. If a stronger check is wanted, testing the send endpoint would verify the
capability actually being relied on.