Sådan mister man et kundedomæne — og hvordan I undgår det

Domæner forsvinder sjældent fordi nogen aktivt vælger at lade dem udløbe. De forsvinder fordi en e-mail blev sendt til den forkerte indbakke, fordi et betalingskort udløb i mellemtiden, eller fordi en ACME-renewal stoppede med at virke uden at give besked. Her er tre realistiske scenarier vi har set hos bureauer det sidste år, og hvordan I kan fange dem inden de eskalerer.

1. Reminder-mailen røg til en ex-medarbejder

Det klassiske: en kunde købte deres domæne tilbage i 2017 igennem jeres tidligere webudvikler, som registrerede det i hans eget navn. Han stoppede i 2020. Registraren sender renewal-reminders 30, 14 og 3 dage før udløb, men de ryger alle til hans gamle private mailadresse, som ikke længere bliver checket.

Resultatet: domænet udløber, ryger i en quarantine-periode på 30-90 dage afhængigt af TLD, og kommer derefter til salg på et drop-marked. Hvis det er et kort, mindeværdigt domæne, bliver det opfanget af en domain squatter inden for timer. Jeres kunde får så at vide, at de kan købe deres eget domæne tilbage for 8.000 USD.

Sådan fanger I det: overvåg WHOIS-udløbsdato på alle domæner I administrerer, uanset hvis konto de teknisk er registreret på. Når et domæne nærmer sig 60-90 dages udløb, så åbn en aktiv samtale med kunden om at flytte registreringen til en konto I kontrollerer, eller bekræft at den nuværende ejer modtager reminders.

2. SSL-fornyelsen kører — bortset fra at den ikke gør

ACME (Let's Encrypt og lignende) er fantastisk når det virker. Når det stopper med at virke, gør det det ofte stille. Et certifikat har 90 dages gyldighed, og certbot prøver typisk at forny 30 dage før udløb. Hvis det fejler, prøver det igen næste dag. Og næste dag. Og næste dag.

Hvad får det til at fejle? Tit en ændring der ikke umiddelbart ser ud til at ramme TLS:

• Kunden har skiftet hosting, og DNS A-record peger ikke længere på den server hvor ACME-challengen valideres.
• En Apache-config-ændring brød den HTTP-01 challenge-path.
• Cloudflare blev sat i "always-use-https"-mode, hvilket redirecter ACME-challengen før den bliver besvaret.
• Rate-limit fra Let's Encrypt (5 fejlede forsøg på 1 time blokerer 12 timer; mange tror det er permanent fejl).

Resultatet: certifikatet udløber, sitet bliver utilgængeligt på en søndag aften, og kunden ringer mandag morgen kl. 07:30.

Sådan fanger I det: overvåg den faktiske NotAfter-dato på SSL-certifikatet for hvert domæne. Det er det eneste der fortæller jer sandheden — certbot's egne logs vil typisk sige "renewal scheduled for next attempt" og lader jer i den tro at alt er fint. Et stykke værktøj der hver nat åbner en TLS-forbindelse og læser certifikatets udløbsdato, vil fange problemet 30+ dage før hjemmesiden går ned.

3. DNS blev ændret af "nogen" — og I opdagede det tre dage senere

En kunde havde tre forskellige leverandører rørende ved deres DNS: jer, deres egen IT-afdeling og en gammel mailhåndtering der havde fået adgang for at sætte DKIM op. På et tidspunkt fjernede én af dem en TXT-record som indeholdt SPF-konfigurationen. Mail begyndte at lande i spam hos modtagere som havde streng SPF-håndhævelse.

Det blev opdaget tre dage senere da en sælger ringede og spurgte hvorfor ingen modtog hans tilbud. Det er to-tre dage med tabte leads.

Det her sker ofte med:

• SPF/DKIM/DMARC-records — usynlige ændringer der først rammer mail-deliverability.
• NS-records — en migration der "næsten" lykkedes, hvor en NS-server blev efterladt aktiv og svarer med stale data.
• MX-records — fx en kunde der prøvede at lægge mail om til Microsoft 365 og endte med at brække den eksisterende setup.

Sådan fanger I det: tag et dagligt snapshot af NS, A, MX og TXT-records på alle kundedomæner. Når noget ændrer sig, så få en notifikation. Det betyder ikke at hver ændring er et problem (kunden har måske selv lavet den med vilje), men det betyder at I ved hvornår det skete, og I kan stille spørgsmålet inden mail-deliverability er ødelagt i en uge.

Det fælles princip

Alle tre scenarier handler om det samme: noget der ændrer sig under vandet, hvor den eneste advarsel I får er et ringende kundenummer. Den tekniske løsning er ikke kompliceret — det er bare et spørgsmål om at have en process der dagligt kigger på de tre kontroller, og som siger til når noget ser anderledes ud end i går.

Det kan I bygge selv med cron, openssl, dig og en lille script-samling. Det tager en eftermiddag at få op at køre, og to dage om året i vedligehold.

Eller I kan lade nogen andre passe på det. Det er det vi laver.