Email: küldés, fogadás, kézbesíthetőség

23.1A két fél: Sending és Routing

A Cloudflare Email Service két képességet fog össze:

Küldés Workerből

{
  "send_email": [
    { "name": "EMAIL", "remote": true }   // remote: valódi API a `wrangler dev` alatt is
  ]
}

export async function sendMail(env, opts: {
  to: string; subject: string; html: string; text: string; replyTo?: string;
}) {
  const res = await env.EMAIL.send({
    from: "noreply@myapp.com",
    to: opts.to,
    subject: opts.subject,
    html: opts.html,
    text: opts.text,              // MINDIG legyen sima szöveges változat is
    replyTo: opts.replyTo,
  });
  return res.messageId;           // naplózd — ez a nyomkövetési azonosító
}

// 1) az API-végpont csak sorba tesz
await env.JOBS.send({ type: "mail", template: "password-reset",
                       to: user.email, tenantId, data: { token } });

// 2) a consumer küld — itt van retry, DLQ, és itt mérünk (9. modul)
async queue(batch, env) {
  for (const m of batch.messages) {
    try {
      const { html, text, subject } = renderTemplate(m.body);
      const id = await sendMail(env, { to: m.body.to, subject, html, text });
      env.USAGE.writeDataPoint({ blobs: [m.body.tenantId, "mail_sent", m.body.template],
                                doubles: [1], indexes: [m.body.tenantId] });
      m.ack();
    } catch (e) { m.retry({ delaySeconds: 120 }); }
  }
}

Fogadás: az email mint bemenet

A bejövő oldal az, ami a Workers-modellben tényleg más: a levél egy handlerben landol (ugyanabban a Workerben, ahol a fetch és a queue van — 2. modul):

export default {
  async email(message, env, ctx) {
    const from = message.from;          // feladó
    const to   = message.to;            // pl. support@myapp.com vagy acme@tickets.myapp.com

    // a nyers üzenet feldolgozása (fejlécek, törzs, mellékletek)
    const raw = await new Response(message.raw).text();

    // 1) melyik tenanthoz tartozik? — a címzettből vagy a feladóból
    const tenantId = tenantFromAddress(to);

    // 2) ne itt dolgozzuk fel: sorba tesszük (ugyanaz az elv, mint a webhooknál)
    await env.JOBS.send({ type: "inbound-mail", tenantId, from, to, raw });

    // 3) opcionálisan továbbítás egy valódi postafiókba is
    // await message.forward("support@mycompany.com");
  },
};

Mit lehet ezzel csinálni? Ticket nyitása emailből, válaszok hozzáfűzése a meglévő ticketthez (a In-Reply-To fejléc alapján), mellékletek mentése R2-be (6. modul), automatikus feldolgozás (rendelés-visszaigazolás beolvasása), vagy egyszerűen egy okos átirányítás. A levél elutasítható is (message.setReject()), ha nem felel meg a szabályaidnak.

23.2Kézbesíthetőség — itt dől el, hogy megérkezik-e

Ez a rész független attól, melyik szolgáltatót használod, és a fejlesztők jellemzően alábecsülik. Három DNS-rekord adja az alapot:

Praktikus sorrend a bevezetéshez: állítsd be az SPF-et és a DKIM-et, majd a DMARC-ot először p=none értékkel — így kapsz jelentéseket, de még nem utasít el semmit. Nézd meg pár hétig, mi küld a domainedről (gyakran kiderül, hogy a CRM, a számlázó és a hírlevél-eszköz is), és amikor minden legitim küldő aláírt, lépj quarantine, majd reject felé.

23.3Multitenant sajátosságok

23.4Sablonok, tesztelés, üzemeltetés

• Sablonok: tartsd őket a repóban (verziózva), ne az adatbázisban. A HTML-emailhez táblázatos elrendezés és inline CSS kell — érdemes egy bevált email-sablon keretet használni, nem nulláról építeni.
• Lokalizáció: a nyelv a felhasználó beállításából jöjjön, ne a böngésző fejlécéből (egy háttérben küldött emailnél nincs is böngésző).
• Tesztelés fejlesztés közben: a send_email binding remote: true beállítással a wrangler dev alatt is a valódi szolgáltatást hívja (11. modul) — ezért dev-ben irányíts mindent egy teszt-postafiókba, vagy tegyél egy kapcsolót a kódba, ami nem-produkciós környezetben csak logol. Egy véletlen éles kiküldés a fejlesztői gépről kellemetlen.
• Bejövő tesztelés: a routing-szabállyal küldd a teszt-címet a dev Workeredhez — a wrangler tail (9. modul) mutatja, mi érkezett.
• Ami mindig kell: leiratkozási link a nem-tranzakciós levelekben, a küldések naplózása (messageId-vel), és riasztás, ha a DLQ-ba email-üzenetek kerülnek.

23.5Mikor válassz mégis külső szolgáltatót?

Az Email Service kényelmes (binding, nincs külön kulcs, ugyanaz a számla), de nem mindig a helyes választás. Maradj/válts külső szolgáltatóra (Resend, Postmark, SES…), ha:

• marketing-küldés is van: listakezelés, kampányok, A/B teszt, leiratkozás-kezelés — ez más termékkategória;
• fejlett analitika kell (megnyitás, kattintás, bounce-osztályozás webhookkal);
• a szolgáltatód bounce/complaint webhookjaira épül a folyamatod (az érvénytelen címek automatikus tiltása);
• vagy egyszerűen már bevált a mostani szállítód, és a migrációnak nincs haszna (10. modul elve: ne mozgass olyat, ami jól működik).

A jó hír: bármelyiket választod, a szerkezet ugyanaz marad — API-végpont → Queue → küldő consumer. A szolgáltató cseréje így egyetlen függvény cseréje (sendMail), nem architektúra-váltás.

23.6Ellenőrizd magad