DEV Community: toolbox-poster

How to Convert JSON Data Easily Online

toolbox-poster — Sun, 12 Apr 2026 19:26:28 +0000

JSON is the standard data format for APIs and web applications, but not everyone works with JSON natively. Marketers need CSV for spreadsheets, managers need formatted reports, and analysts need structured data they can sort and filter.

This guide walks through common JSON conversion tasks step by step, using free online tools that require no coding knowledge.

Converting JSON to CSV

The most common JSON conversion task is turning an array of objects into a spreadsheet-friendly CSV format.

Step 1: Get Your JSON Data

Your JSON typically comes from an API response, a database export, or a file. It should be an array of objects with consistent keys:

[{"name": "Alice", "email": "alice@example.com", "role": "Admin"}, {"name": "Bob", "email": "bob@example.com", "role": "User"}]

Step 2: Paste Into the Converter

Open our JSON to CSV Converter and paste your JSON data. The tool automatically detects the structure and extracts column headers from the object keys.

Step 3: Choose Your Delimiter

Select comma (standard CSV), tab (for tab-separated values), or semicolon (common in European locales where commas are decimal separators).

Step 4: Download or Copy

Click Download to save as a .csv file, or Copy to paste directly into Excel, Google Sheets, or any spreadsheet application.

Formatting JSON for Readability

Raw JSON from APIs is typically minified — a single long line with no formatting. This is efficient for transmission but impossible to read.

Using the JSON Formatter

Open our JSON Formatter, paste your raw JSON, and it's instantly formatted with proper indentation. You can choose 2-space or 4-space indentation, sort keys alphabetically, or switch to the interactive tree view for deep data exploration.

The formatter also validates your JSON in real time. If there's a syntax error — a missing comma, an unclosed bracket — you'll see an immediate error message telling you exactly what's wrong.

Validating JSON Before Processing

Before sending JSON to an API or saving it to a configuration file, validate it. Common issues include trailing commas (valid in JavaScript but NOT in JSON), single quotes (JSON requires double quotes), and unquoted keys.

Our JSON Formatter catches all these errors instantly. The validation runs as you type, so you can fix issues iteratively without switching between tools.

Working with Nested JSON

Many API responses contain deeply nested structures — objects within arrays within objects. For these, the tree view in our JSON Formatter is invaluable. Each level can be collapsed or expanded independently, and hovering shows the node type and child count.

Encoding JSON for URLs and APIs

Need to pass JSON as a URL parameter? Our URL Encoder properly encodes special characters like braces, brackets, and quotes so they survive URL transmission intact.

For embedding JSON in other contexts (email, database fields), our Base64 Encoder converts JSON to a safe, portable text format that can be stored or transmitted through any text-based channel.

Comparing JSON Structures

When you need to compare two JSON objects (e.g., staging vs. production config), use the Sort Keys feature to normalize key ordering first. With keys sorted identically, standard text diff tools will accurately highlight the actual value differences.

JSON to CSV Conversion Tips

Flatten nested objects first: CSV is a flat format — it doesn't support nesting. If your JSON has nested objects, you may need to flatten them or select specific fields.

Handle arrays within objects: If an object property contains an array, it will be converted to a string representation in CSV. For complex structures, consider extracting the nested data separately.

Check for consistent schemas: The converter works best when all objects have the same keys. Missing keys will produce empty cells in the CSV.

Conclusion

Converting and working with JSON doesn't require programming skills or expensive software. Our free online tools handle the most common tasks — JSON to CSV conversion, formatting and validation, and encoding for safe transmission — all in your browser with no data leaving your device.

Explore our complete collection of 20+ free tools for more data processing, conversion, and analysis utilities.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

DNS Lookup Explained: A Beginner's Guide

toolbox-poster — Sun, 12 Apr 2026 19:26:18 +0000

When you type a URL into your browser, a remarkable chain of events happens in milliseconds. The Domain Name System (DNS) translates the human-readable domain name into the numeric IP address that computers use to communicate. Understanding DNS is essential for anyone managing websites, email, or online services.

How DNS Works — The Big Picture

Think of DNS as the internet's phone book. Just as you look up a person's name to find their phone number, DNS looks up a domain name to find its IP address.

When you visit example.com:

1. Your browser checks its cache. If you recently visited the site, the IP address may be stored locally.

2. Your operating system checks its cache. The OS maintains its own DNS cache.

3. Your router/ISP resolver queries DNS servers. If the answer isn't cached locally, the query goes to a recursive DNS resolver (usually your ISP's or a public resolver like Cloudflare 1.1.1.1 or Google 8.8.8.8).

4. The resolver queries the authoritative name servers. Starting from the root servers, through the TLD (.com, .tn, .org) servers, to the domain's authoritative name servers.

5. The IP address is returned. Your browser can now connect to the web server.

This entire process typically takes 20-120 milliseconds.

Understanding DNS Record Types

A Records (Address)

The most fundamental record type. An A record maps a domain name to an IPv4 address (e.g., example.com → 93.184.216.34). This is what directs web traffic to your server.

You can check A records for any domain using our DNS Lookup tool.

AAAA Records (IPv6 Address)

The IPv6 equivalent of A records. As IPv4 addresses run out, AAAA records become increasingly important. They map domains to 128-bit IPv6 addresses like 2606:2800:220:1:248:1893:25c8:1946.

MX Records (Mail Exchange)

MX records specify which mail servers handle email for a domain. They include a priority value — lower numbers indicate higher priority. For example, Google Workspace typically uses:

MX 1 aspmx.l.google.com

MX 5 alt1.aspmx.l.google.com

MX 10 alt2.aspmx.l.google.com

If email isn't working for your domain, MX records are the first thing to check with our DNS Lookup.

CNAME Records (Canonical Name)

CNAME records create aliases. For example, www.example.com might have a CNAME pointing to example.com, or to a CDN like d1234.cloudfront.net.

Important: CNAME records cannot coexist with other record types for the same name (except DNSSEC records). This is why the root domain (example.com) typically uses A records instead of CNAME.

TXT Records

TXT records store text data and serve several critical functions:

SPF (Sender Policy Framework): Specifies which mail servers are authorized to send email from your domain. Prevents email spoofing.

DKIM (DomainKeys Identified Mail): Publishes the public key used to verify email digital signatures.

DMARC (Domain-based Message Authentication): Defines the policy for handling emails that fail SPF/DKIM checks.

Domain verification: Google, Microsoft, and other services use TXT records to verify domain ownership.

NS Records (Name Server)

NS records define which servers are authoritative for a domain's DNS zone. When you register a domain with a registrar and set nameservers, you're updating NS records.

Common DNS Problems and Solutions

"Website Not Found" After Domain Registration

DNS propagation can take 24-48 hours after changing nameservers. Check your A records with our DNS Lookup — if they return the correct IP but the site doesn't load, propagation may still be in progress.

Email Not Working

Check MX records first. Missing or incorrect MX records are the most common cause of email delivery failures. Also verify SPF and DKIM TXT records to prevent emails from being rejected as spam.

"Not Secure" SSL Warnings

If your SSL certificate covers example.com but you're accessing www.example.com (or vice versa), check that both A records and any CNAME records point correctly. Let's Encrypt certificates need to match the exact domain names in your DNS.

Using Our DNS Lookup Tool

Our DNS Lookup queries through Cloudflare's 1.1.1.1 resolver — one of the fastest and most reliable public DNS resolvers. Simply enter a domain and select the record type you want to check.

The tool queries A, AAAA, MX, CNAME, TXT, and NS records, displaying results with full detail including TTL (Time To Live) values that tell you how long the record is cached.

DNS Security Best Practices

Always set SPF, DKIM, and DMARC records for domains that send email. This prevents spoofing and improves deliverability.

Use low TTL values during changes (300 seconds) so updates propagate quickly. Increase TTL after changes are confirmed.

Monitor your DNS records regularly. Unexpected changes could indicate a domain hijacking attempt.

Conclusion

DNS is the invisible infrastructure that makes the internet work. Understanding record types, how resolution works, and how to diagnose common issues makes you more effective at managing any online presence. Start exploring with our DNS Lookup tool and our IP Address Lookup for complete network diagnostics.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

Why Online Tools Save Time in Daily Work

toolbox-poster — Sun, 12 Apr 2026 19:26:09 +0000

We don't lose productivity in big chunks — we lose it in small, repeated moments of friction. Looking up a conversion formula. Finding the right encoding function. Debugging a regex pattern. Checking a DNS record. These tasks take 2-5 minutes each, but they happen dozens of times per week.

Browser-based tools eliminate these moments entirely. Here's why they matter and how to build a toolkit that saves hours every week.

The Hidden Cost of Small Tasks

Consider a typical developer's week:

• Formatting JSON responses — 3 times, ~2 minutes each = 6 minutes

• Converting between units or currencies — 5 times, ~1 minute each = 5 minutes

• Encoding/decoding Base64 or URLs — 4 times, ~2 minutes each = 8 minutes

• Generating test passwords — 2 times, ~3 minutes each = 6 minutes

• Checking DNS records — 2 times, ~3 minutes each = 6 minutes

• Converting text case — 5 times, ~1 minute each = 5 minutes

• Counting words or characters — 3 times, ~1 minute each = 3 minutes

That's 39 minutes per week — over 33 hours per year — spent on tasks that should be instant. And this is a conservative estimate.

Why Browser-Based Beats Desktop

Zero Installation

Desktop tools need downloading, installing, updating, and managing licenses. Browser tools are always available at a URL — open it and work. No setup, no maintenance, no disk space.

Cross-Platform by Default

Working on a Mac at home, Windows at the office, and a Chromebook while traveling? Browser tools work identically everywhere. No platform-specific versions, no compatibility issues.

Always Current

Desktop software develops update fatigue. Browser tools update on every page load — you're always on the latest version with the newest features.

Shareable

When a colleague needs a tool, you send them a URL. No "download this app" or "configure these settings." Just a link.

Building Your Toolkit

The most productive approach is having a curated set of tools bookmarked and ready. Here's a recommended toolkit organized by task type:

For Developers

• JSON Formatter — Format, validate, and minify JSON

• Regex Tester — Test patterns with real-time matching

• Hash Generator — MD5/SHA hashes for integrity checks

• Base64 Encoder — Encode/decode strings and files

• URL Encoder — Encode URL components safely

For Writers & Marketers

• Word Counter — Count words with readability scoring

• Text Case Converter — Convert between text cases

• Lorem Ipsum Generator — Generate placeholder text

• QR Code Generator — Create codes for campaigns

For Everyone

• Currency Converter — Live exchange rates for 145+ currencies

• Unit Converter — Length, weight, temperature, and more

