Your premise, that for something to “be a word” in English, it must have an entry in one or another dictionary, is inherently faulty. For one thing, no dictionary ever contains all English words, not even the OED.
But for another, no dictionary ever contains all possible English words. For regular inflections, for example, like making a noun plural or a verb singular, or inflecting a verb by tense, you never see such things listed unless they are formed irregularly. That means that you don’t have a completely separate entry for flibbertigibbets or bamboozled, for example.
This same principle extends beyond inflectional morphology into derivational morphology. Like many languages, English has productive affixes. These are little bits that you can stick on one or another end of a word to create a brand new word.
Some of the very most productive affixes in English include
the prefixes non‑ and un‑ and the suffixes ‑able, ‑er, ‑ish, ‑less, ‑ly, and ‑ness.
For the most part, you can freely apply those to any word in the right target class
to create a brand new word. If and when this word should become popular, it may
be listed in some standard dictionary. But it is still a word even before that.
So if you cannot tell whether or not something is a word by say, looking in the OED, just think how much less you should trust any automated “spellchecker” to tell you whether you should use a word. It cannot possibly do that, although it may flag some terms for manual inspection. (It will also fail to flag many inappropriate words.)
In this case, unconfigured is a perfectly “real” English word, one that was produced by applying two different derivational affixes to an existing word. Whether its meaning is clear is open to some debate; for example, has it been de-configured, or has it never been configured at all?
But it is without question a valid English word, no matter what some idiot program “thinks” of it.
I don’t know whether something that has been de-configured should be treated the same way as something that has never been configured at all. It depends what each of those means in your application, and I can easily imagine scenarios where those would be completely identical. So in fact, we do not know enough to answer the question — which may even be unanswerable or off-topic.
However, if it were me doing the programming, I might consider changing the lingo to use two different configuration states: default and custom. That way if you unconfigure something with a custom configuration, you can return it to its default state, and if you change something from its default state, it flips into the customized configuration state.