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;

🎯 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

💡 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

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

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

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.

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.

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

⚡ 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

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.

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

⚠️ 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

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.

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"

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

Minimal Valid SVG Tiny PS Template

`plaintext

Example Corp Logo

E

`

🚫 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

💡 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

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.

🎯 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:

💡 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

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.

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

⚠️ 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:

⚡ 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

🎯 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

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.