• Time Zone Converter — Schedule across timezones

• Password Generator — Create secure passwords

• Image Compressor — Shrink images for web

The Privacy Advantage

Many online tools send your data to servers for processing. This creates privacy concerns, especially for sensitive content like passwords, source code, or business data.

Client-side tools process everything in your browser — no data ever leaves your device. Every tool in our collection is 100% client-side, which means you can safely process confidential information without privacy worries.

Learn more about why this matters in our article on client-side processing and privacy.

Maximizing Efficiency

Bookmark your top 5 tools. The tools you use most should be one click away in your browser's bookmarks bar.

Use keyboard shortcuts. Most tools support Ctrl+V for paste and Ctrl+C for copy. Our tools also support Ctrl+K for a quick search across all tools from the header.

Keep tools open in pinned tabs. For tools you use many times per day (like JSON Formatter or Text Case Converter), pin the tab so it's always accessible without navigating.

Conclusion

Productivity is about eliminating friction, not working harder. Browser-based tools turn 2-minute tasks into 2-second tasks, and those saved minutes compound into significant time over weeks and months. Build your toolkit, bookmark the essentials, and reclaim your time for work that actually matters.

Start building your toolkit at toolbox.starnomina.tn/tools.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

SPF Records Explained: Prevent Email Spoofing with Sender Policy Framework

toolbox-poster — Sun, 12 Apr 2026 19:25:53 +0000

TL;DR
SPF (Sender Policy Framework) is the first line of defense against email spoofing, allowing domain owners to declare which IP addresses and servers are authorized to send mail on their behalf. Defined in RFC 7208, SPF has a deceptively simple syntax but hides critical constraints — most notably the 10 DNS lookup limit that silently breaks authentication for complex sending infrastructures. This guide covers every mechanism, qualifier, and modifier in the SPF specification, walks through real-world lookup counting, and explains how SPF interacts with DMARC alignment.

📑 Table of Contents

How SPF Works
SPF Result Codes
Full Mechanism Reference
The 10-Lookup Limit
Real Lookup Count Examples
Provider Include Directives
SPF + DMARC Alignment
SPF Flattening Techniques
Best Practices
Common Mistakes
Tools
Sources & References

1. How SPF Works

When a receiving mail server accepts an incoming SMTP connection, it extracts the domain from the MAIL FROM command (the envelope sender, also called the Return-Path) and performs a DNS TXT lookup on that domain. If an SPF record is found, the receiver evaluates the connecting IP against the authorized mechanisms listed in the record.

📖 Definition — SPF (Sender Policy Framework) is a DNS-based email authentication protocol (RFC 7208) that allows a domain owner to publish a list of IP addresses and hostnames authorized to send email using that domain as the envelope sender.

# SPF evaluation flow
1. Sender connects from IP 198.51.100.42
2. SMTP MAIL FROM: user@example.com
3. Receiver queries TXT record for example.com
4. Record: "v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all"
5. 198.51.100.42 matches ip4:198.51.100.0/24 → Result: PASS

⚠️ SPF does NOT validate the From: header that users see in their mail client. It validates the MAIL FROM (envelope sender / Return-Path). This is why DMARC alignment is required to connect SPF results to the visible sender identity.

2. SPF Result Codes

RFC 7208 §2.6 defines seven possible evaluation results:

Result	Qualifier	Meaning	Typical Action
Pass	`+` (default)	IP is explicitly authorized	Accept
Fail	`-`	IP is explicitly not authorized	Reject or mark as spam
SoftFail	`~`	IP is probably not authorized (transitional)	Accept but flag
Neutral	`?`	Domain makes no assertion about this IP	Accept
None	—	No SPF record found	Accept (no policy)
PermError	—	Permanent error (syntax error, >10 lookups)	Treat as fail or neutral (receiver-dependent)
TempError	—	Temporary DNS error	Try again later (4xx)

🚫 PermError is silent and catastrophic. If your SPF record exceeds 10 DNS lookups, receivers return PermError — which many treat as a fail. Your legitimate mail gets blocked or junked, and you receive no bounce notification.

3. Full Mechanism Reference

Mechanism	DNS Lookups	Syntax	Description
`ip4`	0	`ip4:198.51.100.0/24`	Match IPv4 address or CIDR range
`ip6`	0	`ip6:2001:db8::/32`	Match IPv6 address or CIDR range
`a`	1	`a` or `a:mail.example.com`	Match the A/AAAA record of the domain
`mx`	1 + MX lookups	`mx` or `mx:example.com`	Match the MX hosts' IPs
`include`	1 + nested	`include:_spf.google.com`	Evaluate another domain's SPF record recursively
`exists`	1	`exists:%{i}.bl.example.com`	Pass if A record exists for macro-expanded domain
`all`	0	`-all` / `~all`	Catch-all — always matches (must be last)
`redirect`	1	`redirect=_spf.example.com`	Replace entire record with another domain's SPF
`exp`	1	`exp=explain._spf.example.com`	Custom explanation string for failures

💡 The ptr mechanism exists in the spec but RFC 7208 §5.5 explicitly discourages its use: "This mechanism SHOULD NOT be published." It is slow, unreliable, and counts as a DNS lookup.

4. The 10 DNS Lookup Limit

RFC 7208 §4.6.4 imposes a hard limit: SPF evaluation must not cause more than 10 DNS mechanisms/modifiers that require lookups. This includes include, a, mx, exists, redirect, and ptr. It does not include ip4, ip6, or all.

# These count toward the 10-lookup limit:
include:   → 1 lookup (+ any nested lookups from the included record)
a          → 1 lookup
mx         → 1 lookup (+ additional A lookups for each MX host)
exists     → 1 lookup
redirect   → 1 lookup
ptr        → 1 lookup (deprecated)

# These do NOT count:
ip4:       → 0 lookups (direct IP comparison)
ip6:       → 0 lookups (direct IP comparison)
all        → 0 lookups (catch-all terminator)

10maximum DNS lookups allowed per SPF evaluation (RFC 7208 §4.6.4)

⚠️ The limit is recursive. If include:_spf.google.com itself contains 3 include: directives, those 3 count toward your total of 10.

Void Lookup Limit

RFC 7208 §4.6.4 also defines a void lookup limit of 2. A void lookup is a DNS query that returns either NXDOMAIN or an empty answer. If more than 2 void lookups occur during evaluation, the result is PermError.

5. Real Lookup Count Examples

Here is a real-world example of how lookups accumulate for a domain using Google Workspace, Mailchimp, and SendGrid:

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

Lookup count breakdown:
┌─ include:_spf.google.com          → 1
│  ├─ include:_netblocks.google.com  → 2
│  ├─ include:_netblocks2.google.com → 3
│  └─ include:_netblocks3.google.com → 4
├─ include:servers.mcsv.net          → 5
│  └─ include:mcsv.net               → 6
├─ include:sendgrid.net              → 7
│  └─ include:u12345.wl.sendgrid.net → 8
└─ Total: 8 lookups ✅ (under 10)

🚫 Now add Salesforce (include:_spf.salesforce.com → 1) and Zendesk (include:mail.zendesk.com → 2 nested). That brings you to 11 lookups — PermError. Your email breaks silently.

6. Provider Include Directives

Provider	Include Directive	DNS Lookups Used
Google Workspace	`include:_spf.google.com`	~4
Microsoft 365	`include:spf.protection.outlook.com`	~2
SendGrid	`include:sendgrid.net`	~2
Mailchimp	`include:servers.mcsv.net`	~2
Amazon SES	`include:amazonses.com`	~1
Salesforce	`include:_spf.salesforce.com`	~1
HubSpot	`include:spf.hubspot.com`	~2
Zendesk	`include:mail.zendesk.com`	~3
Freshdesk	`include:email.freshdesk.com`	~2

⚡ Pro Tip: Before adding a new include:, always check its nested lookup count with an SPF checker tool. A single include can consume 1–5 lookups depending on the provider's own SPF chain.

7. SPF + DMARC Alignment

For DMARC to consider SPF as a passing authentication method, two conditions must be met:

