The Campaign Domain Expired. Why Did Every Campaign Link Break at Once?

Answer First

Definition: Campaign domain expiration is what happens when the registered parent domain that backs one or more branded subdomain forwarding entries passes its renewal date without being renewed. The registration lapses, and the domain stops functioning as the base of those URLs — not just one link, but every link that lives underneath it.

Why: Every subdomain entry — spring-sale.example.com forwarding to a campaign landing page — resolves only because the parent domain (example.com) is still registered and its zone is still delegated in DNS. Entry consoles and dashboards show you the state of the entry: its target, its status, its redirect type, its click stats. They do not show you the state of the parent registration, because that data lives in a registrar account the console never touches. So when the parent expires, DNS stops resolving the whole subdomain at once. It isn’t a broken CNAME and it isn’t a dead landing page — the base of the URL itself has stopped existing. And if nobody catches it in time, the domain can enter redemption or get resold to someone else.

Example: A marketing team runs summer2025.example.com as a campaign subdomain entry pointing at a landing page. The parent domain’s auto-renewal was switched off years ago by an agency that set the account up, and the expiry date sits in a registrar inbox nobody checks. The renewal date passes on a Friday. By Monday, every campaign link returns a resolution error at the same time — on billboards, in emails, in ad creative. The CNAME is intact. The landing page is up. But example.com’s registration lapsed, so the entire zone is gone. Whether they recover it depends entirely on where the domain is in its post-expiry lifecycle, and how fast the team can find the right registrar account.

The short answer: subdomain entries are only as alive as the parent domain’s registration, and that registration is tracked in a system your entry tooling never sees. This article covers the registration lifecycle you need to track alongside your entries, how an expired parent differs from a broken CNAME or a dead destination, and what to verify before and after renewal so your entries come back cleanly.

Key Facts

• Every entry inherits the parent’s registration fate. A subdomain entry resolves through a chain of delegated zones; when the parent registration lapses, the whole chain fails (RFC 1034 defines how zones are delegated and served).
• Entry consoles never surface registrar state. Expiry date, auto-renewal status, and account ownership live in the registrar portal — outside the entry-ops boundary of a Console or API.
• Expiry is a process, not an instant. After the renewal date, domains move through phases — auto-renew grace, redemption, pending delete, then release — each with its own rules (ICANN status codes).
• Failure looks identical to a “broken link” but is not fixable in the entry layer. No record edit brings a lapsed registration back.
• After deletion, the name can be re-registered by anyone. Recovery is impossible once the domain is purged and released.

The post-expiry lifecycle at a glance

Phase	Typical window	What happens	Can you renew?
Active registration	Until the expiry date	DNS resolves normally	Yes, anytime
Auto-renew grace	Registrar-dependent (often weeks)	Registrar may auto-renew or hold the name; DNS often still resolving	Yes — usually at normal renewal price
Redemption (redemptionPeriod)	30 days for gTLDs per ICANN	Name held at the registry; no longer serving normally	Only via registrar restore, with extra fees
Pending delete	Short purge window (ICANN: five calendar days after redemption ends, then purged)	Name being deleted from the registry	No
Released / re-registered	After purge	Available to anyone	Only as a brand-new registration

Windows vary by registrar and TLD — country-code TLDs in particular differ from gTLDs. The ICANN figures above describe the gTLD status-code lifecycle; always confirm your registrar’s published policy.

Expert Explanation

The dependency your entry console never shows

A branded subdomain entry works like this: a visitor requests summer2025.example.com, the resolver walks the DNS hierarchy to find the name servers that are authoritative for example.com, and those servers answer for the subdomain record that holds your forwarding configuration. The entry is a record inside the parent’s zone. PushULink-style entry tooling manages that layer — the subdomain forwarding entry, its status, access statistics, logs, and change history — through a Console and OpenAPI. What the entry layer does not contain is the parent registration itself: who holds the registrar account, whether auto-renewal is on, when the domain expires, and what happens after.

That separation is the trap. A subdomain entry can be perfectly configured, healthy, and heavily trafficked, and still die the moment the parent registration lapses — because the zone that contains the entry no longer exists in the registry. Nothing in the entry console can detect this in advance, because the relevant data was never part of the entry. The console shows you the state of the entry; the registrar account shows you the state of the domain. You have to track both.

The registration lifecycle to track alongside entries

For every parent domain that backs entries, your ops team needs four answers:

1. Who holds the registrar account? Whose login, whose payment method, which agency or contractor set it up? A domain registered under a former agency’s account is an expiry waiting to happen.
2. Is auto-renewal on, and is the payment method valid? A lapsed card defeats auto-renewal silently.
3. What is the exact expiry date? Not “sometime in Q3” — the date, in a calendar the entry team can see.
4. What does this registrar do after expiry? Grace length, redemption restore process and fees, and whether DNS keeps resolving during grace all vary by registrar.

When a domain is past its expiry date, its status changes in the registration data. The ICANN EPP status codes page is the authoritative plain-language reference: redemptionPeriod means the registrar asked the registry to delete the name and it is held for 30 days, after which a short purge window leads to deletion; pendingDelete means the restore window has closed; clientHold and serverHold mean the name is not activated in the DNS and will not resolve. You can check current status codes and expiry dates for any name with RDAP or WHOIS — ICANN Lookup is the official entry point for registration data across registries and registrars.

Expired parent vs. broken CNAME vs. dead destination

These three failure modes look identical in a browser and are fixed in completely different places:

