IndexNow key not accepted: when the file is read but rejected
The engine fetched your IndexNow key file, got an answer, and still refused the key. Unlike a file that cannot be read at all, here the request reached a file and what it found did not agree with the submission. The causes are few, each is checkable, and none involves the announced page.
Read but not accepted is not the same as not found
When the key file cannot be read, the request was redirected, answered with a page, or blocked before it reached the file; those cases are set out under key not found. This page starts where that one stops: the file comes back as plain text at the expected address, with no redirection, and the submission is refused anyway.
An endpoint reports a key it could not validate, including a file that does not contain the key, with a 403, and a key outside the protocol's format with a 422; what each code means is set out under response codes. Either way, the refusal is about the agreement between three things: the key in the submission, the name of the file, and what the file contains.
The key and the file name have to agree exactly
The file is served at /<key>.txt, so its name is the key. A key and a file name that differ by one character are two different keys as far as the engine is concerned. Typing either by hand is where the disagreement usually starts; generating the key and the file together removes it.
The file has to contain the key
The file's name says where to look; its contents are what the engine compares. The file has to contain the key itself, the same value that the submission names. A file that sits at the right address but holds something else, such as an older key left over from a previous setup, is read successfully and still refused.
The key itself has to be well formed
The protocol's documentation sets the format: a key of 8 to 128 characters, made of letters, digits and dashes, in UTF-8. A key outside that format is not a valid key, whatever the file contains, and an endpoint can answer it with a 422. If the key was produced by your own tooling rather than generated with the file, check its length and characters against that rule.
The submission and the file have to name the same key
A submission names one key, and the file on that hostname has to hold the same one. The most common way for the two to drift apart is a key change made in the wrong order. The safe order is to serve the new file before submitting with the new key, and to keep the old file in place until nothing uses it; doing it the other way round produces a window in which submissions name a key the hostname does not yet serve. The reasoning is set out under the IndexNow key file.
Each hostname is checked on its own
The key binds to the host that serves it. A key file present on one hostname says nothing about another, so a submission for a second hostname is checked against a file served from that second hostname. A working first hostname is reassuring and proves nothing about the others, so check the file on every hostname you submit for, not just the first one that comes to mind. When the submission names a location other than the root, that location has to be on the same host as the addresses submitted.
What a refused key does not mean
A refused key is about the key, not the page. It says nothing about the address you announced, about its content, or about how an engine treats your site. The submission was refused before any of that came into play, so there is nothing to read into it beyond the disagreement between the key, the file name and the file's contents.
Once those three agree, the next submissions are checked against the corrected file like any other. The submission log records each refusal with its code, so the point at which refusals stop and acceptances begin is visible in the same record, without having to wait for anything to appear in results.
How to check all of them at once
Fetch the key file the way the engine does, from outside your network, and read what comes back next to the submission that was refused. Three questions settle it: does the file name match the key in the submission character for character, does the file contain that same key, and is the key 8 to 128 letters, digits and dashes. Checking the key file sets out the request to make.
When the layer that serves your traffic also serves the key file, the key, the file name and the contents come from one place and cannot disagree, which is what submitting from the edge describes.
FAQ
The key file loads fine. Why is the key still rejected?
Because loading is only half of the check. The engine also compares what the file contains with the key in the submission, and the file name with the key. If any of the three disagree, the file is read and the key refused, with a 403.
I changed my key and submissions started failing. Why?
Usually because the order was reversed: submissions began naming the new key before the hostname served the new file. Serve the new file first, switch the submissions after, and keep the old file until nothing still uses it, so there is no window in which the two disagree.