Indgående email: svar på kampagner

Når en modtager trykker Svar på en kampagne-email, kommer svaret tilbage til WeZend og lander i indbakken — trådet på samme samtale som alt andet, du har sendt til den adresse, og korreleret til præcis den kampagne og præcis den besked, der blev svaret på. Email bliver tovejs, som SMS og WhatsApp allerede var.

Hvordan korreleringen virker

Hver kampagne-email stemples med en Reply-To pr. besked på formen reply+<besked-id>@reply.ditdomæne.dk (VERP). Tokenet er beskedens eget UUID, så når svaret ankommer, gættes der ikke ud fra adresse og tidsnærhed: id'et opløses deterministisk til én kunde, én kampagne og én oprindelig besked.

To regler holder det forudsigeligt:

• Kun kampagne-afsendelser stemples — en transaktionel POST /v1/messages/send røres ikke.
• Et eksplicit reply_to på afsendelsen vinder altid. Sætter du det, lader WeZend det være, så svaret går til din egen postkasse i stedet, og intet lander i indbakken.

Hvad der sker med et svar

1. Den modtagende transport parser MIME-beskeden og POSTer den til POST /v1/webhooks/inbound-email — autentificeret med delt hemmelighed, samme konvention som leveringsrapport-webhooks.
2. Svaret køsættes til holdbar behandling og dedupliceres på sit Message-ID, så en udbyder, der re-POSTer samme mail, ikke kan skabe en dublet. Er køen utilgængelig, behandler webhooken svaret inline frem for at smide det væk, og endpointet svarer altid 2xx, så udbyderen aldrig hård-retryer.
3. Svaret trådes ind i samtalen for den adresse og gemmes med emne, HTML-body, SPF/DKIM/DMARC-verdikterne og id'et på den kampagne, det svarer på.
4. Et message.received-platform-event affyres, så dit CRM eller din helpdesk får svaret uden polling. Har du sat en indgående webhook-URL, videresendes svaret også dertil.

Hvad der frasorteres, før det når dig

• Spam og autentificeringsfejl — en spam-score på 8 eller derover, eller DMARC fail, sættes i karantæne og bliver aldrig en kontakt eller en samtale.
• Autosvar — alt med en Auto-Submitted-header ud over no (feriesvar, sagsbekræftelser) ignoreres, så svar ikke kan loope.
• Mail der ikke kan tilskrives — en svaradresse uden gyldigt besked-token, eller et token der ikke matcher nogen besked, afvises frem for at blive gættet på.

Et svar, der blot lyder STOP (eller unsubscribe, afmeld, framelding …), håndteres som en afmelding, før det bliver en supportsag: adressen ryger på suppressionslisten, en samtykke-registrering skrives, og contact.unsubscribed affyres — se Samtykke.

Vedhæftninger gemmes pr. svar: JPEG, PNG, GIF, WebP og PDF, op til 15 MB pr. fil og 20 filer pr. besked. Andre content-typer registreres som oversprunget frem for at blive gemt.

Sådan tændes det

Indgående email ligger i dvale, indtil en operatør konfigurerer det — der er ingen kontakt i dashboardet, fordi det kræver DNS. Opsætningen er én MX-record på et dedikeret svar-subdomæne (fx reply.ditdomæne.dk), der peger på den modtagende transport, plus det domæne sat på backenden. Dit apex-domænes eksisterende MX berøres ikke, så det forstyrrer ikke, hvor firmaets postkasser bor i dag.

I praksis er det SendGrid Inbound Parse: svar-subdomænets MX peger på den, den evaluerer SPF, DKIM og DMARC, og den POSTer den parsede besked til ingestions-endpointet. Jeres DNS bliver, hvor det er — recorden er én MX på et subdomæne, ikke en migrering.

Transporten holdes bevidst på afstand: ingestions-endpointet normaliserer det, det modtager, til én intern payload, så at skifte eller tilføje en modtagende udbyder er en mapper, ikke en omskrivning. Den udgående opsætning er uforandret — se Email: domæner, DNS & afsendelse.