• Broken entry configuration: DNS resolves, but the entry points at the wrong host, a loop, or a non-existent record. Fix it in your entry tooling or DNS.
• Dead destination: the entry is fine — requests arrive, logs show hits — but the landing page 404s or the server is offline. Fix the destination. If you’re chasing an attribution or conversion problem, the redirect chain itself is worth checking before touching the ads (how to audit the redirect chain, and why a changed landing page confuses the whole setup (what to do when the approved landing page changed)).
• Expired parent domain: resolution fails before any of the above can even run. dig or nslookup the subdomain and you’ll get no usable answer or an error; the RDAP/WHOIS record shows a post-expiry status or the name is gone entirely.

The rule of thumb: if the entry looks right, the destination is up, and the link still dies — check the registration before you rebuild anything. Teams that skip this step rewrite ads and rebuild entries while the actual cause, a lapsed domain, keeps every old link dead (check the entry before rewriting the campaign).

Practical limits

Be honest about what tooling can and can’t do here. An entry-management platform records what happened at the entry layer: when status flipped, what traffic stopped, what the logs show, and who changed what — which is exactly the evidence you need to reconstruct the outage timeline and, if needed, support an audit trail. It cannot see the registrar. There is no console that renews a domain for you, and no entry status that warns you a registration is about to lapse — so build the tracking yourself: a shared calendar of expiry dates, a named owner for each registrar account, and a review cadence.

Also note that renewal is not instant restoration. After the domain comes back, DNS delegation must repopulate, and any certificates for the subdomains may have expired during the outage. Expect propagation delay and verify TLS before reopening links at scale.

Decision Framework

When a campaign link dies and you suspect the domain, triage in this order:

1. Is it the entry? Check the entry’s status and logs in the Console. If the record is healthy and recent traffic is visible, the entry is not the blocker.
2. Is it the destination? Open the target URL directly. If it loads, the destination is fine.
3. Is it the registration? Query RDAP/WHOIS for the parent domain. Status codes like redemptionPeriod or a missing record confirm the diagnosis.

Then choose a path:

• Renew: You can log into the registrar account and the domain is in grace — renew immediately, confirm the new expiry date in the registration data, then verify DNS and certificates.
• Restore: The domain is in redemption. The registrar must restore it at the registry; expect a higher fee and a time window measured in days, not hours.
• Rebuild: The domain is purged or re-registered. Old URLs are gone. Create fresh subdomain entries on a domain you control, update every campaign link, and keep the surviving domain’s entries consolidated so the next inventory is painless (consolidating entries across domains and teams).
• Cut losses: A campaign-specific domain with no long-term value may not be worth a restore fee. Rebuild instead of paying to rescue a name you don’t need.

Pre- and post-renewal checklist

Before renewal (or before expiry — ideally 30+ days out):

• Confirm which registrar account and whose credentials hold the parent domain
• Check auto-renewal is enabled and the payment method is valid
• Record the expiry date in a shared calendar the entry team can see
• Verify current status via RDAP/WHOIS and note any post-expiry codes
• Inventory every subdomain entry that depends on this parent

After renewal:

• Confirm the registration is renewed and the expiry date moved forward (registrar + RDAP)
• Confirm the parent domain and a sample of subdomains resolve again
• Verify certificates for each subdomain — they don’t heal themselves
• Test each entry end-to-end in the Console; confirm logs show the redirect chain completing
• Re-check status codes for any residual hold that keeps DNS offline

Key Takeaways

• Every subdomain entry silently depends on the parent domain’s registration — one lapse breaks every campaign link at once, with no warning from the entry layer.
• Entry consoles show entry state, never registrar state. Track the registrar account holder, auto-renewal status, expiry date, and redemption window in a separate system your entry team owns.
• Distinguish the failure modes: expired parent (resolution fails; RDAP shows redemptionPeriod/pendingDelete), broken CNAME (resolves to the wrong target), dead destination (entry healthy, page gone).
• In redemption, recovery is usually possible but costs more and requires registrar action; after pending delete the name can be resold and the URLs are gone.
• Verify before and after renewal — DNS and certificates don’t restore themselves. Test entries end-to-end once the domain is back.

FAQ

What is campaign domain expiration? It’s when the parent domain that backs a campaign’s subdomain forwarding entries passes its renewal date without being renewed. Because the entries resolve through the parent’s zone, all of them fail at once.

Why do links break when the entry’s DNS records are untouched? The entry’s records live inside the parent’s zone. When the registration lapses, that zone disappears and no authority remains to serve the records — even though the records themselves were never changed.

How is the redemption period different from the grace period? Grace is a registrar-controlled window where normal (cheap) renewal is usually still possible and DNS often keeps working. Redemption is a registry-level hold — 30 days for gTLDs per ICANN — where the name must be restored through the registrar at a higher cost, then a short pending-delete window precedes permanent deletion.

Can we recover a domain that already expired? In redemption, usually yes, via registrar restore with extra fees. After the name is purged and released, anyone can register it, so the old URLs can’t be recovered — rebuild the entries on a domain you control.

Sources

• ICANN, “EPP Status Codes: What Do They Mean, and Why Should I Know?” — the plain-language reference for post-expiry statuses including redemptionPeriod, pendingDelete, and hold codes: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en
• ICANN Lookup — registration data lookup (RDAP) for checking expiry dates and status codes: https://lookup.icann.org/
• P. Mockapetris, RFC 1034, “Domain Names — Concepts and Facilities” — zones, delegation, and authoritative name servers: https://www.rfc-editor.org/rfc/rfc1034
• R. Fielding et al., RFC 9110, “HTTP Semantics” — the redirect status codes (301/302/307/308) that forwarding entries rely on: https://www.rfc-editor.org/rfc/rfc9110
• MDN Web Docs, “Redirections in HTTP” — how redirects work and why redirect chains matter: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections