DEV Community: Regő Botond Ronyecz

DNSSEC: The Developer's Setup Guide (2026)

Regő Botond Ronyecz — Sat, 09 May 2026 12:20:57 +0000

DNSSEC has a reputation for being complicated. That reputation is mostly deserved, but the actual setup on modern DNS providers takes about ten minutes. The hard part is understanding what it does and why, so you don't misconfigure it and silently break your domain for a subset of users.

This is that guide.

What DNSSEC actually does

DNS responses have no built-in authentication. When a resolver asks your nameserver "what's the IP for yourapp.com," there's nothing in the original protocol that proves the answer came from you and wasn't modified in transit. Cache poisoning attacks (Kaminsky, 2008) exploited exactly this.

DNSSEC adds cryptographic signatures to your DNS records. Each record set gets signed with a private key. Resolvers that support DNSSEC validation can verify those signatures against a public key published in your zone. If the answer was tampered with, validation fails and the resolver returns an error instead of a forged response.

It does not encrypt DNS traffic. Someone watching the network can still see what domains you're querying. That's what DNS over HTTPS (DoH) and DNS over TLS (DoT) are for, which is a separate topic. DNSSEC is about integrity, not confidentiality.

The key concepts you need before touching anything

Zone Signing Key (ZSK) signs your actual DNS records (A, MX, CNAME, etc.). It rotates frequently, typically every 30-90 days depending on your provider.

