Innkommende e-post: svar på kampanjer

Når en mottaker trykker Svar på en kampanje-e-post, kommer svaret tilbake til WeZend og lander i innboksen — trådet på samme samtale som alt annet du har sendt til den adressen, og korrelert til nøyaktig den kampanjen og nøyaktig den meldingen det ble svart på. E-post blir toveis, slik SMS og WhatsApp allerede var.

Hvordan korreleringen virker

Hver kampanje-e-post stemples med en Reply-To per melding på formen reply+<melding-id>@reply.dittfirma.no (VERP). Tokenet er meldingens eget UUID, så når svaret kommer inn, gjettes ingenting ut fra adresse og tidsnærhet: id-en løses deterministisk til én kunde, én kampanje og én opprinnelig melding.

To regler holder det forutsigbart:

• Bare kampanje-sendinger stemples — en transaksjonell POST /v1/messages/send røres ikke.
• En eksplisitt reply_to på sendingen vinner alltid. Setter du den, lar WeZend den være, så svaret går til din egen postkasse i stedet og ingenting lander i innboksen.

Hva som skjer med et svar

1. Den mottakende transporten parser MIME-meldingen og POSTer den til POST /v1/webhooks/inbound-email — autentisert med delt hemmelighet, samme konvensjon som leveringsrapport-webhookene.
2. Svaret køes for holdbar behandling og dedupliseres på sitt Message-ID, så en leverandør som re-POSTer samme e-post ikke kan lage en dublett. Er køen utilgjengelig, behandler webhooken svaret inline i stedet for å forkaste det, og endepunktet svarer alltid 2xx slik at leverandøren aldri hard-retryer.
3. Svaret trådes inn i samtalen for den adressen og lagres med emne, HTML-body, SPF/DKIM/DMARC-verdiktene og id-en til kampanjen det svarer på.
4. En message.received-plattformhendelse avfyres, så CRM-et eller helpdesken din får svaret uten polling. Har du satt en innkommende webhook-URL, videresendes svaret dit også.

Hva som lukes ut før det når deg

• Spam og autentiseringsfeil — en spam-score på 8 eller høyere, eller DMARC fail, settes i karantene og blir aldri en kontakt eller en samtale.
• Autosvar — alt med en Auto-Submitted-header annet enn no (ferie-svar, sakskvitteringer) ignoreres, så svar ikke kan loope.
• E-post som ikke kan tilskrives — en svaradresse uten gyldig meldings-token, eller et token som ikke matcher noen melding, avvises heller enn å bli gjettet på.

Et svar som bare lyder STOP (eller unsubscribe, afmeld, framelding …) håndteres som en avmelding før det blir en supportsak: adressen havner på sperrelisten, en samtykkeregistrering skrives, og contact.unsubscribed avfyres — se Samtykke.

Vedlegg lagres per svar: JPEG, PNG, GIF, WebP og PDF, opp til 15 MB per fil og 20 filer per melding. Andre innholdstyper registreres som hoppet over heller enn å bli lagret.

Slik slår du det på

Innkommende e-post ligger i dvale til en operatør konfigurerer det — det finnes ingen bryter i dashbordet, fordi det krever DNS. Oppsettet er én MX-post på et dedikert svar-subdomene (for eksempel reply.dittfirma.no) som peker på den mottakende transporten, pluss det domenet satt på backenden. Apex-domenets eksisterende MX er urørt, så dette forstyrrer ikke der firmaets postkasser bor i dag.

I praksis er det SendGrid Inbound Parse: svar-subdomenets MX peker på den, den evaluerer SPF, DKIM og DMARC, og den POSTer den parsede meldingen til ingestion-endepunktet. DNS-en deres blir der den allerede er — posten er én MX på et subdomene, ikke en migrering.

Transporten holdes bevisst på armlengdes avstand: ingestion-endepunktet normaliserer det det mottar til én intern payload, så å bytte eller legge til en mottakende leverandør er en mapper, ikke en omskriving. Det utgående oppsettet er uendret — se E-post: domener, DNS & utsending.