Your Emails Go to Spam Because of Three DNS Records You Never Set Up

As a fractional CTO working with startups in the B4i program, I've seen the same email delivery problem show up over and over. The app was fine. The email content was fine. The issue was usually three DNS records nobody had set up properly.

If you've ever deployed something that sends email and then discovered nobody was receiving it, these are the first records to check.

A Quick DNS Refresher (Skip If You Know This)

DNS records are how the internet maps names to things. You probably know A records (domain → IP address) and CNAME records (domain → another domain). Here's the rest of the cast, briefly:

AAAA: same as A, but IPv6. You need this if you want your site reachable over IPv6.

MX: tells the world where your email goes. The number is priority (lower = preferred). MX values must be hostnames, not IP addresses. This trips people up.

example.com.    MX    10 mail.example.com.
example.com.    MX    20 backup-mail.example.com.

TXT: arbitrary text. In practice it's used for SPF, DKIM, DMARC, and domain verification ("add this TXT record to prove you own the domain").

NS: points to your nameservers. You touch this when switching DNS providers and basically never otherwise.

You can check all of these at once with a DNS lookup tool instead of running multiple dig commands.

Now: Why Your Email Goes to Spam

Three records get you from "I send email" to "receiving servers can actually trust it." They're not the only thing that affects deliverability, but they're the baseline.

SPF: Who's Allowed to Send

SPF is a TXT record that declares which servers are allowed to send mail for your envelope sender domain.

v=spf1 include:_spf.google.com include:sendgrid.net -all

Translation: Google can send, SendGrid can send, everyone else should fail SPF (-all).

The gotchas:

DNS lookup limit. SPF allows max 10 DNS lookups. Each include: is one. Nested includes count too. If you use Google Workspace + SendGrid + Mailchimp + HubSpot, you're probably already over. An SPF checker makes this easy to validate.

~all vs -all. Tilde means soft fail, unauthorized emails are usually accepted but flagged. Dash means SPF returns fail. Many receivers will penalize or reject those messages, but the final decision is still theirs. Use -all unless you have a specific reason not to.

Forgetting a sender. You set up SPF for your marketing tool but not your transactional email service. Welcome emails fail SPF and start landing in spam.

Multiple SPF records. You can only have one. Adding a second one doesn't add senders, it breaks everything.

DKIM: Proving Emails Weren't Tampered With

DKIM is a cryptographic signature. Your email provider signs every outgoing email with a private key, and publishes the public key in DNS:

selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Receiving servers check the signature. If someone modified the email in transit (or forged it), the signature won't match.

Setup is straightforward: your email provider gives you a DNS record to add, you add it, done. But two things go wrong regularly:

Wrong selector. DKIM records are per-selector. Google uses google, SendGrid uses s1 and s2. If you're checking the wrong selector, it looks like DKIM is missing when it's fine.

Short keys. RSA keys should be 2048 bits minimum. Some old setups still use 512 or 1024. The shorter the key, the easier it is to forge signatures.

DMARC: What Happens When SPF/DKIM Don't Align

DMARC ties SPF and DKIM to the visible From: domain. It tells receiving servers what to do when neither SPF nor DKIM passes in alignment, and where to send reports about it.

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

The p= tag is the policy: none (just report), quarantine (usually send to spam), reject (ask receivers to reject it).

Don't start with p=reject. If your SPF or DKIM alignment is wrong, you can break your own mail. Roll out gradually:

1. Start with p=none and a rua= email address. Collect reports for a few weeks.
2. Read the reports. They show who's sending from your domain and whether they pass. You'll probably find senders you forgot about.
3. Move to p=quarantine with pct=25 (only quarantine 25% at first).
4. Ramp up to p=reject once you're confident nothing legitimate is failing.

A DMARC checker will show your current policy quickly.

The Fastest Way to Check a Domain

If you're debugging a real domain, this is the order I use:

1. Run a DNS Lookup to confirm the domain resolves and the expected MX/TXT records exist.
2. Run the SPF checker to catch multiple records, missing senders, or the 10-lookup limit.
3. Run the DKIM checker with the selector your provider gave you.
4. Run the DMARC checker to verify policy and reporting setup.

That usually gets you to the real problem faster than bouncing between provider dashboards and raw dig output.

Debugging DNS Problems (While We're Here)

Since you're already looking at DNS, a few common issues and what to check:

Site doesn't resolve. NS records might be pointing to the wrong provider. Or the domain expired. Check the basics first.

Changes not showing up. DNS caching. Every record has a TTL. If yours is 3600 (1 hour), changes can take up to an hour to show up in resolvers you don't control. Tip: lower the TTL to 300 before making changes, then raise it back after.

SSL certificate won't provision. Let's Encrypt uses a TXT record for DNS challenges. If it hasn't propagated yet, provisioning fails.

Reverse DNS fails. Some services (especially email servers) check PTR records. Given your IP, does it resolve back to your domain? This is set by your hosting provider, not your DNS provider.

tl;dr

Set up all three. If you want to validate them quickly, you can use lookup.echovalue.dev. Start DMARC in report-only mode, fix what fails, then enforce.