SPF must evaluate to Pass for the MAIL FROM domain.
The MAIL FROM domain must align with the From: header domain (relaxed or strict per DMARC's aspf tag).

⚠️ Most third-party senders use their own Return-Path (e.g., bounces.sendgrid.net), which means SPF passes for their domain, not yours. SPF alignment fails — DMARC must rely on DKIM alignment instead.

Custom Return-Path

To achieve SPF alignment with third-party senders, configure a custom return-path using your subdomain:

# Instead of:
Return-Path: bounces@em.sendgrid.net     → SPF passes for sendgrid.net (not aligned)

# Configure:
Return-Path: bounces@em.yourdomain.com   → SPF passes for yourdomain.com (aligned!)

# DNS: Add CNAME
em.yourdomain.com → u12345.wl.sendgrid.net

8. SPF Flattening Techniques

When you hit the 10-lookup limit, SPF flattening replaces include: directives with their resolved ip4: and ip6: addresses, reducing lookups to zero for those entries.

# Before flattening (8 lookups):
v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net -all

# After flattening (0 lookups for Google IPs):
v=spf1 ip4:209.85.128.0/17 ip4:172.217.0.0/16 ip4:108.177.8.0/21
       include:servers.mcsv.net include:sendgrid.net -all

🚫 Flattening is fragile. Provider IPs change without notice. If Google adds a new IP range and your flattened record doesn't include it, mail from that IP fails SPF. You must automate flattening with a tool that re-resolves and updates your DNS record regularly.

🎯 A safer alternative to flattening is using the redirect= modifier to point to a dynamically managed SPF record on a subdomain, or using a service like Cloudflare's SPF management that handles flattening automatically.

9. Best Practices

End with -all
Use a hard fail (-all) in production. ~all (softfail) is for testing only; it lets unauthorized mail through.

Monitor lookup count
Check your total DNS lookup count after every change. A single vendor addition can push you over 10.

One record per domain
RFC 7208 §3.2: a domain must not have multiple SPF records. Two records cause PermError.

Avoid deprecated mechanisms
Never use ptr. It's slow, unreliable, and wastes a lookup. RFC 7208 explicitly discourages it.

Use ip4/ip6 for static IPs
Dedicated servers with fixed IPs should use ip4:/ip6: — no lookup cost.

Keep under 255 characters per string
DNS TXT records are limited to 255-byte strings. Long records must be split into multiple strings within a single TXT record set.

10. Common Mistakes

🚫 Multiple SPF records on the same domain. Publishing two TXT records that start with v=spf1 causes PermError (RFC 7208 §3.2). Merge them into one record.

🚫 Exceeding the 10-lookup limit. This is the #1 SPF misconfiguration. Every include: adds lookups recursively. Use an SPF checker to validate the total.

⚠️ Using +all. A record ending with +all authorizes the entire internet to send as your domain. This is equivalent to having no SPF record at all.

⚠️ Forgetting the v=spf1 prefix. Without the version tag, the TXT record is not recognized as SPF. Receivers will return "None" (no SPF found).

⚠️ Confusing include with redirect. include: evaluates another record and returns its result. redirect= replaces the entire evaluation with another domain's record. redirect cannot coexist with all.

⚠️ Placing mechanisms after all. The all mechanism matches everything — anything after it is never evaluated. Always put all last.

11. Tools

Validate and build your SPF records with these tools:

Tool	Purpose
SPF Record Checker	Validate syntax, count DNS lookups, detect errors
SPF Record Generator	Build a syntactically correct SPF record by selecting providers

12. Sources & References

📄 RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
📄 RFC 7489 — DMARC
📄 Google Workspace — Authorize email senders with SPF
📄 Microsoft 365 — Set up SPF to help prevent spoofing
📄 Cloudflare — What is an SPF record?
📄 M3AAWG — Best Practices for Implementing DMARC (includes SPF guidance)

🎯 Key Takeaway: SPF tells the world which IPs may send email as your domain — but it only validates the envelope sender, not the visible From: header. Respect the 10 DNS lookup limit religiously, always end with -all, and pair SPF with DKIM so DMARC has a reliable alignment path that survives forwarding. Check your lookup count after every change.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

DKIM Explained: How Email Digital Signatures Protect Your Domain

toolbox-poster — Sun, 12 Apr 2026 19:25:12 +0000

TL;DR
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email, allowing recipients to verify that the message was authorized by the domain owner and was not tampered with in transit. Defined in RFC 6376, DKIM is the most resilient authentication mechanism in the email stack — unlike SPF, it survives forwarding. This guide details the signing architecture, dissects every tag in the DKIM-Signature header, compares RSA and Ed25519 algorithms, and covers key rotation, canonicalization, over-signing, and common failure modes.

📑 Table of Contents

How DKIM Works
DKIM-Signature Header Anatomy
The Selector Concept
RSA vs Ed25519
Canonicalization: Simple vs Relaxed
Key Rotation Procedure
DKIM + DMARC Alignment
Over-Signing
Best Practices
Common Failures
Tools
Sources & References

1. How DKIM Works

DKIM uses asymmetric cryptography (public/private key pair) to sign emails. The sending server holds the private key; the public key is published in DNS. When a recipient receives the message, it retrieves the public key and verifies the signature.

Key Generation
The domain owner generates an RSA (or Ed25519) key pair. The private key is installed on the mail server or ESP. The public key is published as a DNS TXT record at selector._domainkey.example.com.

Message Signing
The sending MTA selects headers to sign (e.g., From, To, Subject, Date) and the message body. It canonicalizes them (normalizes whitespace), hashes the result, and encrypts the hash with the private key.

Signature Insertion
The encrypted hash (signature) and metadata are placed in a DKIM-Signature header prepended to the message. This header includes the selector, algorithm, signed headers list, and the base64-encoded signature value.

DNS Lookup
The receiving MTA reads the DKIM-Signature header, extracts the selector (s=) and domain (d=), and queries s._domainkey.d for the public key TXT record.

Verification
The receiver re-canonicalizes the signed headers and body, computes the hash, and uses the public key to decrypt the signature. If the hashes match, the signature is valid — the message is authentic and unmodified.

DMARC Evaluation
If the d= domain aligns with the From: header domain (relaxed or strict), DMARC considers DKIM as a passing authentication result.

💡 DKIM does not encrypt the message content. It only provides a digital signature that proves origin and integrity. The message itself is still transmitted in cleartext (unless TLS is used at the transport layer).

2. DKIM-Signature Header Anatomy

Every DKIM-signed message contains a DKIM-Signature header with the following tags:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1; t=1712880000;
  x=1713484800; h=from:to:subject:date:message-id:mime-version;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=LjxLMKpHN2kQz... (signature value)

Tag	Required	Meaning	Values
`v`	Yes	Version	`1` (always)
`a`	Yes	Signing algorithm	`rsa-sha256`, `rsa-sha1` (deprecated), `ed25519-sha256`
`d`	Yes	Signing domain (DMARC alignment key)	e.g., `example.com`
`s`	Yes	Selector (lookup key for public key)	e.g., `selector1`, `google`, `s1`
`h`	Yes	Signed header fields	Colon-separated list of header names
`b`	Yes	Signature data (base64)	Cryptographic signature value
`bh`	Yes	Body hash (base64)	Hash of the canonicalized body
`c`	No	Canonicalization (header/body)	`simple/simple` (default), `relaxed/relaxed`, `relaxed/simple`
`t`	No	Signature timestamp (Unix epoch)	e.g., `1712880000`
`x`	No	Signature expiration (Unix epoch)	e.g., `1713484800`
`l`	No	Body length limit (bytes signed)	Integer — avoid using
`i`	No	Agent or user identifier	Must be a subdomain of `d=`
`q`	No	Query method	`dns/txt` (default, only value)
`z`	No	Copied header fields (for diagnostics)	Pipe-separated copies of signed headers

🚫 Never use the l= (body length) tag. It tells verifiers to only check the first N bytes of the body, allowing attackers to append malicious content after the signed portion. RFC 6376 §8.2 explicitly warns about this vulnerability.

3. The Selector Concept

A selector is a label that lets a single domain have multiple DKIM keys simultaneously — essential for key rotation and multi-service environments. The public key is published at ._domainkey..

📖 Definition — A DKIM selector is an arbitrary string chosen by the domain owner that identifies a specific public key record in DNS. It is specified in the s= tag of the DKIM-Signature header and used to construct the DNS query: selector._domainkey.domain.com.

Selectors by Provider

Provider	Typical Selector(s)	DNS Record Location
Google Workspace	`google`	`google._domainkey.example.com`
Microsoft 365	`selector1`, `selector2`	`selector1._domainkey.example.com`
SendGrid	`s1`, `s2`	`s1._domainkey.example.com`
Mailchimp	`k1`	`k1._domainkey.example.com`
Amazon SES	Auto-generated (CNAME-based)	3 CNAME records per domain
Postmark	`20240101` (date-based)	CNAME to Postmark DNS

⚡ Pro Tip: Use descriptive selectors that include the date or purpose: google-2024, marketing-q1. This makes key rotation audits much easier — you can tell at a glance which keys are current and which are deprecated.

4. RSA vs Ed25519

RFC 8463 (2018) introduced Ed25519 as an alternative to RSA for DKIM signatures. Here's how they compare:

Property	RSA-SHA256	Ed25519-SHA256
RFC	RFC 6376	RFC 8463
Key Size	1024–4096 bits (2048 recommended)	256 bits (fixed)
Signature Size	~342 bytes (2048-bit)	88 bytes (fixed)
DNS TXT Record Size	~400 bytes (2048-bit public key)	~60 bytes
Performance	Slower signing & verification	Significantly faster
Security	Secure at 2048+ bits	128-bit equivalent security
Receiver Support	Universal	Growing (Gmail, Fastmail support it)

🎯 Dual-sign with both RSA-2048 and Ed25519. Receivers that support Ed25519 benefit from smaller signatures and faster verification. Receivers that don't will fall back to the RSA signature. Each signature uses a different selector.

⚠️ 1024-bit RSA keys are deprecated. RFC 8301 (2018) requires a minimum of 2048 bits for RSA DKIM keys. Some receivers (notably Gmail) will reject 1024-bit signatures. Rotate immediately if you're still using 1024-bit keys.

5. Canonicalization: Simple vs Relaxed

Canonicalization normalizes the message before hashing to tolerate minor modifications by intermediate mail servers. The c= tag specifies the algorithm for headers and body separately (e.g., c=relaxed/relaxed).

Mode	Headers	Body
Simple	No changes — headers must be byte-identical	Trailing empty lines removed; no other changes
Relaxed	Header names lowercased; whitespace folding normalized; trailing whitespace removed	Whitespace sequences reduced to single space; trailing whitespace on lines removed; trailing empty lines removed

# simple/simple — very strict, breaks easily:
Subject: Hello World     ←  exact bytes must match

# relaxed/relaxed — tolerant of whitespace changes:
Subject:Hello World      ←  extra spaces and case changes are normalized
subject: hello world     ←  both canonicalize to the same form

⚡ Pro Tip: Always use c=relaxed/relaxed. Intermediate servers (mailing lists, forwarding services, antivirus gateways) frequently modify whitespace. Simple canonicalization causes unnecessary DKIM failures in real-world mail flows.

6. Key Rotation Procedure

DKIM keys should be rotated periodically (every 6–12 months) to limit exposure if a private key is compromised. The selector mechanism makes zero-downtime rotation straightforward.

Generate new key pair
Create a new RSA-2048 or Ed25519 key pair with a new selector (e.g., dkim-202604).

Publish new public key
Add the new TXT record at dkim-202604._domainkey.example.com. Wait for DNS propagation (TTL).

Switch signing to new selector
Configure your MTA/ESP to sign outgoing mail with the new private key and selector.

Monitor for failures
Watch DMARC reports and DKIM verification headers for a few days. Ensure the new key passes.

Revoke old key
After the overlap period (1–2 weeks), publish an empty p= tag for the old selector: v=DKIM1; p=. This tells receivers the key is revoked.

Remove old DNS record
After another TTL cycle, delete the old selector's DNS record entirely.

💡 An empty p= tag in a DKIM DNS record (RFC 6376 §3.6.1) is the official revocation signal. It tells verifiers that the key has been deliberately revoked, as opposed to a missing record which could be a DNS failure.

7. DKIM + DMARC Alignment

For DMARC to consider DKIM as a passing result, two conditions must be met:

DKIM signature must verify (valid cryptographic signature).
The d= domain must align with the From: header domain.

Scenario	DKIM `d=`	From Header	DMARC `adkim`	Aligned?
Exact match	`example.com`	`user@example.com`	Any	Yes
Subdomain (relaxed)	`mail.example.com`	`user@example.com`	`r`	Yes
Subdomain (strict)	`mail.example.com`	`user@example.com`	`s`	No
Third-party domain	`sendgrid.net`	`user@example.com`	Any	No

⚠️ Many ESPs sign with d=esp-domain.com by default. You must configure custom DKIM signing so the d= tag uses your domain (or a subdomain of it in relaxed mode) for DMARC alignment to work.

8. Over-Signing

📖 Definition — Over-signing is a DKIM best practice where the h= tag includes headers that are not present in the message (e.g., listing Reply-To twice). This prevents attackers from adding a spoofed Reply-To header after signing — any addition would invalidate the signature.

# Over-signing example: listing headers that don't exist in the message
h=from:to:subject:date:reply-to:reply-to:cc:cc

# "reply-to" is listed twice:
# First instance covers the actual Reply-To header (if present)
# Second instance "seals" the slot — adding a new Reply-To breaks the signature

🎯 Over-sign these headers at minimum: From, To, Subject, Date, Reply-To, CC, Content-Type, MIME-Version, Message-ID. Over-signing prevents post-signature header injection attacks.

9. Best Practices

Use 2048-bit RSA minimum
1024-bit keys are deprecated (RFC 8301). Generate 2048-bit keys for all selectors.

Use relaxed/relaxed canonicalization
Simple canonicalization fails too easily with intermediate MTAs. Relaxed is the industry standard.

Sign with your domain
Ensure the d= tag matches your From: domain for DMARC alignment. Configure custom DKIM on every ESP.

Rotate keys every 6–12 months
Use the selector system for zero-downtime rotation. Revoke old keys with an empty p= tag.

Over-sign critical headers
List From, Reply-To, Subject, and CC twice in the h= tag to prevent header injection.

Never use the l= tag
Body length limits allow content to be appended to signed messages. Always sign the full body.

10. Common Failures

🚫 DNS record not found. The most common DKIM failure. Usually caused by a typo in the selector name, missing CNAME, or DNS propagation delay. Always verify with dig TXT selector._domainkey.example.com.

🚫 Body hash mismatch (bh= tag). The body was modified after signing — typically by a mailing list, antivirus gateway, or footer-appending service. Use relaxed body canonicalization and investigate the specific MTAs in the delivery chain.

⚠️ Key too short. 512-bit and 1024-bit RSA keys are rejected by many receivers. Gmail logs dkim=neutral (body hash did not verify) for weak keys even when the signature is mathematically valid.

⚠️ Expired signature. If the x= tag is set and the current time exceeds it, the signature is treated as invalid. Use generous expiration windows (7+ days) or omit x= entirely.

⚠️ Testing with email headers. To debug DKIM, view the full message headers and look for Authentication-Results. Gmail shows dkim=pass, dkim=fail, or dkim=neutral with a reason string.

# Gmail Authentication-Results header example:
Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=selector1 header.b=LjxLMKpH;
  spf=pass (google.com: domain of user@example.com designates 198.51.100.42 as permitted sender);
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

11. Tools

Tool	Purpose
DKIM Record Checker	Look up any selector's public key and validate record syntax

12. Sources & References

📄 RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
📄 RFC 8463 — A New Cryptographic Signature Method for DKIM (Ed25519-SHA256)
📄 RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM
📄 RFC 7489 — DMARC
📄 Google Workspace — Turn on DKIM signing
📄 Microsoft 365 — Use DKIM to validate outbound email
📄 Cloudflare — What is a DKIM record?
📄 M3AAWG — Best Practices (includes DKIM guidance)

🎯 Key Takeaway: DKIM is the most durable email authentication mechanism — it survives forwarding, validates message integrity, and provides the preferred alignment path for DMARC. Use 2048-bit RSA or Ed25519, always choose relaxed/relaxed canonicalization, sign with your own domain for DMARC alignment, over-sign critical headers, rotate keys every 6–12 months, and never use the l= body length tag.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

BIMI: Display Your Brand Logo in Email Inboxes

toolbox-poster — Sun, 12 Apr 2026 19:24:22 +0000

TL;DR
BIMI (Brand Indicators for Message Identification) is the final layer in the email authentication stack, allowing organizations to display their brand logo directly in recipients' inboxes next to authenticated messages. Built on top of DMARC enforcement, BIMI transforms email authentication from an invisible infrastructure concern into a visible brand asset. This guide covers the DNS record format, SVG Tiny PS requirements, VMC certificates, provider support, cost analysis, and the full setup procedure — including when BIMI is (and isn't) worth the investment.

