That Demo Was Impressive — Until You Checked the DNS
You just finished a demo with a potential vendor. Their pitch was polished, the product looked solid, the references were glowing. Then you ran a quick DNS lookup on their domain. No SPF record. No DMARC. A single MX pointing to a platform known for reliability but zero failover. It wasn't a dealbreaker by itself, but it told you everything you needed to know about what happens behind the scenes.
Your domain's DNS records are public. Anyone can inspect them in seconds. They show whether your team thinks about resilience, security, and operational maturity—or just ships features and hopes email works. The gap between a solid demo and a neglected DNS setup is the gap between a team that builds for scale and one that's patching things as they break.
DNS: The Public Engineering Resume You Didn't Know You Had
Most business leaders never look at their own DNS records. They assume the engineers set it up correctly years ago and that email just works. But DNS configurations drift. New services get added, old ones are abandoned, nobody updates the records. Over time, the setup becomes a silent record of every shortcut and forgotten cleanup task.
An SPF record that hasn't been touched since launch signals that nobody owns email deliverability. A missing DMARC policy means the team either doesn't know about email spoofing or hasn't prioritized it. A single MX record says the business is one server failure away from an email outage. These aren't minor glitches—they're fingerprints of how the engineering team operates.
What Your DNS Records Expose — and How to Fix It
SPF: Who Gets to Send Email as You
The Problem
The SPF record is missing entirely because nobody set it up. Or it includes only the primary email service but not the CRM, marketing tool, or ticketing system. Many companies add a new sending platform and forget to update SPF, so those emails silently get rejected or land in spam. More than one SPF record is a common mistake—it breaks the check entirely.
How to Fix It
Audit every service that sends email on behalf of your domain: transactional mail, sales outreach, support platform, survey tool. Build a single SPF record that include:s all legitimate senders and ends with -all or ~all. Avoid multiple SPF records; a domain with more than one invalidates the policy. Learn more about how SPF protects your reputation in our SPF guide.
DKIM: Proving Your Emails Haven't Been Tampered With
The Problem
DKIM keys were never generated, or the public key was published but the private key doesn't match. Emails can still deliver without DKIM, but they appear less trustworthy to receiving servers. A missing selector._domainkey record means there's no cryptographic proof that the message content is authentic, leaving your domain open to being flagged as suspicious.
How to Fix It
Generate a DKIM key pair for each sending service. Publish the public key in a TXT record at selector._domainkey.yourdomain.com, using the selector specified by your email provider. Verify the key matches by checking that the p= value is present and correct. Most major email platforms (Google Workspace, Microsoft 365, dedicated sending services) have straightforward instructions—the fix usually takes minutes once you know it's missing.
DMARC: What Happens When Someone Fakes Your Email Address
The Problem
No DMARC record at _dmarc.yourdomain.com means there's no policy telling receiving servers what to do when an email claims to be from your domain but fails SPF or DKIM. Anyone can impersonate your brand in phishing campaigns. Even with SPF and DKIM set, without DMARC there's no enforcement and no visibility into abuse. A blank DMARC is a security blind spot that most mature organizations closed years ago.
How to Fix It
Start with a policy of p=none to monitor traffic without blocking anything. Publish a DMARC record with rua= so you receive aggregate reports showing who is sending as your domain. After you're confident the legitimate senders pass, tighten to p=quarantine and eventually p=reject. This is the single most effective signal of security ownership an engineering team can put in DNS. Read our DMARC explainer for a deeper look.
MX: Where Your Incoming Email Goes When the Primary Goes Down
The Problem
A single MX record, like aspmx.l.google.com, means you're counting on one server—or one provider—to always be available. If that server has an outage or the provider faces an issue, incoming emails bounce. There's no backup. This is a reliability gap that costs real business communication, yet it's common in organizations that never tested failover.
How to Fix It
Add at least one secondary MX record with a higher priority number. If you use a cloud email provider, they often provide multiple MX hosts; ensure all are published. If you're self-hosting, arrange a secondary mail service to queue email during outages. The fix is a configuration change, not a platform migration. It's the engineering equivalent of having a spare tire—something your team either thought of or didn't.
DNSSEC: Verifying the Directions to Your Domain Aren't Spoofed
The Problem
Without DNSSEC, an attacker can poison a DNS cache and redirect visitors to a fake version of your site. A missing DS record at the registrar means there's no chain of trust verifying that DNS responses are authentic. This isn't theoretical—cache poisoning attacks happen, and a domain with DNSSEC turned off signals that security infrastructure wasn't a priority.
How to Fix It
Enable DNSSEC at your domain registrar and sign your zone. The registrar will provide the DS record to publish in the parent zone. Most modern registrars support DNSSEC with a single toggle and automatic key management. This shines a light on whether your team has explored defense-in-depth for the most fundamental internet service. Our DNSSEC article walks through the steps.
How to Audit Your Domain's Engineering Maturity
A full DNS health check doesn't take long. You can walk through the key signals in under an hour and find configuration gaps that have been accumulating for years.
Once the immediate fixes are in place, ongoing discipline prevents drift. These small habits separate teams that maintain trust from those that erode it over months.
For a deeper dive into each check, our DNS Health Checks guide covers the technical side in detail.
_dmarc.yourdomain.com starting with p=none and a reporting addressThe Bottom Line
You don't need a demo or a reference call to understand how an engineering team thinks about operations. Their DNS tells you in seconds. A clean, complete, well-maintained set of records means someone is minding the store. Gaps, contradictions, and missing policies mean things are slipping through the cracks—and they've probably been slipping for a while.
Your DNS is a public artifact of engineering culture. It's the resume you never submitted but every partner, vendor, and security-conscious customer can read. What does yours say about your team?
Run a free scan of your domain with TechSpy right now. It takes less than a minute, and it will show you exactly which records are missing, misconfigured, or silently failing. You might be surprised how much your DNS has been saying when you weren't listening.