Google Workspaces Picking Up an MX record Not Set in Domain DNS

Question

I recently acquired a domain on GoDaddy auctions on behalf of a client for their new business's website. I am building the site and hosting it.

I am in the process of configuring Google Workspaces and just finished adding txt record verification and mx records. Important to note is that while Godaddy is the registrar, I'm not using their nameservers, I'm using Digital Ocean's.

When I go to validate the mx records, I notice that the *.aspmx.l.google.com are all still propagating. However, there's an odd record showing up that I have not set anywhere that Google says needs to be deleted.

1    @     mail.picklehost.com     86400

Never encountered this before, and never managed an auctioned off domain. Few questions:

• Do auctioned off domains commonly come with DNS baggage?

• If so, is that something you typically just chill and wait for?

• Why might Google Workspaces pick up an MX record that has not been set?

---

Below are some dns readouts from my research. the secureserver.net people initially said "you need to log into your dns and remove the record" but when I said "that's not the problem, I never set this record" they hung up on me.

NS Records :

[0] Name : mail.picklehost.com | value: ns1.totalpc.com. | ttl: 21600
[1] Name : mail.picklehost.com | value: ns2.totalpc.com. | ttl: 21600

------------------

Answer 1

Do auctioned off domains commonly come with DNS baggage?

If you acquire a domain from someone else it might have a working resolution already, so yet it might have DNS settings.

If so, is that something you typically just chill and wait for?

Once the domain is yours you are free to change the DNS settings (either/or the nameservers or their content aka the zone). As with any DNS changes, it may take some time to see the change, depending on how you test. Note that, contrary to popular belief, there is NO propagation, this is the wrong term to use.

Why might Google Workspaces pick up an MX record that has not been set?

You will have to ask the relevant provider on what it does or why it gets those results.

If you do a test on dnsviz.net (a very good online troubleshooting tool), it shows your domain as correctly configured, so this is well. See specifically: https://dnsviz.net/d/picklehost.com/Yc4RqA/dnssec/

If you query the authoritative nameservers for apex MX records you get:

$ dig @ns1.totalpc.com. picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.
$ dig @ns2.totalpc.com. picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.

so no taces of other MX hosts, and some major recursive servers have the correct data too:

$ dig @1.1.1.1 picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.
$ dig @8.8.8.8 picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.
$ dig @9.9.9.9 picklehost.com MX +noall +ans
picklehost.com.     4h IN MX 0 picklehost.com.

But if you queried right before doing the change, then your local recursive nameserver is having the old data in its cache, for 4 hours maybe or something else (what TTL the previous MX records had).

PS: for your kind of problem, the whois part is irrelevant for troubleshooting.

Answer 2

Do auctioned off domains commonly come with DNS baggage?

The worst case may be some caching (typically then 1 day) of old information. This will only affect a small number of users, and is not normally a significant issue once the nameservers have been updated. Its certainly not the issue you are experiencing here.

Why might Google Workspaces pick up an MX record that has not been set?

In this case your the MX record HAS been set. If we do a query on the authorative nameservers (ie ns1.totalpc.com/ns2.totalpc.com) it provides an MX record of 0 picklehost.com. This is not a caching issue - the domains are authoritatively answering incorrectly -

mypcname:~$ dig @ns1.totalpc.com picklehost.com mx

; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.totalpc.com picklehost.com mx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33544
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 797182d97c7174f35f87dc2f61ce2fa5ad7fcb755c02f359 (good)
;; QUESTION SECTION:
;picklehost.com.            IN  MX

;; ANSWER SECTION:
picklehost.com.     14400   IN  MX  0 picklehost.com.

;; AUTHORITY SECTION:
picklehost.com.     86400   IN  NS  ns1.totalpc.com.
picklehost.com.     86400   IN  NS  ns2.totalpc.com.

;; ADDITIONAL SECTION:
picklehost.com.     14400   IN  A   170.249.198.42
ns1.totalpc.com.    14400   IN  A   170.249.198.42
ns2.totalpc.com.    14400   IN  A   170.249.198.43

;; Query time: 196 msec
;; SERVER: 170.249.198.42#53(170.249.198.42)
;; WHEN: Fri Dec 31 11:16:05 NZDT 2021
;; MSG SIZE  rcvd: 179

This really is an issue with your DNS provider - likely their web interface is not correctly reflecting the underlying zone. This is something that has to be fixed in the nameservers. (If They won't fix it for you, find a new nameserver provider and update your DNS servers with your registrar to bypass the problem).

You say you are using Digital Oceans nameservers - but I think this is incorrect. Your registrar/whois information and DNS all say totalpc.com are providing your DNS. This is likely your problem - maybe your registrar has not updated the nameservers?