📑 Table of Contents

How BIMI Works
DNS Record Format
SVG Tiny PS Requirements
VMC Certificates
Provider Support Matrix
DMARC Prerequisite
Cost Analysis
Setup Steps
Best Practices
Common Mistakes
Tools
Sources & References

1. How BIMI Works

BIMI leverages the existing email authentication stack (SPF, DKIM, DMARC) and adds a visual trust indicator. When a message passes DMARC with an enforcement policy, the receiving mail client looks up the sender's BIMI DNS record to retrieve a logo URL and (optionally) a VMC certificate that validates brand ownership.

Message arrives
The receiver performs standard SPF, DKIM, and DMARC evaluation. The message must pass DMARC with p=quarantine or p=reject.

BIMI DNS lookup
The receiver queries default._bimi.example.com for a TXT record containing the logo URL and optional VMC URL.

Logo retrieval & VMC validation
The receiver fetches the SVG logo from the l= URL. If a a= (authority) URL is present, it fetches and validates the VMC certificate against the domain and logo.

Logo display
If all checks pass, the mail client displays the brand logo as the sender's avatar. Without BIMI, a generic initial or silhouette is shown.

📖 Definition — BIMI (Brand Indicators for Message Identification) is an email specification that enables domain owners to display a verified brand logo in supporting email clients, contingent on DMARC enforcement and (for some providers) a Verified Mark Certificate (VMC).

💡 BIMI is not just cosmetic. Research from the BIMI Working Group shows that brand logos increase email open rates by 10–39% and significantly improve brand recall. It's a deliverability and marketing asset as much as a security one.

2. DNS Record Format

A BIMI record is a DNS TXT record published at default._bimi.yourdomain.com:

default._bimi.example.com  TXT  "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"

Tag	Required	Meaning	Value
`v`	Yes	Version	`BIMI1`
`l`	Yes	Logo URL (HTTPS)	URL to SVG Tiny PS file
`a`	No*	Authority (VMC certificate URL)	URL to PEM-encoded VMC

Gmail and Apple Mail **require* a VMC (a= tag) to display the logo. Without it, only providers like Fastmail and Yahoo display BIMI logos.

⚠️ The l= URL must use HTTPS with a valid TLS certificate. HTTP URLs are rejected. The SVG file must be served with Content-Type: image/svg+xml and appropriate CORS headers.

Selector Variants

The default selector covers all mail. You can publish additional selectors for different use cases (e.g., marketing._bimi.example.com), though receiver support for non-default selectors is limited.

# Default BIMI record — applies to all mail
default._bimi.example.com  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

# To explicitly disable BIMI for a domain:
default._bimi.example.com  TXT  "v=BIMI1; l=;"

3. SVG Tiny PS Requirements

BIMI does not accept standard SVG files. The logo must conform to SVG Tiny PS (Portable/Secure), a restricted profile designed for security and consistent rendering across mail clients.

📖 Definition — SVG Tiny PS is a constrained subset of the SVG Tiny 1.2 specification, created specifically for BIMI. It removes scripting, external references, and other features that could pose security risks in email clients.

Key Requirements

Requirement	Detail
Profile declaration	Must include `baseProfile="tiny-ps"` and `version="1.2"`
Dimensions	Square aspect ratio required; `viewBox` must be square
Title element	Must contain a `` element
No scripting	No ``, event handlers, or JavaScript
No external references	No `xlink:href` to external resources, no `` elements
No animations	No `,` , or SMIL elements
No raster images	No embedded PNG/JPEG via data URIs or external links
File size	Should be under 32 KB (recommended limit)
Background	Should have a solid background — transparent logos render poorly on varied email client backgrounds

Minimal Valid SVG Tiny PS Template

`plaintext

Example Corp Logo

🚫 Common SVG errors that break BIMI: Missing baseProfile="tiny-ps", non-square viewBox, embedded tags, xlink:href references, inline styles using url() for external resources, gradients referencing filters. Always validate with the BIMI Group's SVG checker.

⚡ Pro Tip: Export your logo from a vector editor (Illustrator, Figma), then manually clean the SVG: remove metadata, comments, embedded fonts, and Illustrator-specific namespaces. Add the baseProfile="tiny-ps" and version="1.2" attributes. Validate with the BIMI validator before publishing.

4. VMC Certificates

A Verified Mark Certificate (VMC) is an X.509 certificate that cryptographically binds your brand logo to your domain. It is issued by a Certificate Authority after verifying your trademark registration and domain ownership.

VMC Issuers

Certificate Authority	Annual Cost (approx.)	Trademark Requirement
DigiCert	$1,299 – $1,499/year	Registered trademark (USPTO, EUIPO, WIPO Madrid, etc.)
Entrust	$1,299 – $1,499/year	Registered trademark

💡 As of 2024, DigiCert and Entrust are the only two Certificate Authorities authorized to issue VMC certificates. The BIMI Working Group requires CAs to be members and follow strict validation procedures.

VMC Validation Requirements

Registered trademark — Your logo must be a registered trademark in an accepted jurisdiction (USPTO, EUIPO, CIPO, IP Australia, WIPO Madrid Protocol, and others).
Domain ownership — You must prove ownership/control of the domain specified in the certificate.
Logo match — The SVG file referenced in your BIMI record must match the trademarked logo in the VMC.
DMARC enforcement — Your domain must have p=quarantine or p=reject.

⚠️ The VMC issuance process typically takes 3–6 weeks due to trademark verification. Plan ahead — you cannot rush this step.

5. Provider Support Matrix

Mail Provider	BIMI Support	VMC Required?	Notes
Gmail	Yes	Yes	Full support since July 2021; requires VMC
Apple Mail	Yes	Yes	Supported since iOS 16 / macOS Ventura
Yahoo/AOL	Yes	No	Displays BIMI logos without VMC
Fastmail	Yes	No	Early BIMI adopter; no VMC needed
Microsoft Outlook	Partial	—	Uses proprietary "Brand Indicators" via Microsoft 365 admin; not standard BIMI
Zoho Mail	Yes	No	Supports BIMI without VMC
ProtonMail	No	—	No BIMI support as of 2025
Thunderbird	No	—	No BIMI support

1.8B+mailboxes support BIMI (Gmail + Apple Mail + Yahoo)

6. DMARC Prerequisite

BIMI has a hard dependency on DMARC enforcement. Your domain must have a DMARC record with p=quarantine or p=reject for BIMI logos to be displayed.

DMARC Policy	BIMI Effect
`p=none`	BIMI ignored — logo is not displayed
`p=quarantine`	BIMI active — logo displayed for passing messages
`p=reject`	BIMI active — logo displayed for passing messages

🎯 If you haven't deployed DMARC yet, start there. Follow the phased rollout (p=none → p=quarantine → p=reject) before investing in BIMI and VMC. BIMI is the reward for achieving full email authentication maturity.

7. Cost Analysis

BIMI itself is free (it's a DNS record). The costs come from the VMC certificate and preparation:

Item	Cost	Frequency
BIMI DNS record	Free	One-time setup
SVG Tiny PS logo creation	$0 – $500	One-time (designer time or self-service)
Trademark registration (if not already registered)	$250 – $2,000+	Initial filing + maintenance
VMC certificate (DigiCert or Entrust)	$1,299 – $1,499	Annual renewal
DMARC enforcement (prerequisite)	$0 – varies	Ongoing monitoring & management

💡 Without VMC: For Yahoo, Fastmail, and Zoho, you can deploy BIMI for free (just a DNS record + SVG). For Gmail and Apple Mail (the vast majority of consumer mailboxes), you need a VMC. The total first-year cost with VMC is typically $1,500 – $3,500.

When BIMI Is Worth It

High email volume
If you send millions of emails monthly, a 10–39% increase in open rates easily justifies the VMC cost.

Strong brand recognition
Recognizable logos (retail, finance, SaaS) benefit most. A logo people don't recognize adds no value.

Already have a trademark
If your logo is already registered, VMC cost is the only expense — the ROI is very favorable.

Phishing target
Financial institutions, e-commerce platforms, and government agencies that are frequently impersonated get anti-phishing benefits from visual brand verification.

⚠️ BIMI is NOT worth it if: You haven't achieved p=reject DMARC yet, you send very low volume, your brand is new/unknown, or your logo isn't trademarked and you don't plan to trademark it.

8. Setup Steps

Achieve DMARC Enforcement
Ensure your domain has p=quarantine or p=reject with 100% alignment. BIMI requires DMARC to work.

Prepare SVG Tiny PS Logo
Convert your logo to SVG Tiny PS format. Square aspect ratio, no scripts, no external references, no raster images. Set baseProfile="tiny-ps" and version="1.2".

Validate SVG
Use the BIMI Group's SVG validator or the BIMI Inspector tool to check compliance before publishing.

Obtain VMC (Optional/Required)
If targeting Gmail/Apple Mail, purchase a VMC from DigiCert or Entrust. Provide your trademark registration number and domain verification.

Host Assets
Upload the SVG and VMC PEM file to your web server over HTTPS. Ensure correct Content-Type headers and public accessibility.

Publish DNS Record
Add a TXT record at default._bimi.yourdomain.com with the v=BIMI1; l= and a= tags pointing to your hosted files.

Test & Verify
Send a test email to a Gmail account and check if the logo appears. Use BIMI Inspector to verify DNS, SVG, and VMC configuration.

`plaintext

