Inkommande e-post: svar på kampanjer

När en mottagare trycker Svara på en kampanj-e-post kommer svaret tillbaka till WeZend och landar i inkorgen — trådat på samma samtal som allt annat du har skickat till den adressen, och korrelerat till exakt den kampanjen och exakt det meddelande som besvarades. E-post blir tvåvägs, som SMS och WhatsApp redan var.

Hur korreleringen fungerar

Varje kampanj-e-post stämplas med en Reply-To per meddelande på formen reply+<meddelande-id>@reply.dittforetag.se (VERP). Token är meddelandets eget UUID, så när svaret kommer in gissas inget utifrån adress och närhet i tid: id:t löses deterministiskt till en kund, en kampanj och ett ursprungligt meddelande.

Två regler håller det förutsägbart:

• Endast kampanj-utskick stämplas — ett transaktionellt POST /v1/messages/send lämnas orört.
• Ett explicit reply_to på utskicket vinner alltid. Sätter du det rör WeZend det inte, så svaret går till din egen brevlåda i stället och inget landar i inkorgen.

Vad som händer med ett svar

1. Den mottagande transporten parsar MIME-meddelandet och POSTar det till POST /v1/webhooks/inbound-email — autentiserat med delad hemlighet, samma konvention som leveransrapport-webhookarna.
2. Svaret köas för hållbar bearbetning och dedupliceras på sitt Message-ID, så en leverantör som re-POSTar samma mail inte kan skapa en dubblett. Är kön otillgänglig bearbetar webhooken svaret inline i stället för att slänga det, och endpointen svarar alltid 2xx så att leverantören aldrig hård-retryar.
3. Svaret trådas in i samtalet för den adressen och lagras med ämne, HTML-body, SPF/DKIM/DMARC-utfallen och id:t för den kampanj det besvarar.
4. En message.received-plattformshändelse avfyras, så ditt CRM eller din helpdesk får svaret utan polling. Har du satt en inkommande webhook-URL vidarebefordras svaret även dit.

Vad som sorteras bort innan det når dig

• Spam och autentiseringsfel — en spam-score på 8 eller högre, eller DMARC fail, sätts i karantän och blir aldrig en kontakt eller ett samtal.
• Autosvar — allt med en Auto-Submitted-header annan än no (frånvarosvar, ärendebekräftelser) ignoreras, så svar inte kan loopa.
• Mail som inte kan tillskrivas — en svarsadress utan giltig meddelande-token, eller en token som inte matchar något meddelande, avvisas i stället för att gissas.

Ett svar som bara lyder STOP (eller unsubscribe, afmeld, framelding …) hanteras som en avanmälan innan det blir ett supportärende: adressen hamnar på spärrlistan, ett samtyckesregister skrivs, och contact.unsubscribed avfyras — se Samtycke.

Bilagor lagras per svar: JPEG, PNG, GIF, WebP och PDF, upp till 15 MB per fil och 20 filer per meddelande. Andra innehållstyper registreras som överhoppade i stället för att sparas.

Så slår du på det

Inkommande e-post ligger i vila tills en operatör konfigurerar det — det finns ingen knapp i dashboarden, eftersom det kräver DNS. Uppsättningen är en MX-post på en dedikerad svars-subdomän (till exempel reply.dittforetag.se) som pekar på den mottagande transporten, plus den domänen satt på backenden. Apex-domänens befintliga MX är orörd, så detta stör inte var företagets brevlådor bor i dag.

I praktiken är det SendGrid Inbound Parse: svars-subdomänens MX pekar på den, den utvärderar SPF, DKIM och DMARC, och den POSTar det parsade meddelandet till ingestion-endpointen. Er DNS ligger kvar där den redan är — posten är en MX på en subdomän, inte en migrering.

Transporten hålls medvetet på armlängds avstånd: ingestion-endpointen normaliserar det den tar emot till en intern payload, så att byta eller lägga till en mottagande leverantör är en mappare, inte en omskrivning. Den utgående uppsättningen är oförändrad — se E-post: domäner, DNS & utskick.