Key Signing Key (KSK) signs the ZSK. It rotates less often and is the one that gets published up the chain to your parent zone (your TLD's nameservers).

DS record is a hash of your KSK that lives in the parent zone. This is the link in the chain of trust. When you enable DNSSEC, your registrar takes your DS record and publishes it in the TLD zone. Resolvers walk up this chain to verify your signatures.

NSEC/NSEC3 records prove that a name doesn't exist. Without them, an attacker could return NXDOMAIN for a name that actually exists and you'd have no way to verify they're lying. NSEC3 hashes the names so you're not exposing your full zone contents in the process.

If this sounds like a lot, managed DNSSEC on most providers handles all of it for you. You enable it, copy a DS record to your registrar, and the provider rotates keys automatically.

Setup by provider

Cloudflare

Cloudflare's DNSSEC is one click. Go to DNS > Settings > DNSSEC and enable it. Cloudflare gives you a DS record to add at your registrar. That's it. Key rotation is automatic and you never have to think about it again.

The one thing to check: if you're using Cloudflare as a proxy (orange cloud), DNSSEC only covers the DNS layer. The traffic between Cloudflare and your origin is a separate concern.

AWS Route 53

Route 53 added managed DNSSEC in 2020. In the console, go to your hosted zone, select DNSSEC signing, and enable it. AWS creates a KSK backed by a KMS key in your account, which you can see and control.

After enabling, Route 53 shows you the DS record. You add that record at your domain registrar. If your registrar is Route 53 as well, there's a button to do it automatically.

One Route 53 gotcha: the KMS key has to be in us-east-1. If your infrastructure is in another region, the key still needs to live there. This surprises people.

Google Cloud DNS

Go to your Cloud DNS zone, click DNSSEC, enable it. Google manages key rotation automatically. You get a DS record to copy to your registrar. Same pattern as the others.

Self-hosted BIND or NSD

This is where it gets manual. You need to generate your ZSK and KSK with dnssec-keygen, sign your zone with dnssec-signzone, and set up automated re-signing before signatures expire. If you're running your own nameservers and haven't done this before, the official BIND documentation is the right starting point. The managed provider path is meaningfully easier.

The DS record and your registrar

This step is where most DNSSEC setups fail. Enabling signing on your DNS provider is only half the job. The DS record has to be published in the parent zone (the TLD), and that happens through your registrar.

Every registrar has a different UI for this. You're looking for something called "DNSSEC," "DS records," or "domain security." You'll paste in four fields: key tag, algorithm, digest type, and digest. These come directly from your DNS provider after you enable signing.

If you change DNS providers later, you have to update the DS record at your registrar before you disable DNSSEC on the old provider. The failure mode is ugly: resolvers that validate DNSSEC will return SERVFAIL for your domain, which looks like your site is down to roughly 30% of users (the ones whose resolvers validate). The other 70% will see nothing wrong. This makes it hard to diagnose.

Checking your setup

After enabling DNSSEC and adding the DS record, give it 15-30 minutes to propagate, then verify:

# Check if your zone is signed
dig DNSKEY yourapp.com +short

# Check if the DS record is in the parent zone
dig DS yourapp.com @8.8.8.8 +short

# Full validation check
dig yourapp.com +dnssec +short

For a more readable output, dnsviz.net generates a visual graph of your DNSSEC chain of trust. It's the clearest way to see if something is broken.

DANE Validator is useful if you're also doing TLSA records for email.

What breaks when you get it wrong

Signature expiry. DNSSEC signatures have an expiration date. If your provider doesn't auto-rotate and you forget to re-sign, signatures expire and validating resolvers start returning SERVFAIL. This has taken down larger domains than you'd expect. With a managed provider, this is their problem. On self-hosted DNS, put re-signing on a cron job with monitoring.

DS/DNSKEY mismatch. If you publish a DS record at your registrar that doesn't match the KSK on your nameserver, validation fails for everyone. This usually happens during a provider migration where someone enabled DNSSEC on the new provider before updating the DS record.

Removing DNSSEC incorrectly. If you want to disable DNSSEC: remove the DS record at your registrar first, wait for TTL to expire, then disable signing on your provider. Doing it in the wrong order is the same failure mode as the migration problem above.

Monitoring after setup

DNSSEC is one of those things that works silently when it's right and breaks loudly when it's wrong. The breakage is often partial, which makes it worse to debug. Automated monitoring that continuously checks your DNSSEC chain and alerts you if signatures are about to expire or if the DS record stops matching is worth having.

ZeroHook monitors DNS record changes and flags anomalies, including DNSSEC issues, without you having to remember to check manually: zerohook.org.

TL;DR

DNSSEC signs your DNS records so resolvers can verify the answers haven't been tampered with. On managed providers (Cloudflare, Route 53, Google Cloud DNS), setup is: enable signing, copy DS record to registrar, done. The common failure modes are forgetting the DS record step, and misconfiguring during provider migrations.

If you're on a managed provider and haven't enabled it yet, you can do it right now. It takes ten minutes and you're protected against a whole class of attacks that otherwise have no defense at the DNS layer.

Part of an ongoing series on DNS security. Previous posts: DNS hijacking · Certificate Transparency logs · Subdomain takeover and dangling DNS

DNS hijacking: when someone else answers in your domain's name

Regő Botond Ronyecz — Sat, 09 May 2026 03:39:20 +0000

Your users type your domain into their browser. They get a login page that looks exactly like yours. They enter their credentials. You never see any of it.

That's DNS hijacking. No one broke into your servers. No one touched your code. They just changed where your domain points.

How DNS actually works (the part that matters)

When someone visits yourapp.com, their browser asks a DNS resolver: "what IP address is this?" The resolver checks its cache, and if it doesn't have an answer, it walks up the DNS hierarchy until it finds one. Your authoritative nameserver, the one you control through your registrar, gives the final answer.

The whole process takes milliseconds and happens invisibly. It's also built on a foundation of trust. DNS was designed in 1983, when the internet was a handful of universities sharing files. Authentication was an afterthought added decades later, and most of the internet still doesn't use it.

That gap is where hijacking lives.

The three ways it actually happens

Registrar account compromise

This is the most common and the most damaging. Your domain registrar account gets compromised, and the attacker changes your nameservers to ones they control. Every DNS query for your domain now goes to their server. They answer however they want.

From the outside, nothing looks wrong. The domain name is yours. The WHOIS still shows your company. Users have no way of knowing they're talking to the wrong server.

The 2019 Sea Turtle campaign, attributed to a nation-state actor, used exactly this method to target government and military domains across the Middle East and North Africa. They didn't attack the targets directly. They compromised registrars and DNS providers upstream, then redirected traffic to collect credentials. Some victims went months without noticing.

DNS cache poisoning

Resolvers cache DNS responses to avoid asking the same question twice. Cache poisoning tricks a resolver into storing a fake answer, so every user who asks that resolver for your domain gets sent to the wrong IP.

The classic attack exploits the fact that DNS uses UDP, which has no built-in verification. An attacker who can guess the query ID (a 16-bit number, so 65,536 possibilities) can inject a fake response before the real one arrives. Kaminsky's 2008 disclosure showed this was practical at scale. The patch was randomizing the source port on top of the query ID, which raised the guessing space to around 2 billion. Better, but not foolproof.

BGP hijacking with DNS as a side effect

Border Gateway Protocol is how internet routers know which paths to use. It's also almost entirely based on trust between autonomous systems. When a network announces that it owns an IP range it doesn't, traffic for those IPs can get rerouted through the attacker's infrastructure.

In 2018, attackers briefly hijacked the BGP routes for Amazon's Route 53 DNS service. They redirected DNS queries for MyEtherWallet to a server they controlled, which served a fake version of the site and collected around $150,000 in cryptocurrency in two hours. The DNS records themselves were never touched.

What attackers do with it

Credential harvesting is the obvious one. Serve a convincing copy of your login page, collect usernames and passwords, pass the credentials through to the real site so users don't notice anything is off.

But it goes further than that. If your domain is used for email (MX records), an attacker who controls your DNS controls where your email goes. Password reset links, internal notifications, customer data, all of it can be redirected.

HTTPS doesn't save you here. An attacker who controls your DNS can request a valid TLS certificate for your domain from any CA using HTTP-01 or DNS-01 validation. The padlock in the browser will be green. The certificate will show your domain name. It will be completely legitimate from the browser's perspective.

Signs something is wrong

Most teams find out from users. "Your site looks weird" or "my password stopped working" are common first signals, by which point the damage is done.

What to actually watch:

Your NS records should never change unless you're deliberately migrating DNS providers. Set up monitoring for them. If your authoritative nameservers change without a ticket in your system, something is wrong.

TTL spikes are suspicious. Attackers sometimes lower TTLs before a hijacking to make the switch propagate faster and to make rollback harder. A sudden drop in TTL across your zone is worth investigating.

Response time changes. If your DNS responses start coming from unexpected geographic locations or taking longer than usual, a resolver somewhere is getting wrong answers.

Certificate transparency logs, which we covered in the previous post on CT logs, will show you if a certificate was issued for your domain from an unexpected CA. This is often one of the first visible signs of an active hijack.

Tools like ZeroHook monitor your DNS records continuously and alert you when something changes, NS records, A records, MX records, anything. The window between a hijack starting and you noticing it manually is often days. Automated monitoring closes that window considerably. Worth setting up: zerohook.org.

How to actually protect yourself

Lock your domain at the registrar. Most registrars offer a "registrar lock" or "transfer lock" that prevents nameserver changes without an additional out-of-band confirmation. Enable it. Some registrars also offer registry lock, which requires a phone call or signed document to make changes. For critical domains, that friction is worth it.

Enable DNSSEC on your zone. DNSSEC adds cryptographic signatures to DNS records, so resolvers can verify that the answer they received came from your authoritative server and wasn't tampered with in transit. Adoption is still patchy, but it defends against cache poisoning and some man-in-the-middle attacks.

Harden your registrar account. Use a strong unique password, enable MFA, and restrict access to the minimum number of people who actually need it. The Sea Turtle campaign worked because registrar accounts are often treated as low-value administrative accounts rather than the critical infrastructure they are.

Use CAA records to restrict which certificate authorities can issue certs for your domain. If your CAA record says only Let's Encrypt can issue for yourapp.com, a hijacker using a different CA will get rejected. It's not foolproof but it raises the bar.

Monitor, not just your servers but your DNS. Uptime monitoring tells you when your site is down. It doesn't tell you that your site is up but serving someone else's content.

TL;DR

DNS hijacking doesn't require access to your servers or your code. It requires access to wherever your domain's DNS records live, which is usually a registrar account protected by a password and maybe SMS two-factor.

The attack is invisible to users. HTTPS doesn't stop it. You can lose credentials, email, and customer trust before anyone on your team notices.

Lock your domain. Enable DNSSEC. Watch your NS records. Set up monitoring that tells you when your DNS changes, not just when your site goes down.

Certificate Transparency Logs: How Attackers Map Your Infrastructure Before You Know They're Looking

Regő Botond Ronyecz — Sat, 09 May 2026 03:28:01 +0000

You deleted the staging server. You closed the Jira ticket. You told your team the migration is done.

But somewhere out there, a publicly searchable database has been quietly logging every TLS certificate your company has ever issued, including the one for internal-api.yourapp.com you spun up two years ago and forgot about.

That database is open to anyone with a browser. Attackers use it every single day.

What is Certificate Transparency and why does it exist?

Certificate Transparency (CT) is a public, append-only logging system for TLS certificates. It was designed with good intentions: in 2013, Google introduced it after a CA (DigiCert Malaysia) was caught issuing unauthorized certificates for Google's own domains. The idea was to make every certificate publicly auditable so rogue certs could be detected quickly.

Today, all major browsers require that certificates be submitted to at least two public CT logs before they're considered trusted. That means every certificate issued for your domains, past or present, is recorded in a permanent, searchable, publicly accessible ledger.

The logs are operated by Google, Cloudflare, DigiSign, and others. You can query them directly at crt.sh, or tap into the real-time stream with tools like Certstream.

This is great for defenders. It's also a goldmine for attackers.

The recon phase nobody talks about

Before any actual attack happens, there's reconnaissance. Certificate transparency logs have become one of the most reliable recon techniques out there, because they're passive, legal, and the data is just sitting there.

Step 1: Enumerate every subdomain you've ever had

curl "https://crt.sh/?q=%.yourapp.com&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u

This one command returns a complete historical list of every subdomain you've ever issued a certificate for. Not just what's live today, everything, ever.

That includes:

staging.yourapp.com (the one you decommissioned last spring)
internal-dashboard.yourapp.com (set up for a contractor who left)
beta-v2.yourapp.com (the failed product launch from 2021)
jenkins.yourapp.com (please tell me you took this offline)

The attacker didn't scan your network. They didn't need to. You published this list yourself every time you provisioned a certificate.

Step 2: Check which ones are still alive

Once they have the list, it's trivial to check which subdomains still resolve, and more importantly, which ones resolve to something they can claim.

cat subdomains.txt | dnsx -silent -a -resp

Tools like dnsx, massdns, and shuffledns can resolve thousands of subdomains in seconds. The attacker is looking for a specific pattern: a CNAME that still exists in your DNS, pointing at a service that no longer has your app registered on it.

Step 3: Find dangling records and take them over

If staging.yourapp.com has a CNAME pointing to yourapp-staging.herokuapp.com, and that Heroku app was deleted six months ago, it's available to claim. Anyone can register a new Heroku app at that address. The attacker now controls a subdomain under your brand, with a valid HTTPS certificate and no browser warnings.

This isn't theoretical. It has happened to Uber, Microsoft, and hundreds of smaller companies. The EdOverflow/can-i-take-over-xyz repository tracks dozens of platforms, Heroku, Netlify, GitHub Pages, S3, Fastly, Shopify, Azure, that are all exploitable in exactly this way.

What they do once they're in

A subdomain takeover under your domain isn't just an embarrassment. Consider what the attacker actually has.

A login page at staging.yourapp.com looks completely legitimate. The SSL padlock is valid. The URL is your brand. Security-aware users who check the URL before entering credentials will see nothing wrong.

If your session cookies are set on .yourapp.com, they're readable by any subdomain, including the one the attacker just claimed. Depending on your cookie configuration, this can mean direct session hijacking without ever touching your main application.

And if your CSP includes *.yourapp.com as a trusted source (which is common), scripts served from the attacker's subdomain are treated as trusted by your main application. Arbitrary JavaScript, injected from a domain that looks like yours, passing all your security checks.

Your browser has no way of knowing the subdomain changed hands.

The CertStream problem: real-time exposure

CT logs aren't just queryable in retrospect. They're also streamable in real time.

CertStream exposes a WebSocket feed of every certificate being issued right now, across all major CT logs. Attackers use it to monitor for newly issued certificates matching patterns they care about: your company name, your product, your domain.

The moment your developer issues a cert for new-feature.yourapp.com, it appears in that stream. Before the feature is deployed, before any internal announcement, an attacker watching CertStream already knows it exists.

This matters especially for acquisitions. When you start setting up infrastructure for a company you're acquiring, the subdomain pattern is often a dead giveaway. Competitors and researchers monitor these logs. Developers who issue certs for internal services and assume nobody will find them are usually wrong.

Wildcards don't help as much as you think

A common response to subdomain enumeration concerns is switching to wildcard certificates (*.yourapp.com). If you're not issuing individual certs for each subdomain, they won't appear in CT logs.

This is partially true. But most organizations issue a mix of wildcard and specific certs. Historical certs from before any wildcard migration are still in the logs forever.

More importantly, CT logs reveal what subdomains you've certificated, not what's actually exposed. Your DNS zone file is the real source of truth. Wildcard certs don't clean up dangling CNAME records.

There's also the question of blast radius. A single compromised wildcard key signs everything under your domain. The cert covering *.yourapp.com is a high-value target.

How to audit your exposure

Pull your full historical subdomain list:

curl "https://crt.sh/?q=%.yourdomain.com&output=json" \
  | jq -r '.[].name_value' \
  | sed 's/\*\.//g' \
  | sort -u > subdomains.txt

Resolve which ones are still live:

cat subdomains.txt | dnsx -silent -a -resp -o live_subdomains.txt

Check CNAMEs for dangling records:

cat subdomains.txt | while read sub; do
  cname=$(dig CNAME +short $sub)
  if [ -n "$cname" ]; then
    echo "$sub -> $cname"
    curl -s -o /dev/null -w "%{http_code}" "https://$cname" | grep -q "404\|no such app\|doesn't exist" && echo "  ⚠ POTENTIALLY DANGLING"
  fi
done

Run subjack for automated takeover checks:

subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt -ssl

For most teams, this is a one-time audit that surfaces something uncomfortable. For ongoing monitoring, ZeroHook automates the whole thing: it watches your DNS records, flags dangling CNAMEs, and alerts you before someone else finds them. Worth bookmarking: zerohook.org.

What to actually fix

Delete the DNS record before you tear down any service. Same day. Not "we'll clean it up next sprint," because that sprint doesn't come.

Export your zone file and go through it line by line. If you can't explain what a record is for, it probably shouldn't be there.

Get CT log monitoring in place. CertStream or anything that wraps it will tell you when a certificate is issued for your domains. You want to know before someone else does.

Check your cookie scope. Session cookies set on .yourapp.com are readable by any subdomain. Tighten this if you can.

Review your CSP. Wildcard allowances like *.yourapp.com are common and dangerous. Enumerate sources explicitly where possible.

DNS cleanup belongs on your decommissioning checklist, next to revoking API keys and removing IAM roles. It's the same category of problem.

TL;DR

Every certificate you've ever issued is in a public, searchable, permanent log. Attackers use that log to find subdomains you forgot about, check which ones are still live, and claim the ones pointing at services you've already shut down.

The recon is free. The takeover is five minutes of work. The damage, phishing campaigns on your domain, session hijacking, CSP bypass, is harder to explain to your users.

Run the commands above. It takes 20 minutes and you'll almost certainly find something.

Subdomain Takeover Explained (and How to Fix It)

Regő Botond Ronyecz — Thu, 23 Apr 2026 20:31:20 +0000

You shut down a product. You deleted the Heroku app, tore down the S3 bucket, and removed the Netlify site. But you probably forgot the DNS record pointing to it.

That subdomain is now up for grabs.

The problem with dangling DNS records

When you create staging.yourapp.com and point it to Heroku, you add a CNAME record mapping your subdomain to yourapp.herokuapp.com. When you shut down the app, that CNAME stays behind. Heroku lets anyone register a new app at that same .herokuapp.com address. If an attacker grabs it, they now control everything that loads on staging.yourapp.com. It runs under your domain, with your SSL cert, and with your brand name sitting right there in the address bar.

You probably didn't notice because you were busy shipping the next thing.

Why this is actually dangerous

This isn't a theoretical edge case. It's happened to Uber, Microsoft, and it keeps happening to smaller startups that never bother to audit their DNS. Once someone controls a subdomain, the rest is easy:

Phishing: A login page at staging.yourapp.com looks completely legitimate. There are no browser warnings and the HTTPS is valid.
Cookie theft: Session cookies scoped to .yourapp.com are readable by any subdomain, including the one they just claimed.
CSP bypass: If your Content Security Policy whitelists *.yourapp.com, the attacker is basically inside the house. Any scripts they serve will count as trusted.

Your browser has absolutely no way of knowing the subdomain changed hands.

Where to look

Any external hosting platform can be a vector. The most common culprits I see are Heroku (app deleted but CNAME stays), GitHub Pages (repo renamed), Netlify, and S3. Fastly, Pantheon, Azure, and Shopify all have the exact same problem. There's a solid community-maintained list at github.com/EdOverflow/can-i-take-over-xyz that tracks exploitable platforms and their specific error fingerprints.

How to check if you're vulnerable

Most teams don't have a full list of their subdomains. You'll need to export your DNS provider's zone file and read through it. Check old CI/CD configs for anywhere you set a CNAME. Finally, hit up crt.sh (certificate transparency logs) to see every subdomain you've ever issued a cert for:

curl "https://crt.sh/?q=%.yourapp.com&output=json" | jq '.[].name_value' | sort -u

Once you have your list, check if the target still exists for each CNAME:

dig CNAME staging.yourapp.com
curl -I https://yourapp.herokuapp.com

If dig returns a CNAME and curl gets a "No such app" or a 404, that's a dangling record. Someone could claim it right now. Also, make sure to check your A records. If you're pointing at an elastic IP that you've decommissioned, that IP might be sitting in a stranger's AWS account.

Fixing it

The fix is incredibly straightforward: just delete the DNS record.

The much harder part is making sure this doesn't keep happening. DNS cleanup usually doesn't make it onto shutdown checklists, but it needs to be treated with the same urgency as revoking API keys. When you decommission a service, delete the DNS record that same day and verify it no longer resolves. If you absolutely need to keep the subdomain, point it at something you control. Even a static page returning a 200 is enough to block a takeover.

Tools I use for this

ZeroHook (zerohook.org) for auditing DNS and subdomains in one place. It automatically flags dangling records and has a free tier.
crt.sh as a starting point for discovery.
subjack to automatically scan a list of subdomains for takeover vulnerabilities.
dnsx for fast bulk DNS resolution when the list gets long.

TL;DR

DNS records outlive the services they point to. That's the entire problem.

Check your subdomains, especially the old ones. If you've never audited your zone file, take 20 minutes and do it this week. You'll almost certainly find something. It's a five-minute fix if you catch it early, and a full-blown incident if you don't.

SPF, DKIM, DMARC: The Developer's Fixing Guide (2026)

Regő Botond Ronyecz — Thu, 23 Apr 2026 10:48:47 +0000

You deployed your app. Transactional emails are set up. Users sign up and trigger a welcome email, but it lands in spam or, worse, never arrives.

This isn't a code issue. It's a DNS configuration problem, and it's more common than you think.

This guide covers the three records every developer needs to understand: SPF, DKIM, and DMARC. We'll explain what they are, why they matter, and how to fix them.

THE PROBLEM: ANYONE CAN FAKE YOUR DOMAIN

Email was designed in the 1980s without any authentication. By default, anyone can send an email claiming to be from noreply@yourapp.com. There's no verification or signature.

This is why spam filters exist, and why they are so aggressive. If your domain appears untrustworthy due to missing records or misconfigured DNS, Gmail and Outlook will quietly hide your emails.

SPF, DKIM, and DMARC are the three DNS records that confirm you are actually sending from your domain.

SPF - "These servers are allowed to send for me"

SPF (Sender Policy Framework) is a TXT record on your domain that lists which mail servers are allowed to send emails on your behalf.

When Gmail receives an email from noreply@yourapp.com, it checks your DNS for an SPF record and asks: "Is this server on the allowed list?"

A typical SPF record looks like this:

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

Breaking this down:

v=spf1 is always the version identifier.
include:sendgrid.net means SendGrid's servers are allowed.
include:_spf.google.com means Google Workspace servers are allowed.
~all means anything else is a soft fail — it's suspicious, but not fully rejected.

The choice between ~all and -all is important. Use ~all while you're setting up. Switch to -all once you're sure every sending service is listed. Never use +all — it allows everyone.

A common mistake is hitting the 10-lookup limit. SPF has a hard limit of 10 DNS lookups. Each include: counts as one. If you use SendGrid, Mailchimp, Google Workspace, and Salesforce, you'll reach that limit quickly. If you go over, SPF fails even for legitimate emails. Check your lookup count before you deploy.

DKIM - "This email was signed by us"

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server checks this signature against a public key you publish in DNS.

Think of it as a wax seal. Anyone can see the letter, but only you have the stamp.

You publish a TXT record at a selector subdomain:

selector1._domainkey.yourapp.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSI..."

The actual signing happens in your email provider — SendGrid, Postmark, AWS SES, etc. They generate the key pair and give you the public key to add to DNS. You don't create this manually.

How to set it up:

Go to your email provider's dashboard (in SendGrid, it's Settings > Sender Authentication).
They'll give you 2-3 DNS records to add.
Add them to your DNS provider (Cloudflare, Route53, etc.).
Click Verify in the provider dashboard.

That's it. DKIM setup mostly involves copy-pasting — the complexity is handled by your provider.

One thing to note: some providers (SendGrid, Mailchimp) use CNAME records for DKIM instead of TXT. Both methods work. Just follow your provider's instructions.

DMARC - "Here's what to do if SPF/DKIM fails"

DMARC (Domain-based Message Authentication, Reporting & Conformance) connects SPF and DKIM and tells receiving servers what to do when authentication fails. It also sends you daily reports — summaries of who is sending email from your domain and whether it passed or failed.

The record goes at _dmarc.yourapp.com:

_dmarc.yourapp.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com"

The key field is p= (policy):

p=none — do nothing, just report.
p=quarantine — send failures to spam.
p=reject — block failing emails entirely.

The right rollout order:

Week 1-2: p=none. Just collect reports and don't block anything.
Week 3-4: Review reports and fix any legitimate sources you missed.
Month 2: p=quarantine. Failing emails go to spam.
Month 3+: p=reject. Once you're confident, implement hard rejection.

Don't start with p=reject. You risk blocking legitimate emails you didn't know about.

The reports arrive as XML attachments. They aren't user-friendly. Use a tool to parse them (more on that below). Don't skip this step — reports help you discover misconfigured services or someone spoofing your domain.

BONUS: TWO MORE RECORDS WORTH KNOWING