Complete DNS configuration example:

1. DMARC record (prerequisite)

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

2. BIMI record

default._bimi.example.com TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"
`

9. Best Practices

Validate SVG rigorously
Use the official BIMI Group validator. Even minor deviations from SVG Tiny PS will cause silent failures — no logo, no error.

Use a solid background
Transparent SVG backgrounds render differently across email clients. Use a solid brand-color background for consistent appearance.

Keep SVG under 32 KB
While not a hard limit, larger files may be rejected or slow to render. Optimize paths and remove unnecessary metadata.

Monitor DMARC continuously
BIMI vanishes if your DMARC policy drops below enforcement. A single misconfiguration can remove your logo from billions of inboxes.

Plan for VMC renewal
VMC certificates expire annually. Set a calendar reminder 30 days before expiration and renew early to avoid logo disappearance.

Cache and CDN considerations
Receivers cache your SVG logo. After updating, it may take days for the new version to propagate. Use a different filename or cache-busting query parameter.

10. Common Mistakes

🚫 Using standard SVG instead of SVG Tiny PS. Regular SVG files exported from Illustrator, Figma, or Inkscape include features not allowed in Tiny PS (gradients with filters, embedded images, metadata). The logo will silently fail to display.

🚫 Deploying BIMI with p=none DMARC. BIMI requires DMARC enforcement (quarantine or reject). With p=none, receivers ignore the BIMI record entirely.

⚠️ Non-square logo. BIMI requires a square aspect ratio. Rectangular logos will be rejected or cropped unpredictably by mail clients.

⚠️ Hosting SVG over HTTP. The l= tag must point to an HTTPS URL with a valid TLS certificate. HTTP URLs are rejected by all BIMI-supporting receivers.

⚠️ Expecting instant display. After publishing a BIMI record, it can take 24–72 hours for receiver caches to populate. Gmail specifically crawls BIMI records on its own schedule.

⚠️ Forgetting the VMC for Gmail. About 30% of all email goes to Gmail. Without a VMC, your BIMI setup covers only Yahoo, Fastmail, and smaller providers — a fraction of your audience.

11. Tools

Tool	Purpose
BIMI Record Checker	Look up BIMI DNS records, validate SVG URL, and check VMC presence

12. Sources & References

📄 BIMI Group — Implementation Guide
📄 BIMI Group — SVG Tiny PS Specification
📄 Google Workspace — Set up BIMI
📄 Google — BIMI requirements and troubleshooting
📄 DigiCert — Verified Mark Certificates (VMC)
📄 Entrust — Verified Mark Certificates (VMC)
📄 RFC 7489 — DMARC (BIMI dependency)
📄 RFC 6376 — DKIM (authentication layer)
📄 RFC 7208 — SPF (authentication layer)

🎯 Key Takeaway: BIMI is the visible payoff of a mature email authentication stack. It requires DMARC enforcement (p=quarantine or p=reject), a logo in SVG Tiny PS format, and — for Gmail and Apple Mail — a Verified Mark Certificate (~$1,500/year). Deploy BIMI after you've achieved full DMARC enforcement, not before. For high-volume senders with recognized brands, the ROI in open rates and brand protection is substantial. For everyone else, get your DMARC house in order first — BIMI is the cherry on top.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

SSL/TLS Certificates Explained: HTTPS Security for Every Website

toolbox-poster — Sun, 12 Apr 2026 19:24:11 +0000

TL;DR
SSL/TLS certificates are the backbone of encrypted web communication, authenticating server identity and
protecting data in transit. With over 95% of web traffic now encrypted via HTTPS, understanding certificate
types, the TLS 1.3 handshake, certificate chains, and common pitfalls is essential for every developer and
sysadmin. This guide covers the full lifecycle — from issuance to renewal — with practical tooling.

📑 Table of Contents

What Is SSL/TLS?
The TLS 1.3 Handshake
Certificate Types
Certificate Chain of Trust
OCSP & Revocation
HSTS — HTTP Strict Transport Security
Certbot & Automation
Best Practices
Common Mistakes
Tools
References

What Is SSL/TLS?

Transport Layer Security (TLS) — the successor to the deprecated SSL protocol — provides encryption,
authentication, and integrity for data transmitted between clients and servers. As of 2024, TLS 1.3
accounts for over 60% of all encrypted connections, with TLS 1.2 covering most of the remainder.
SSL 2.0 and 3.0 are considered insecure and must never be used.

📖 Definition — A digital certificate is a digitally signed document that binds a public key to an identity (domain, organization). It is issued by a Certificate Authority (CA) after validating ownership.

The TLS 1.3 Handshake

TLS 1.3 (defined in RFC 8446) reduces the handshake from two round-trips to just one (1-RTT),
and supports 0-RTT resumption for returning clients, dramatically reducing latency.

ClientHello — Client sends supported cipher suites, key shares (ECDHE), and a random nonce.

ServerHello — Server selects cipher suite, sends its key share, and the handshake is encrypted from this point.

Server Parameters & Certificate — Server sends encrypted extensions, its certificate, and a CertificateVerify signature.

Finished — Both sides derive session keys and exchange Finished messages. Application data flows immediately.

💡 TLS 1.3 removed insecure algorithms: RSA key exchange, CBC ciphers, SHA-1, RC4, DES, and 3DES are all gone. Only AEAD ciphers (AES-GCM, ChaCha20-Poly1305) remain.

Certificate Types

Type	Validation	Use Case	Issuance Time
DV Domain Validated	Domain ownership only	Blogs, personal sites, APIs	Minutes
OV Organization Validated	Domain + org identity	Business websites	1–3 days
EV Extended Validation	Rigorous legal/physical checks	Banks, e-commerce	1–2 weeks
Wildcard	Covers *.example.com	Multi-subdomain projects	Varies

⚠️ Wildcard certificates cover only one level of subdomain. *.example.com covers api.example.com but NOT v2.api.example.com.

Certificate Chain of Trust

A certificate chain links your server's leaf certificate to a trusted root CA via one or more
intermediate CAs. Browsers and OS trust stores contain root CAs; the server must send the intermediates.

Leaf Certificate  (your domain)
    ↓  signed by
Intermediate CA   (e.g., R3 — Let's Encrypt)
    ↓  signed by
Root CA           (e.g., ISRG Root X1 — in trust stores)

🚫 Never serve only the leaf certificate without intermediates. This causes "unable to verify the first certificate" errors in clients that don't have the intermediate cached.

OCSP & Revocation

When a private key is compromised, the certificate must be revoked. Two mechanisms exist:

CRL (Certificate Revocation List) — A downloadable list of revoked serial numbers. Can be large and slow.
OCSP (Online Certificate Status Protocol) — Real-time check against the CA. Preferred method.

⚡ Pro Tip: Enable OCSP Stapling on your server. The server fetches the OCSP response periodically and sends it during the TLS handshake, eliminating the client's need to contact the CA — improving privacy and performance.

# Nginx — enable OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

HSTS — HTTP Strict Transport Security

HSTS tells browsers to always use HTTPS for your domain, preventing protocol downgrade attacks and cookie hijacking.

# Nginx header
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

🎯 Submit your domain to the HSTS Preload List to have browsers enforce HTTPS before the first visit. Requires max-age ≥ 1 year, includeSubDomains, and preload.

Certbot & Automation

Certbot is the official ACME client from the EFF for obtaining and renewing free Let's Encrypt certificates.

# Install and obtain a certificate (Nginx)
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

# Auto-renewal (cron or systemd timer)
sudo certbot renew --dry-run

💡 Let's Encrypt certificates are valid for 90 days. Certbot's systemd timer renews at 60 days by default. Always test renewal with --dry-run first.

Best Practices

Use TLS 1.3 as the minimum version. Disable TLS 1.0 and 1.1 entirely.

Enable OCSP Stapling and configure a valid resolver.

Deploy HSTS with a long max-age and consider preloading.

Use ECDSA P-256 keys for better performance than RSA 2048.

Automate renewal — never let certificates expire manually.

Redirect all HTTP traffic to HTTPS with a 301 redirect.

Common Mistakes

Mistake	Impact	Fix
Missing intermediate certificate	Broken chain on some clients	Bundle intermediates in the cert file
Expired certificate	Browser security warnings, lost trust	Automate renewal with Certbot
Mixed content (HTTP resources on HTTPS page)	Browser blocks insecure resources	Use protocol-relative or HTTPS URLs
Allowing TLS 1.0/1.1	Vulnerable to POODLE, BEAST attacks	Set `ssl_protocols TLSv1.2 TLSv1.3;`
Weak cipher suites	Susceptible to brute-force or downgrade	Use Mozilla SSL Configuration Generator

Tools

Check your SSL/TLS configuration with our built-in checker:

🔧 SSL Certificate Checker — Verify certificate validity, chain, expiry, and protocol support.

References

📄 RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
📄 Let's Encrypt Documentation
📄 Mozilla Server Side TLS Guidelines
📄 Mozilla SSL Configuration Generator
📄 Certbot — EFF
📄 HSTS Preload List Submission

🎯 Key Takeaway: Modern TLS is non-negotiable. Use TLS 1.3 with AEAD ciphers, automate certificate management with Certbot,
serve the full certificate chain, enable OCSP Stapling, and enforce HTTPS via HSTS. A misconfigured certificate
erodes user trust faster than almost any other infrastructure issue.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

DNS Records: The Complete Reference Guide for Every Record Type

toolbox-poster — Sun, 12 Apr 2026 19:24:02 +0000

TL;DR
DNS (Domain Name System) translates human-readable domain names into IP addresses and service endpoints.
With over 1.1 trillion DNS queries handled daily worldwide, understanding every record type — from
the ubiquitous A record to specialized CAA and SRV entries — is fundamental to deploying, securing,
and troubleshooting any internet service. This reference covers all major record types with real-world examples.

📑 Table of Contents

How DNS Works
A & AAAA Records
CNAME Records
MX Records
TXT Records
NS & SOA Records
SRV Records
CAA Records
PTR Records
Understanding TTL
Best Practices
Common Mistakes
Tools
References

How DNS Works

A DNS query follows a hierarchical resolution path: your device's stub resolver asks a
recursive resolver (e.g., 1.1.1.1 or 8.8.8.8), which queries root servers,
then the TLD nameserver (.com, .org), and finally the domain's authoritative nameserver
to return the answer. Responses are cached at each level according to the record's TTL.

📖 Definition — A DNS record (Resource Record) is an entry in a zone file that maps a domain name to a specific value — an IP address, mail server, text string, or another domain name.

A & AAAA Records

The most fundamental record types. A records map a domain to an IPv4 address;
AAAA records map to an IPv6 address.

; A Record — IPv4
example.com.    300    IN    A      93.184.216.34

; AAAA Record — IPv6
example.com.    300    IN    AAAA   2606:2800:220:1:248:1893:25c8:1946

🎯 Always publish both A and AAAA records for dual-stack compatibility. IPv6 adoption crossed 40% globally in 2024.

CNAME Records

A CNAME (Canonical Name) record aliases one domain to another. The DNS resolver follows the chain
until it reaches an A/AAAA record.

www.example.com.    3600    IN    CNAME    example.com.
blog.example.com.   3600    IN    CNAME    myhost.github.io.

⚠️ A CNAME cannot coexist with any other record type at the same name (RFC 1034 §3.6.2). You cannot place a CNAME at the zone apex alongside SOA/NS records. Use ALIAS/ANAME (provider-specific) for apex domains.

MX Records

MX (Mail Exchanger) records direct email to the correct mail servers. The priority
value determines failover order — lower numbers are tried first.

example.com.    3600    IN    MX    10    mail1.example.com.
example.com.    3600    IN    MX    20    mail2.example.com.

Priority	Server	Role
10	mail1.example.com	Primary mail server
20	mail2.example.com	Backup mail server

TXT Records

TXT records store arbitrary text and are heavily used for email authentication, domain verification, and security policies.

; SPF — Authorize mail senders
example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

; DKIM — Email signature verification
selector._domainkey.example.com.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0G..."

; DMARC — Email policy
_dmarc.example.com.    3600    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

; Domain verification
example.com.    3600    IN    TXT    "google-site-verification=abc123..."

💡 A single domain can have multiple TXT records. However, only one SPF record is allowed per domain — multiple SPF records cause authentication failures (RFC 7208 §3.2).

NS & SOA Records

NS records delegate a zone to specific nameservers. SOA (Start of Authority) records
define the zone's primary nameserver, admin email, and serial/refresh/retry/expire timers.

; NS Records
example.com.    86400    IN    NS    ns1.provider.com.
example.com.    86400    IN    NS    ns2.provider.com.

; SOA Record
example.com.    3600    IN    SOA    ns1.provider.com. admin.example.com. (
                        2024031501  ; Serial
                        7200        ; Refresh (2h)
                        3600        ; Retry (1h)
                        1209600     ; Expire (14d)
                        86400       ; Minimum TTL (1d)
)

SRV Records

SRV records specify the host and port for specific services (e.g., SIP, XMPP, LDAP).

; _service._protocol.name    TTL    class    SRV    priority weight port target
_sip._tcp.example.com.    3600    IN    SRV    10 60 5060 sip1.example.com.
_sip._tcp.example.com.    3600    IN    SRV    10 40 5060 sip2.example.com.

💡 The weight field enables load balancing among servers with the same priority. Higher weight = more traffic share.

CAA Records

CAA (Certificate Authority Authorization, RFC 8659) records specify which CAs are permitted to issue
certificates for a domain — a critical security control.

example.com.    3600    IN    CAA    0 issue "letsencrypt.org"
example.com.    3600    IN    CAA    0 issuewild ";"
example.com.    3600    IN    CAA    0 iodef "mailto:security@example.com"

🎯 Use issuewild ";" to explicitly block wildcard certificate issuance if you don't need wildcards. The iodef tag notifies you of policy violations.

PTR Records

PTR (Pointer) records provide reverse DNS — mapping an IP address back to a domain name.
Essential for mail server reputation and network diagnostics.

; Reverse DNS for 93.184.216.34
34.216.184.93.in-addr.arpa.    3600    IN    PTR    example.com.

Understanding TTL

TTL Value	Duration	Use Case
60	1 minute	Failover, migrations, testing
300	5 minutes	Dynamic services, CDNs
3600	1 hour	Standard web records
86400	24 hours	Stable records (NS, MX)

⚡ Pro Tip: Before a planned DNS change, lower the TTL to 60–300 seconds at least 48 hours in advance (to let the old high TTL expire from caches). After the change propagates, raise TTL back to its normal value.

Best Practices

Publish both A and AAAA records for every public hostname.

Set CAA records to restrict certificate issuance to your chosen CA.

Configure SPF + DKIM + DMARC TXT records for every domain that sends email.

Use at least two geographically diverse NS records.

Set up PTR records for all mail server IPs.

Lower TTL before migrations, restore afterward.

Common Mistakes

Mistake	Impact	Fix
CNAME at zone apex	Broken NS/SOA coexistence	Use ALIAS/ANAME or A record
Multiple SPF TXT records	SPF PermError — email fails auth	Merge into one `v=spf1` record
Missing trailing dot in zone files	Relative name interpreted wrong	Always use FQDN with trailing dot
TTL too high before migration	Long propagation delays	Pre-lower TTL 48h before changes
No CAA records	Any CA can issue certs for your domain	Publish restrictive CAA records

Tools

Inspect and verify your DNS configuration:

🔧 DNS Lookup — Query A, AAAA, MX, NS, SOA, SRV, and other record types.
🔧 TXT Record Lookup — Inspect SPF, DKIM, DMARC, and verification records.
🔧 CNAME Lookup — Trace CNAME chains to their canonical target.

References

📄 RFC 1035 — Domain Names: Implementation and Specification
📄 RFC 8659 — DNS Certification Authority Authorization (CAA)
📄 RFC 7208 — Sender Policy Framework (SPF)
📄 RFC 2782 — A DNS RR for Specifying the Location of Services (SRV)
📄 Cloudflare DNS Documentation

🎯 Key Takeaway: DNS is the invisible foundation of every internet service. Master the record types — A/AAAA for addresses,
CNAME for aliases, MX for mail, TXT for authentication, CAA for certificate control, and SRV for service
discovery. Combine proper TTL management with email authentication (SPF/DKIM/DMARC) to build a secure,
resilient DNS configuration.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

HTTP Security Headers: The Complete Guide to Securing Your Website

toolbox-poster — Sun, 12 Apr 2026 19:23:52 +0000

TL;DR
HTTP security headers are your first line of defense against cross-site scripting (XSS), clickjacking,
MIME sniffing, and data injection attacks. Despite being simple response headers, a 2024 scan of the
top 1 million websites found that fewer than 12% deploy a Content Security Policy. This guide
covers every critical security header with production-ready Nginx and Apache configurations.

📑 Table of Contents

Why Security Headers Matter
Content Security Policy (CSP)
Strict-Transport-Security (HSTS)
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
Additional Useful Headers
Nginx & Apache Configuration
Best Practices
Common Mistakes
Tools
References

Why Security Headers Matter

Security headers instruct browsers on how to handle your content — which scripts can run,
whether your page can be framed, and what information is leaked in referrers. They cost nothing to deploy
and defend against entire categories of attacks identified in the OWASP Top 10.

📖 Definition — HTTP security headers are response headers sent by the server that activate browser-side security mechanisms, restricting behavior that could be exploited by attackers.

Content Security Policy (CSP)

CSP is the most powerful security header. It defines an allowlist of content sources, effectively neutralizing
XSS, data injection, and unauthorized inline scripts.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests;

Directive	Controls	Recommended Value
`default-src`	Fallback for all resource types	`'self'`
`script-src`	JavaScript sources	`'self'` + specific CDNs
`style-src`	CSS sources	`'self'` (avoid `'unsafe-inline'`)
`img-src`	Image sources	`'self' data: https:`
`frame-ancestors`	Who can embed your page	`'none'`
`base-uri`	Restricts `` element	`'self'`

🎯 Start with Content-Security-Policy-Report-Only to log violations without blocking. Use the report-uri or report-to directive to collect reports, then tighten the policy iteratively.

🚫 Never use 'unsafe-eval' in production CSP. It re-enables eval(), completely undermining XSS protection. Refactor code that calls eval(), new Function(), or inline event handlers.

Strict-Transport-Security (HSTS)

Forces browsers to connect over HTTPS only, preventing protocol downgrade attacks and SSL stripping.

`http Strict-Transport-Security: max-age=63072000; includeSubDomains; preload `

⚠️ Once HSTS is deployed with includeSubDomains, every subdomain must have a valid TLS certificate. Rolling this out without full HTTPS coverage will break subdomains.

X-Frame-Options

Prevents your page from being embedded in , , or
`` elements on other sites — blocking clickjacking attacks.

X-Frame-Options: DENY

Value	Behavior
DENY	Never allow framing (most secure)
SAMEORIGIN	Allow framing only from same origin

💡 CSP's frame-ancestors directive is the modern replacement for X-Frame-Options, offering more granular control. Deploy both for backward compatibility.

X-Content-Type-Options

Prevents browsers from MIME-sniffing a response away from the declared Content-Type.
Blocks attacks that disguise executable content as harmless file types.

X-Content-Type-Options: nosniff

Referrer-Policy

Controls how much referrer information is sent when navigating away from your site.

Referrer-Policy: strict-origin-when-cross-origin

Policy	Same-Origin	Cross-Origin (HTTPS→HTTPS)	Downgrade (HTTPS→HTTP)
`no-referrer`	None	None	None
`strict-origin`	Full URL	Origin only	None
`strict-origin-when-cross-origin`	Full URL	Origin only	None
`no-referrer-when-downgrade`	Full URL	Full URL	None

Permissions-Policy

Controls which browser features (camera, microphone, geolocation, etc.) your site and embedded iframes can use.
Formerly known as Feature-Policy.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(self), usb=()

⚡ Pro Tip: Set unused features to () (empty allowlist) to explicitly disable them. This prevents embedded third-party scripts from silently accessing sensitive APIs like the camera or microphone.

Additional Useful Headers

Header	Value	Purpose
`Cross-Origin-Opener-Policy`	`same-origin`	Isolates browsing context, enables SharedArrayBuffer
`Cross-Origin-Embedder-Policy`	`require-corp`	Ensures all embedded resources opt-in to being loaded
`Cross-Origin-Resource-Policy`	`same-origin`	Prevents other origins from loading your resources
`X-DNS-Prefetch-Control`	`off`	Prevents speculative DNS lookups (privacy)

Nginx & Apache Configuration

Nginx

# /etc/nginx/snippets/security-headers.conf
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self';" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Embedder-Policy "require-corp" always;

# Include in server block:
# include snippets/security-headers.conf;

Apache

# .htaccess or httpd.conf
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; frame-ancestors 'none';"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Best Practices

Deploy CSP in report-only mode first, analyze violations, then enforce.

Use nonce-based CSP ('nonce-{random}') instead of 'unsafe-inline' for inline scripts.

Add the always keyword in Nginx to send headers on all response codes (including 4xx/5xx).

Test headers in staging before production — overly strict CSP can break legitimate functionality.

Audit headers regularly with automated scanners as your site's dependencies evolve.

Common Mistakes

Mistake	Impact	Fix
Using `'unsafe-inline'` + `'unsafe-eval'` in CSP	Nullifies XSS protection	Use nonces or hashes instead
Missing `always` keyword in Nginx	Headers absent on error pages	Add `always` to every `add_header`
HSTS without full HTTPS coverage	Subdomains become unreachable	Ensure all subdomains have valid TLS certs first
Forgetting `frame-ancestors` in CSP	Clickjacking still possible	Add `frame-ancestors 'none'` to CSP
Setting `Referrer-Policy: unsafe-url`	Full URL leaked to third parties	Use `strict-origin-when-cross-origin`

Tools

Scan your website's security headers:

🔧 Security Header Scanner — Analyze all security headers and get an actionable report with grades.

References

📄 MDN — Content Security Policy (CSP)
📄 MDN — Strict-Transport-Security
📄 MDN — Permissions-Policy
📄 OWASP Secure Headers Project
📄 OWASP HTTP Headers Cheat Sheet
📄 MDN — Referrer-Policy

🎯 Key Takeaway: Security headers are free, high-impact defenses. At minimum, deploy CSP, HSTS, X-Frame-Options,
X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Start CSP in report-only mode,
iterate based on real violation reports, then enforce. Combine with a regular scanning cadence
to catch regressions as third-party dependencies change.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

DNS Propagation: How Long Does It Really Take? (With Technical Explanation)

toolbox-poster — Sun, 12 Apr 2026 19:23:43 +0000

TL;DR
DNS propagation — the time it takes for DNS changes to reach every resolver worldwide — is one of the most
misunderstood concepts in web operations. While changes can appear instant for some users, others may wait
up to 72 hours due to aggressive caching. Understanding the resolution flow, TTL mechanics, caching
layers, and pre-change strategies lets you execute DNS migrations with near-zero downtime.

📑 Table of Contents

What Is DNS Propagation?
The DNS Resolution Flow
TTL Mechanics & Caching
Caching Layers
Pre-Change Strategy
Anycast DNS
Real-World Propagation Timing
Best Practices
Common Mistakes
Tools
References

What Is DNS Propagation?

When you update a DNS record at your registrar or DNS provider, the change is immediately live on your
authoritative nameservers. However, recursive resolvers around the world have cached
the old record and will continue serving it until the cached entry's TTL expires. The gradual process of
every resolver picking up the new record is called DNS propagation.

📖 Definition — DNS propagation is not a push mechanism — there is no broadcast. Each recursive resolver independently expires its cache based on the TTL from the last response it received from the authoritative server.

The DNS Resolution Flow

Understanding the full resolution path explains why propagation takes time and where caching occurs.

Stub Resolver — Your device's OS-level resolver sends a query to the configured recursive resolver (e.g., your ISP, or 1.1.1.1 / 8.8.8.8).

Recursive Resolver — Checks its cache. If found and TTL hasn't expired, returns the cached answer immediately. If not, begins iterative resolution.

Root Servers — The recursive resolver queries one of the 13 root server clusters, which responds with the TLD nameserver (e.g., .com NS).

TLD Nameserver — Returns the authoritative NS records for the specific domain (e.g., ns1.provider.com).

Authoritative Nameserver — Returns the actual record (A, CNAME, MX, etc.) with its TTL. The recursive resolver caches this response.

Response to Client — The recursive resolver returns the answer to your device, which may also cache it locally.

💡 Each step in the chain can cache results. Root and TLD NS records are cached for long periods (often 48 hours), but your domain's records are cached according to their own TTL.

TTL Mechanics & Caching

TTL (Time To Live), defined in RFC 1035, is a 32-bit integer representing seconds. When a resolver
caches a record, it decrements the TTL over time. At zero, the entry is evicted and must be re-fetched.

; Example: A record with 1-hour TTL
example.com.    3600    IN    A    93.184.216.34

; After 2000 seconds, a resolver's cached copy has:
;   Remaining TTL = 3600 - 2000 = 1600 seconds

TTL (seconds)	Human Readable	Propagation Window
60	1 minute	~1–5 minutes globally
300	5 minutes	~5–15 minutes
3600	1 hour	~1–2 hours
86400	24 hours	~24–48 hours

⚠️ Some resolvers do not honor low TTLs. Certain ISP resolvers enforce a minimum TTL floor (commonly 300 seconds). RFC 2308 allows negative caching of NXDOMAIN responses for up to the SOA minimum TTL.

Caching Layers

DNS responses are cached at multiple levels, each with different eviction behavior:

Layer	Location	Cache Duration	Flushable?
Browser	Chrome, Firefox, etc.	Up to 60 seconds (Chrome)	Yes — `chrome://net-internals/#dns`
OS	Windows/macOS/Linux stub resolver	Varies (often honors TTL)	Yes — `ipconfig /flushdns`
Router/LAN	Home/office router, local DNS	Varies widely	Reboot router
ISP Resolver	ISP's recursive nameserver	Honors TTL (usually)	No — must wait for expiry
Public Resolver	1.1.1.1, 8.8.8.8, 9.9.9.9	Strictly honors TTL	Cloudflare: purge cache tool

