Don't add the trailing dot to the RR name. Use it like this:
server my.dns.server
zone example.com
key example.com some-key-data
update delete example.com 604800 A
update add example.com 604800 A 192.0.2.1
send
I just tested it with A and MX record; it worked for me, the server is PowerDNS, the client is ISC nsupdate from bind-tools, authentication was via TSIG, the key name equals the zone name for simplicity.
I've got an impression you don't fully understand how $ORIGIN and @ work, so here is a little explanation. For the complete explanation see RFC1035.
On the wire these never appear. It's just a convience "syntax sugar" shortening your typing and reading of zone files. The following three examples define identical zones (I am lazy to complete SOA records, their exact values don't matter for our subject):
$ORIGIN example.com.
@ 604800 IN SOA ns1 ....
604800 IN NS ns1
ns1 3600 IN A 192.0.2.1
@ 3600 IN A 192.0.2.5
$ORIGIN .
example.com 604800 IN SOA ns1.example.com ....
$ORIGIN com.
example 604800 IN NS ns1.example
$ORIGIN ns1.example.com.
@ 3600 IN A 192.0.2.1
example.com. 3600 IN A 192.0.2.5
example.com. 604800 IN SOA ns1.example.com. ....
example.com. 604800 IN NS ns1.example.com.
ns1.example.com. 3600 IN A 192.0.2.1
example.com. 3600 IN A 192.0.2.5
In the first example I didn't specify any RR name in the third line (NS RR after SOA RR), so parser will take it from the previous line. This behaviour is the precise reason for @ syntax existence: you can't leave the RR name field empty, as it will take the previous record name. If I skipped the @ at the last record, I'd define a second A record for ns1. So to define a record with the name equals to currently set origin (it'll be "apex" if the origin set to zone name) you can't use "empty name", because it will invoke this "take previous" behaviour. You either have to spell the full record name explicitly with the trailing dot so it won't append an origin (like it is written in other examples), change the origin, or use a special symbol @ which tells the parser: "don't repeat the previous name, here comes the origin naked", so the last line in the first example defines example.com..
The second example is just fancy demonstration how $ORIGIN and @ work together.
The third example doesn't use any sugar. This is real absolute data the zone holds in each of those three examples.
So, your record could be represented in the zone file as example.com after $ORIGIN ., or example.com. anywhere, or @ after $ORIGIN example.com., or even example after $ORIGIN com., it doesn't matter. These cases are all equal. Probably you are expecting to see "@" variant, but BIND may decide to spell it as any of those variants, so be prepared to recognize them all. And you can't force it to use any particular variant, sorry.
Another caveat could be you reading the zone file after update without first freezing it. Notice the "jnl" file next to the zone file; it is the journal where your updated data first stored. Only when you do the rndc freeze example.com the data is written into the zone file (but the zone is then locked for updates, to unlock you need to do the thaw operation or reload the server). The proper way to check if zone is updated or not is to do the actual DNS query, with dig or host or nslookup, whichever you like:
host -v example.com