MTA-STS forces other mail servers to use TLS when connecting to yours. Without it, email in transit can be downgraded to unencrypted. It requires a TXT record plus a hosted policy file. It's a bit more setup, but worth it for transport security.

BIMI allows your logo to appear in Gmail's inbox next to your email. It requires p=quarantine or p=reject DMARC plus a verified mark certificate. It's mostly relevant for marketing emails, but it's a nice trust signal once everything else is in order.

THE FIX CHECKLIST

If your emails are going to spam, check the following:

SPF record exists — dig TXT yourdomain.com | grep spf
SPF includes all your sending services — SendGrid, Mailchimp, Google, etc.
SPF lookup count is 10 or under — use an SPF checker
DKIM is configured in your email provider and DNS records are verified
DMARC record exists — dig TXT _dmarc.yourdomain.com
DMARC rua= is set to receive reports
No duplicate SPF records — you can only have one SPF TXT record per domain

TOOLS I ACTUALLY USE

ZeroHook (zerohook.org) — Full DNS and email security audit in one place. There's a free tier available. It's worth checking if you have compliance requirements in the future.

MXToolbox (mxtoolbox.com) — SPF/DKIM/DMARC lookup, blacklist check. Good for a quick check.

mail-tester.com — Send a test email to get a deliverability score and see specific issues.