⚡ Pro Tip: During a migration, test from multiple resolvers. Use dig @1.1.1.1, dig @8.8.8.8, and dig @9.9.9.9 to see whether major public resolvers have picked up the change. Your ISP's resolver may lag behind.

Pre-Change Strategy

The single most important technique for fast, smooth DNS changes is TTL pre-lowering.

48 hours before — Lower the TTL on the record you plan to change to 60–300 seconds. Wait for the old high TTL to expire from all caches.

Make the change — Update the DNS record to its new value. Because the TTL is now low, caches expire quickly.

Verify propagation — Use a global DNS checker to confirm the new value is seen from multiple locations worldwide.

After confirmation — Raise the TTL back to its normal production value (e.g., 3600 or 86400).

# Step 1: Lower TTL (48h before migration)
example.com.    60    IN    A    93.184.216.34    ; was 86400

# Step 2: Change record (migration day)
example.com.    60    IN    A    104.21.45.67     ; new server

# Step 3: After propagation confirmed, restore TTL
example.com.    3600  IN    A    104.21.45.67

🚫 Never skip the TTL pre-lowering step. If your record has a 24-hour TTL and you change it without lowering first, some users will be stuck on the old IP for up to 48 hours.

Anycast DNS

Anycast is a routing technique where the same IP address is announced from multiple geographic
locations. DNS providers like Cloudflare, Route 53, and Google Cloud DNS use anycast to route queries to
the nearest server, reducing latency and improving redundancy.

