Posted in

DNS TTL Definition: Why DNS Changes Take Time to Propagate

DNS TTL determines how long a DNS record can be cached before a resolver should retrieve a fresh version.

TTL means Time to Live, and it is one of the main reasons a DNS change may not appear everywhere immediately.

How does DNS TTL work?

Suppose your website currently points to:

192.0.2.10

Your A record has a DNS TTL of 3600 seconds, or one hour.

A recursive resolver looks up the domain and caches the answer. Ten minutes later, you change the record to a different IP address.

That resolver may continue returning its cached answer until the record’s remaining TTL expires. Once it needs the record again, it can request the newer value.

Longer TTL values can improve caching efficiency, while shorter TTL values allow changes to become visible more quickly.

Is that DNS propagation?

What people call DNS propagation is often really a collection of caches around the internet expiring at different times.

There isn’t a giant DNS update being pushed simultaneously to every computer on Earth.

Different resolvers may have cached the old record at different times, so one person might see your new server while another temporarily sees the old one.

Should you always use a low DNS TTL?

Not necessarily.

Lower TTL values mean resolvers need to request fresh answers more frequently. Higher TTL values provide more caching but make planned changes slower to appear.

For an upcoming migration, administrators often reduce the DNS TTL beforehand so cached records expire sooner. Once the migration is stable, the TTL can be increased again.

You should also remember that local caches and provider-specific behavior can affect exactly when you observe a change.

So the next time someone says, “The DNS hasn’t propagated yet,” check the TTL.

Very often, DNS isn’t broken.

It’s simply doing exactly what the cache was told to do.

Posted in

BIMI Explained

BIMI is an email standard that can allow your organization’s verified brand logo to appear beside authenticated emails in supporting inboxes.

BIMI stands for Brand Indicators for Message Identification. Instead of simply telling an email provider who sent a message, it adds a visual identity to authenticated email by giving participating mailbox providers a published brand logo they can display.

How does BIMI work?

It relies heavily on email authentication.

Before implementing it, a domain should have SPF, DKIM and DMARC correctly configured and aligned. DMARC must be operating at enforcement, using p=quarantine or p=reject, with the policy applied to 100% of messages.

Next comes the logo. Your organization prepares its logo using the required SVG format and publishes a DNS TXT record.

A simplified record lives under a name such as:

default._bimi.example.com

The record tells supporting email providers where the approved logo can be found.

What about VMC and CMC certificates?

You may also need a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). These provide additional verification around the logo being displayed. Requirements vary between mailbox providers, and publishing a BIMI record does not guarantee that every inbox will show your logo.

Is BIMI a security feature?

Not exactly.

BIMI itself isn’t intended to replace email security. Its value comes partly from requiring strong authentication mechanisms such as DMARC before a brand becomes eligible.

Think of it as the visible layer at the end of a properly authenticated email setup.

If SPF, DKIM, and DMARC are the security team checking your identity at the door, BIMI is the name badge you get once you’ve made it inside.