Transaktionsmail der lander: DNS, templates og ejerskab

En transaktionsmail, der ikke lander, er ikke et designproblem. Det er et brudt produkt. Kunden kan ikke komme ind. De kan ikke se kvitteringen. De tror, I aldrig svarede på bookingen. Support får den samme sag, I allerede 'har sendt'. I har ikke et mail-problem. I har et tillidsproblem, I måler som tickets.

Teams reagerer forkert. De skriver om emnelinjen. De tilføjer et logo. De skifter fra én 'smart' udbyder til en anden med samme manglende DNS. De slår et marketing-værktøj til på samme From, fordi 'så har vi alt ét sted'. Indbakker slår ikke op i jeres Figma. De slår op i om I må sende som det navn, I påstår.

Det er også et auth- og billing-spørgsmål. Magic link og reset er døren ind. Faktura og kvittering er døren til 'I skylder' og 'I har betalt'. Hvis Stripe sender den ene, og I sender den anden fra et andet domæne, der ikke kan underskrives, har kunden to afsendere og én tvivl. Billing-modellen kan være rigtig, og mailen kan stadig være løgnen i kæden.

Vi skriver det, fordi 'email rammer spam' er blevet et værktøjskøb oven på den samme zone. Et ærligt setup er kedeligt: I ved hvilket domæne der står i From, hvilke nøgler der underskriver, hvad der sker ved bounce, og hvilke mails I slet ikke skal sende fordi Stripe eller auth-leverandøren allerede gør det. Uden den sætning har I en skabelon. I har ikke levering, I kan forsvare.

Transaktionsmail er en mail, produktet skylder brugeren fordi de gjorde noget, eller fordi I skylder dem en tilstand: reset, bekræftelse, kvittering, 'dit link', 'betalingen fejlede', 'invitationen venter'. Den er forventet. Den er tidskritisk. Den må ikke være et nyhedsbrev, I har sat et andet badge på.

Marketing-mail er en mail, I gerne vil have, at de åbner. Andet formål, andet samtykke, andet omdømme. Når I blander dem på samme From og samme IP-pool, arver reset-mailen det rygte, jeres kampagne byggede. Det er den almindelige grund til at 'det virkede i staging' og dør i produktion efter første udsendelse.

DNS er ikke dekoration. SPF siger hvem der må sende som domenet. DKIM siger at indholdet ikke blev pillet ved undervejs. DMARC siger hvad modtageren skal gøre, når de to ikke stemmer — og om From må se ud som jer, når underskriften sidder et andet sted. Alignment er ordet, de fleste springer over: det synlige From og den underskrivende identitet skal høre sammen. Ellers hjælper pæne records ikke.

Ejerskab er den del, skabelon-debatten skjuler. Hvem kan ændre From? Hvem har DNS? Hvem ser, at en reset bouncede? Hvem har lov at sende 'et hurtigt nyhedsbrev' fra det samme domæne? Hvis svaret er 'marketing har værktøjet, udvikling har koden, ingen har bounces', har I ikke et mail-setup. I har tre antagelser.

Start i zonens records, ikke i HTML. Find det From, brugeren ser. Find hvilken tjeneste der faktisk sender. Tjek at SPF peger på den tjeneste — og ikke på fem historiske, I har glemt. Tjek at DKIM-nøglen matcher det, udbyderen viser nu, ikke det I satte for to år siden. Tjek DMARC: p=none er et spejl, ikke en politik. Det er fint mens I kigger. Det er ikke 'vi har DMARC', hvis I aldrig rykker videre, og aldrig læser rapporterne.

Derefter headers i en rigtig indbakke. Ikke jeres egen, der allerede kender jer. En frisk adresse hos en stor udbyder. Læs Authentication-Results. Læs, om SPF og DKIM passer, og om DMARC gav pass. Læs, hvilket domæne der underskrev. Hvis I ikke kan forklare en fail, er skabelon-ændringen gætværk.

Først til sidst copy og layout. Ja, 'RE: faktura' og store billeder uden tekst kan skade. Ja, en URL der ikke matcher afsenderen, ser ud som phishing. Men et pænt brev på et domæne, I ikke må sende som, er stadig et brev, filteret har lov at tvivle på. Omvendt kan en kedelig, kort reset-mail på et aligned domæne lande, selv om den er grim.

List-unsubscribe, åbne-pixels og sporings-domæner hører til marketing. På en reset er de støj, og ofte et signal I ikke vil sende. Hold transaktionsmail kort: hvorfor den kom, hvad brugeren skal gøre, en vej der ikke kræver at de logger ind for at læse selve advarslen. Gem kampagnen til det rør, I har samtykke til.

Stripe kan sende kvittering, faktura og 'opdater kort'. Det er ofte det rigtige. Så skal I ikke også sende en hjemmelavet 'tak for købet' fra et domæne, I ikke har sat DNS på. To mails om samme betaling er ikke bedre service. Det er to chancer for at den ene rammer spam og den anden forvirrer. Beslut hvem der ejer hver type. Skriv det ned. Sluk den, I ikke vil eje.

Auth-leverandører sender reset og invitation, medmindre I har bedt om at gøre det selv. At 'overtage' de mails uden at overtage DNS og bounce-håndtering er hvordan I får et pænere brev, der ikke lander. Hvis I selv sender magic link fra Next.js, er ruten og hemmeligheden jeres — og From og DKIM er det også. Et fetch til et ESP i en Route Handler er ikke et setup. Det er et kald, indtil zonens records matcher.

På Next.js er den typiske løgn at I har kontrollen, fordi I ejer repoet. En server action sender via et SDK, env peger på et testdomæne, og produktion arver et From, nogen satte i et dashboard. Eller I renderer en HTML-streng i React og glemmer at text-delen findes. Indbakker og tilgængelighed vil have en tekstkrop. Kontrolleret HTML er fint. HTML alene er et signal, spam-filtre kender.

WordPress-shops og 'et plugin der sender' fejler samme sted med et andet ansigt: WooCommerce eller et SMTP-plugin med en fælles nøgle, ingen DKIM, og en afsender der ligner webmaster@hosting. Tjekket er det samme. Inventar først. DNS bagefter. Skabelon til sidst. Et nyt plugin oven på en zone, I ikke ejer, er et fjerde rør.