💡 Anycast means two users in different countries querying the same resolver IP (e.g., 1.1.1.1) may hit different physical servers with different cache states. This is why propagation appears inconsistent across regions.

Real-World Propagation Timing

Change Type	Typical Duration	Worst Case
A/AAAA record (low TTL pre-set)	1–10 minutes	30 minutes
A/AAAA record (high TTL, no prep)	4–24 hours	72 hours
NS record change (registrar)	12–24 hours	48 hours
New domain (fresh registration)	Minutes–2 hours	24 hours
MX record change	Follows TTL	TTL + resolver floor

🎯 For zero-downtime migrations, keep the old server running until propagation completes. Both old and new servers should serve valid responses during the transition window.

Best Practices

Always pre-lower TTL 48 hours before any DNS change.

Keep old infrastructure running in parallel during the propagation window.

Use public resolvers (1.1.1.1, 8.8.8.8) for testing — they strictly honor TTLs.

Monitor propagation from multiple geographic locations, not just your local machine.

Use anycast DNS providers for lower query latency and faster cache refresh across regions.

Document your rollback plan before changing DNS — know the old values and how to revert.

Common Mistakes

Mistake	Impact	Fix
Not lowering TTL before migration	Hours of stale DNS for some users	Pre-lower to 60s, wait 48h, then change
Shutting down old server immediately	Downtime for users still resolving old IP	Keep old server live for 2× the old TTL
Testing only from local machine	Local cache gives false positive	Flush local cache + test from multiple resolvers
Forgetting to restore TTL after change	Excessive queries to authoritative server, slower resolution	Raise TTL back to 3600+ after propagation
Ignoring negative caching (RFC 2308)	Deleted records linger as NXDOMAIN in caches	Pre-create records before pointing traffic

