You can use @ if you format it as pre-formatted text, e.g. by picking </> from the editor menu (it's tricky to access this when on a smartphone, though).
I have re-introduced the @-sign in your above dig commands.
Your output is somewhat inconclusive, suggesting at most partial ECS support of your DC DNS servers.
The first dig command tests if your DC DNS servers would accept subnet information when a client sends it.
This doesn't seem to be the case:
instead should have returned:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; CLIENT-SUBNET: 1.2.3.0/24/0
;; QUESTION SECTION:
The second dig command is meant to test if your DC DNS servers would inject ECS information when forwarding DNS requests.
The first TXT field contains the IP address of the resolver that has sent the query to Google's DNS.
In your case, that is `172.253.206.37`, which seems to be a Google resolver from Google's Warsaw data center.
This can be glimpsed from:
curl --silent https://www.gstatic.com/ipranges/publicdns.json | grep 172.253.206 -A2
which currently returns:
"ipv4Prefix": "172.253.206.32/24",
"service": "Google Public DNS",
"scope": "waw"
That much is expected.
The second TXT field contains the ECS subnet information as received by that resolver, which in turn would have forwarded that information as received by your DC DNS server (provided you did use one of Google's DNS server IPs 8.8.8.8 as your DC's upstream).
It should instead also have produced a warning similar to:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
(...) Provided ECS includes 32 bits, but no more than 24 are allowed. (...)
; CLIENT-SUBNET: 172.27.17.123/32/0
Since that is missing, that could suggest that either your DC DNS server is not sending any ECS information at all, or it is sending a /24 subnet mask.
To see individual client IPs in Pi-hole, the IP address should not be masked, i.e. your DC DNS servers should use a /32 netmask for requests it forwards to your Pi-hole.
You'd have to configure your DC DNS servers to include that information.
Once you've verified you succeeded, you should then configure Pi-hole to remove ECS information before it forwards DNS requests to upstream public DNS resolvers.
(That could be done via a custom configuration file. I can provide additional advice if your DC DNS servers have been correctly configured for EDNS(0) ECS.)
Alternatively, it may be easier to just apply my earliest advice and rearrange your DNS resolution chain to put Pi-hole before your DC DNS. 