How does a DNS lookup work?

Every time a mailbox provider receives one of your emails, it runs a DNS lookup to verify you are who you say you are. That lookup is how it checks your SPF, DKIM, and DMARC records. Understanding what actually happens during that lookup helps you troubleshoot authentication failures faster.

Here's the sequence from start to finish.

Step 1: The query starts at a resolver. When Gmail's servers receive an email from captain@deepcurrent.io, they ask a DNS resolver (usually their own internal one, or a public resolver like 8.8.8.8) to look up the SPF record for deepcurrent.io. The resolver's first move is to check its local cache. If it saw that record recently and the TTL hasn't expired, it returns the cached answer immediately. That's why DNS lookups are usually milliseconds fast.

Step 2: If there's no cached answer, the resolver works up the hierarchy. It starts at the root nameservers (the top of the DNS tree), which point it toward the .io TLD nameservers. Those TLD servers say "deepcurrent.io is managed by these authoritative nameservers." The resolver then goes directly to those authoritative nameservers and asks for the actual record.

Step 3: The authoritative nameserver returns the record. This is where your SPF record, DKIM public key, or DMARC policy actually lives. The resolver gets the answer, caches it for the duration of the TTL, and passes it back to Gmail's servers. Gmail then uses that data to decide whether your email passes authentication.

The whole process typically takes under 100 milliseconds. But there are a few places it can go wrong for email senders.

• Too many SPF lookups. SPF allows a maximum of 10 DNS lookups per check. If your SPF record chains together too many "include:" statements, you'll hit that limit and fail authentication even with a valid record.
• Stale cache after a record change. If you update your DKIM record but the old TTL was set to 24 hours, receiving servers may keep checking the old key for up to a day. That can cause DKIM failures during the window between your update and when caches expire.
• Missing or misconfigured records. If the authoritative nameserver returns nothing (NXDOMAIN or empty response), DMARC will treat that as a fail. A misconfigured DNS record is one of the most common causes of sudden deliverability drops.

You can check what any resolver currently sees for your domain using our free SPF Checker. If you're trying to debug a DKIM failure, our DKIM Record Lookup shows exactly what the lookup returns. And if something is broken right now and you can't figure out why, the SOS hotline is free.