Tools

Monitor and verify your DNS propagation in real time:

🔧 DNS Lookup — Query any record type against specific resolvers.
🔧 Global DNS Checker — Verify propagation status from 20+ worldwide locations simultaneously.

References

📄 RFC 1035 — Domain Names: Implementation and Specification
📄 RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE)
📄 Cloudflare — DNS Record Types
📄 Cloudflare — What Is DNS Propagation?
📄 Cloudflare — Purge 1.1.1.1 Cache

🎯 Key Takeaway: DNS propagation is not magic — it's cache expiration. The single most effective technique is
TTL pre-lowering: drop the TTL to 60 seconds 48 hours before your change, make the update,
verify globally, then restore the TTL. Keep old infrastructure running during the transition window
and always test from multiple geographic vantage points, not just your local machine.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

IP Geolocation: How It Works and Its Accuracy Limits

toolbox-poster — Sun, 12 Apr 2026 19:23:30 +0000

TL;DR

privacy regulations, and never treat IP coordinates as precise physical locations. and postal code levels. Always layer multiple data sources, keep databases updated, respect

IP geolocation delivers reliable country-level accuracy (~99%) but degrades rapidly at city
🎯 Key Takeaway: 📄 GDPR Article 6 — Lawfulness of Processing 📄 IP2Location — Data Accuracy 📄 IPinfo — Accuracy & Methodology 📄 ARIN — Whois-RWS Service 📄 RIPE NCC — RIPE Database 📄 MaxMind — GeoIP2 Databases & GeoLite2References

🌍 [Geo Checker](https://toolbox.starnomina.tn/tools/geo-checker) — Verify geographic location data for IP addresses in bulk.

🔍 IP Address Lookup — Resolve any IP to its geolocation, ISP, and ASN.

Tools

Using geolocation for fraud detection alone: Combine with device fingerprinting and behavioral signals. Stale databases: IP reallocations happen constantly; outdated data degrades fast. Ignoring IPv6: Many databases have weaker IPv6 coverage — test both protocols. Blocking users by country without appeal: CGNAT and VPNs cause false positives in geo-blocking. Trusting coordinates as exact: The lat/lng is typically a city centroid, not a street address.

Common Mistakes

Implement fallback logic for unresolvable IPs (private ranges, CGNAT). Update your local database at least biweekly to keep accuracy current. Use the GeoLite2 free database locally before paying for API calls. Combine IP geolocation with user-selected locale for content personalization. Always validate country-level data before trusting city-level results.
(weekly at most). This reduces API costs and latency.

Cache geolocation results aggressively — IP-to-location mappings change infrequently

⚡ Pro Tip: Best Practices Right to object: Allow users to opt out of location-based personalization. Transparency: Disclose IP-based geolocation in your privacy policy. Retention limits: Delete raw IP logs within a defined retention period. Data minimization: Store only country/region if city-level precision isn't required. Legal basis: Use legitimate interest (Art. 6(1)(f)) or consent for geolocation processing. Key compliance points: Under GDPR, an IP address is considered personal data when it can be linked to an individual.Privacy & GDPR Considerations
in client-side JavaScript.
💡 Always keep API tokens in environment variables or a secrets manager — never hardcode them
geolocate('8.8.8.8').then(console.log);// Usage} }; org: data.org, // ASN + ISP name loc: data.loc, // "lat,lng" country: data.country, region: data.region, city: data.city, return { const data = await res.json(); if (!res.ok) throw new Error(\

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

Domain Security Audit: The Complete Checklist for 2026

toolbox-poster — Sun, 12 Apr 2026 19:23:21 +0000

TL;DR
A domain security audit reviews DNS configuration, email authentication, SSL/TLS certificates,
and HTTP security headers to identify vulnerabilities before attackers do. This 2026 checklist
provides structured tables, a quarterly schedule, and a scoring system so you can track
your domain's security posture over time.

📑 Table of Contents

Why Domain Audits Matter in 2026
DNS Configuration Checklist
Email Authentication Checklist
SSL/TLS Certificate Checklist
Security Headers Checklist
Scoring System
Quarterly Audit Schedule
Best Practices
Common Mistakes
Tools
References

Why Domain Audits Matter in 2026

Google and Yahoo enforce strict sender requirements as of 2024, browsers flag mixed content and
missing headers, and attackers increasingly exploit DNS misconfigurations for subdomain takeover.
A quarterly audit catches drift before it becomes a breach.

💡 Organizations with regular domain audits detect misconfigurations 4× faster than those
relying on incident-driven reviews (Verizon DBIR 2025).

DNS Configuration Checklist

Check	Expected State	Tool	Risk if Missing
A / AAAA records resolve	Valid IPs, no dangling CNAMEs	DNS Lookup	Subdomain takeover
CNAME records valid	All targets resolve	CNAME Lookup	Subdomain takeover
TXT records clean	No stale verification tokens	TXT Lookup	Information leakage
DNSSEC enabled	DS record in parent, signatures valid	DNS Checker	DNS spoofing
CAA record set	Restrict CAs to authorized issuers	DNS Lookup	Rogue certificates
NS records consistent	All NS respond identically	DNS Checker	Resolution failures
Low TTL audit	No production records below 300s without reason	DNS Lookup	Performance impact

Email Authentication Checklist

Check	Expected State	Tool	Risk if Missing
SPF record exists	Single `v=spf1` record, ≤10 DNS lookups	SPF Checker	Spoofing / delivery failure
DKIM selector valid	RSA ≥ 2048-bit or Ed25519, rotated annually	DKIM Checker	Message tampering
DMARC policy	`p=reject` or `p=quarantine`; `rua` tag set	DMARC Checker	Domain impersonation
BIMI record	Valid SVG logo, VMC certificate (optional)	BIMI Checker	Missed brand visibility
MTA-STS policy	`mode: enforce` with valid `mta-sts.txt`	TXT Lookup	Downgrade attacks
TLS-RPT record	`v=TLSRPTv1; rua=mailto:...`	TXT Lookup	No TLS failure visibility

SSL/TLS Certificate Checklist

Check	Expected State	Tool	Risk if Missing
Certificate valid	Not expired, covers all subdomains	SSL Checker	Browser warnings / MITM
TLS version	TLS 1.2+ only; TLS 1.0/1.1 disabled	SSL Checker	Protocol downgrade
Certificate chain	Complete chain served, no missing intermediates	SSL Checker	Mobile trust failures
HSTS header	`max-age ≥ 31536000; includeSubDomains; preload`	Security Scanner	SSL stripping
OCSP stapling	Enabled on server	SSL Checker	Revocation check delays
CT logs	Certificate in public transparency logs	SSL Checker	Rogue cert detection gap

Security Headers Checklist

Header	Recommended Value	Tool
`Content-Security-Policy`	Restrictive `default-src 'self'` with explicit exceptions	Security Scanner
`X-Content-Type-Options`	`nosniff`	Security Scanner
`X-Frame-Options`	`DENY` or `SAMEORIGIN`	Security Scanner
`Referrer-Policy`	`strict-origin-when-cross-origin`	Security Scanner
`Permissions-Policy`	Restrict camera, microphone, geolocation	Security Scanner
`Cross-Origin-Opener-Policy`	`same-origin`	Security Scanner

Scoring System

📖 Definition — Each checklist item earns points. Total your score and compare
against the rating thresholds to gauge your domain's security health.

Category	Max Points	Weight
DNS Configuration	20	20%
Email Authentication	30	30%
SSL/TLS	25	25%
Security Headers	25	25%

Rating thresholds:

90–100 — Excellent: production-ready
70–89 — Good: minor improvements needed
50–69 — Fair: significant gaps exist
0–49 — Critical: immediate remediation required

Quarterly Audit Schedule

Q1 — January
Full audit of all four categories. Renew expiring certificates.
Review DKIM key rotation. Update DMARC policy toward p=reject.

Q2 — April
DNS hygiene sweep: remove stale records, check for dangling
CNAMEs, verify DNSSEC signatures. Review CAA records.

Q3 — July
Email deliverability review: analyze DMARC aggregate reports,
check SPF lookup count, verify BIMI rendering. Test MTA-STS.

Q4 — October
Security header hardening: test CSP in report-only mode,
add new headers, review Permissions-Policy. Pre-renewal SSL check.

Best Practices

⚡ Pro Tip: Automate your audits with CI/CD checks. Run DNS and header validations on every deployment
to catch regressions before they reach production.

Document your baseline score and track improvement quarter over quarter.
Use p=none DMARC only during initial monitoring — escalate to quarantine then reject.
Set calendar reminders 30 days before certificate expiry.
Maintain an inventory of all subdomains including third-party services.
Test security headers with report-only mode before enforcing.

Common Mistakes

Dangling CNAME records: Decommissioned services with active DNS entries invite subdomain takeover.
Multiple SPF records: Only one v=spf1 TXT record is allowed per domain.
Wildcard certificates without monitoring: A compromised wildcard key exposes all subdomains.
HSTS without testing: A misconfigured HSTS header with preload is extremely difficult to undo.
Ignoring DMARC reports: Publishing rua without reading reports defeats the purpose.
Forgetting non-sending domains: Domains that don't send email still need v=spf1 -all and p=reject.

Tools

🔍 DNS Lookup — Query A, AAAA, MX, NS, TXT, and other DNS record types.

✉️ SPF Checker — Validate SPF records and count DNS lookups.

🔑 DKIM Checker — Verify DKIM selectors and key strength.

🛡️ DMARC Checker — Analyze DMARC policy and reporting tags.

🏷️ BIMI Checker — Validate BIMI records and logo format.

🔒 SSL Checker — Inspect certificate chain, expiry, and TLS config.

🛡️ Security Scanner — Audit HTTP security headers.

🔗 CNAME Lookup — Resolve CNAME chains to detect dangling records.

📝 TXT Lookup — Retrieve all TXT records for a domain.

🌐 DNS Checker — Global DNS propagation and DNSSEC validation.

References

📄 Google — Email sender guidelines (2024)
📄 Yahoo — Sender Requirements
📄 Qualys SSL Labs — SSL Server Test
📄 Security Headers — Analysis Tool
📄 RFC 8461 — MTA-STS
📄 RFC 8460 — TLS Reporting (TLSRPT)

🎯 Key Takeaway: A domain security audit is not a one-time event — it's a recurring discipline. Use the
quarterly schedule and scoring system above to track progress. Prioritize email authentication
and SSL/TLS first, as these have the highest impact on both security and deliverability.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.