The five parts, always in that order
Every DNS record, whatever its type, is an owner name, a time-to-live, a class, a type and some data. Three of those are frequently omitted in a zone file and inherited from context, which is why lines that look different are structurally identical. The decoder identifies each token by what it is rather than by where it sits, which is the same thing a nameserver does when it reads the file.
The DNS record types page covers each type in full, with the mistake it invites. This tool is the fast version: paste the line, see the parts, read the warning if there is one.
What the warnings catch
Three faults account for most broken records and all three are visible in a single line. A missing trailing dot on a target name, which makes it relative and silently appends the zone origin. A TTL long enough that a planned change will be served from cache for days after it is made. And a CNAME at the zone apex, which cannot be valid because the apex necessarily holds SOA and NS records and a CNAME may not coexist with anything.
A fourth is worth knowing and is not visible from one line: a TXT string over 255 characters must be split into several quoted strings that are concatenated on reading, and a key split at the wrong point is syntactically fine and functionally dead. The decoder reports the length so the problem is at least noticeable.
Reading the TTL as a plan rather than a number
The time-to-live is the field most often set once and never thought about again, and it is the one that decides how a change behaves. A resolver that has cached an answer is entitled to keep serving it until the TTL expires, and nothing can make it forget sooner. A record with a TTL of 86400 will therefore be served from caches for about a day after it is changed, on some networks and not others, which is what makes a migration look half-finished.
The sequence that avoids it is three steps and has to be done in order. Lower the TTL to a few minutes. Wait for the old TTL to expire, which is the step people skip. Then make the change, confirm it, and raise the TTL again. Skipping the waiting period means the old long TTL is still cached at the moment of the change, so the low value that was supposed to make the migration fast has not reached anybody yet.
There is a second cache worth knowing about, in the SOA record. Its last timer governs how long a negative answer is remembered, so a name that previously did not exist can keep answering as though it does not for a while after it starts existing. That is the mechanism behind a newly delegated domain resolving for some people and not others, and it is covered on nameservers and delegation.
What it cannot tell you
Whether the record is actually published. This is a parser, not a resolver, and it makes no network request at all. A well-formed line that is not in the zone, or is in the zone but contradicted by the parent delegation, will decode perfectly. For that class of problem the relevant reading is nameservers and delegation, where the parent copy of the NS records is the one that decides.