DEV Community: Emiliano Saurin

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

Emiliano Saurin — Mon, 20 Apr 2026 13:31:55 +0000

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:

Start with p=none and a rua= email address. Collect reports for a few weeks.
Read the reports. They show who's sending from your domain and whether they pass. You'll probably find senders you forgot about.
Move to p=quarantine with pct=25 (only quarantine 25% at first).
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:

Run a DNS Lookup to confirm the domain resolves and the expected MX/TXT records exist.
Run the SPF checker to catch multiple records, missing senders, or the 10-lookup limit.
Run the DKIM checker with the selector your provider gave you.
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

Record	What it does	What breaks without it
SPF	Authorizes senders for the envelope domain	Mail can fail authentication or lose trust
DKIM	Signs outgoing mail with a verifiable key	Messages are easier to spoof or modify undetected
DMARC	Enforces alignment and reporting for the `From:` domain	Spoofing is harder to detect and control

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.

I Built a JSON Fixer Because I Was Tired of Counting Characters

Emiliano Saurin — Mon, 13 Apr 2026 21:05:00 +0000

JSON.parse() gives you an error at "position 42". Great. Position 42 of a 500-line config file. Let me just count characters manually, I guess.

I hit this so often that at some point I stopped counting and built a JSON Linter that shows errors with actual line numbers. But more on that in a second. First, let's talk about why JSON keeps breaking in the same ways.

It's Always the Same Five Things

Trailing commas. You delete the last field, forget the comma on the one above it. Or you copy from JavaScript, where trailing commas are fine. JSON disagrees.

{
  "name": "Alice",
  "age": 32,
}

Single quotes. A Python habit. Or a "I'll just type this real quick" habit. JSON wants double quotes, always.

Comments. JSON has no comments. None. This is honestly a spec failure. tsconfig.json and VS Code settings use JSONC precisely because people need comments in config files. But standard JSON? Nope.

{
  // this breaks everything
  "url": "https://api.example.com"
}

Unquoted keys. Valid JavaScript, invalid JSON. { name: "Alice" } fails.

Missing brackets. Usually from truncated logs or half-pasted API responses.

These five cover maybe 90% of all JSON parse errors I've ever seen.

So I Built a Fixer

The JSON Linter and Fixer does two things:

Paste broken JSON, hit "Fix" and it auto-repairs trailing commas, single quotes, comments, unquoted keys. It uses jsonrepair under the hood. It won't magically reconstruct corrupted data, but if the JSON is almost right (and it usually is), it'll clean it up.

Hit "Lint" and you get properly formatted output with syntax highlighting. Useful even when the JSON isn't broken, just minified into an unreadable blob.

{"users":[{"name":"Alice","age":32,"addresses":[{"city":"NYC","zip":"10001"}]},{"name":"Bob","age":25,"addresses":[{"city":"LA","zip":"90001"}]}]}

Nobody can read that. One click and it's formatted.

Everything runs client-side. No backend, nothing uploaded anywhere.

The Other Half: jq Without Installing Anything

Once the JSON is valid, you usually need to pull something out of it. "Give me all the user names." "Which items have status failed?" "Group these by category."

You could write a quick script. Or you could use jq, which does this kind of thing in one line. Except now you need to install jq, and you're on a machine where you can't, or you don't feel like it.

So the same site has a jq playground. Paste JSON, write a filter, see the result. Browser-only, same as the linter.

Some examples that come up all the time, given this data:

[
  { "name": "Alice", "age": 32, "role": "admin", "active": true },
  { "name": "Bob", "age": 25, "role": "user", "active": false },
  { "name": "Carol", "age": 28, "role": "admin", "active": true }
]

Pull all names:

map(.name)

Filter active admins over 30:

.[] | select(.role == "admin" and .age > 30)

Reshape into a different format:

map({ id: .name, isAdmin: (.role == "admin") })

Group by role and count:

group_by(.role) | map({ role: .[0].role, count: length })

That last one gives you [{"role": "admin", "count": 2}, {"role": "user", "count": 1}]. The kind of thing you'd normally open Python for.

Other one-liners I use constantly:

[.[] | .category] | unique           # unique values from an array
max_by(.price)                       # most expensive item
[.users[].addresses[].city] | unique # flatten and dedupe nested arrays

You get the idea. Try it with your own data.

The Workflow

I keep the linter bookmarked. API returns garbage, paste, fix, lint. Need to dig into the response, switch to the jq tab. It handles maybe 80% of my "what's in this JSON?" moments without opening a terminal.

The whole thing is open source on GitHub if you want to look at the code or contribute.

Part of echoValue. Free, no signups, no tracking.

InstaTrack: Track Your Instagram Followers & Following (Privacy-First, Open Source)

Emiliano Saurin — Mon, 06 Oct 2025 13:29:12 +0000

After getting frustrated with Instagram analytics apps that require account access or send data to their servers or are not free I built InstaTrack: a fully client-side tool to analyze followers/following.

What it does:

Upload Instagram JSON exports (followers/following)
See who doesn't follow you back and vice versa
Track trends over time with multiple snapshots

All processing happens in your browser (localStorage), zero server involvement
Try it: https://instatrack.njoylab.com
GitHub: https://github.com/njoylab/instatrack

I have few followers, so haven't tested performance with large datasets (10k+ followers). If anyone tries it with a big following, would love feedback on how it handles.

Open to any feedback on UX or features!

[iOS] Built an offline vault app - need honest UI/UX feedback

Emiliano Saurin — Fri, 15 Aug 2025 10:07:23 +0000

Hey folks,

I recently shipped “In My Pocket”

https://apps.apple.com/us/app/in-my-pocket-offline-vault/id6444294006

Main idea:

100% offline storage, no cloud, no accounts, just local data
Store key/value pairs like IBANs, loyalty cards, access codes, etc.
Core features are free, a $3 one-time IAP unlocks a few extras

Where I need help:
I deliberately went with stock iOS components for speed and familiarity, but the result feels very plain. I’m looking for constructive UI/UX suggestions to make it cleaner and more pleasant without adding bloat.

Next update: import/export between devices

Would love if you could check it out and tell me what you’d change. Brutal honesty welcome.