Postmark DMARC Digests (dmarc.postmarkapp.com) — Free DMARC report parser with a clean interface.

DMARC Analyzer (dmarcanalyzer.com) — More detailed, paid plans for ongoing monitoring.

Quick CLI checks without leaving the terminal:

dig TXT yourdomain.com (SPF)
dig TXT _dmarc.yourdomain.com (DMARC)
dig TXT selector1._domainkey.yourapp.com (DKIM)

TL;DR

Email authentication involves three DNS records that took the internet 20 years to adopt correctly. They aren't glamorous, but getting them right ensures your emails reach people.

SPF — whitelist your sending servers.
DKIM — cryptographically sign your emails.
DMARC — set a policy and get reports.

Start with p=none, read the reports for a few weeks, then tighten the policy. Don't skip the reports — they provide the actual signal.

If you found this helpful or have questions, leave a comment. I'm happy to discuss specific provider setups (AWS SES, SendGrid, Postmark) if you're interested.

Your DNS configuration mistakes are quietly breaking your emails

Regő Botond Ronyecz — Wed, 22 Apr 2026 10:57:11 +0000

Most people are not aware that their emails end up in spam
due to either wrong DMARC configuration or non-existent SPF record.
This is one of those issues that go unnoticed and are difficult to debug.

What usually happens is you search for anything on Google,
try five different tools, and are still lost in figuring out
what needs to be fixed. This happens to everyone – it's frustrating.

ZeroHook was recently discovered in the midst of such an ordeal.
Checks 30+ different items with respect to your email and DNS
configurations and offers solutions on which records need to be added.

Beta version for now, but definitely worth bookmarking if you
struggle with similar problems.

zerohook.org