Paano Magpadala ng Email mula sa App Mo (at Makarating sa Inbox)

Para magpadala ng email mula sa app nang maaasahan, gumamit ng email sending provider sa halip na sarili mong mailbox, magpadala mula sa address sa sarili mong domain, at idagdag ang mga DNS record na ibibigay ng provider para pumasa ang SPF, DKIM at DMARC. Panatilihing hiwalay ang transactional email (password reset, resibo, kumpirmasyon) sa marketing email, ipadala ang bawat isa lamang sa mga taong inaasahan ito, at hawakan ang mga bounce at unsubscribe. Unahin ang tamang authentication; ito ang pinakakaraniwang dahilan kung bakit napupunta sa spam ang email ng app.

Transactional vs marketing email

Magkamukha ang dalawang uri ng email na ito sa code, pero magkaiba ang trato sa kanila ng mga inbox provider at ng batas.

Paghiwalayin ang mga ito. Kapag nakatanggap ng spam complaint ang isang marketing campaign, ayaw mong maapektuhan ang mga password reset na galing sa parehong stream. Karaniwang paraan ang hiwalay na subdomain, halimbawa mail.example.com para sa account email at news.example.com para sa mga newsletter, at may ilang provider na naghihiwalay din nito sa loob. Halimbawa, inilalarawan ng Postmark ang transactional at broadcast nitong "message stream" bilang tumatakbo sa magkahiwalay na sending infrastructure, ayon sa Setyembre 2026.

Pagpili ng provider

Hindi dapat magpadala ng email ang app mo mismo mula sa sarili nitong server. Inaasikaso ng mga sending provider ang infrastructure, IP reputation, retry at pagproseso ng bounce. Kabilang sa kilalang opsyon ang Postmark, Resend, SendGrid, Amazon SES at Mailgun; bawat isa ay may HTTP API at SMTP access, at nagbabago ang presyo at plano, kaya ikumpara sila sa kani-kanilang site.

Ano ang ikumpara:

• Pokus. May mga provider na nakatuon sa transactional email; ang iba ay pinagsasama ang transactional at marketing.
• Developer experience. Malinaw na API, opisyal na library para sa wika mo, at kapaki-pakinabang na log na nagpapakita kung na-deliver, na-bounce o namarkahang spam ang bawat mensahe.
• Webhook para sa bounce, complaint at delivery, para makapag-react ang app mo.
• Template: nakaimbak sa provider, o nasa sarili mong code. Mas madaling i-version at i-test kapag nasa code.
• Rehiyon at paghawak ng data, kung may kinakailangan ka tungkol sa lugar kung saan pinoproseso ang data.
• Gastos sa dami mo, kasama kung ano ang mangyayari kapag lumampas sa libreng tier.

Para sa newsletter sa isang listahan, mas angkop kadalasan ang dedikadong newsletter o email marketing tool kaysa gumawa ng campaign feature sa loob ng app mo.

I-set up ang sending domain

Magpadala mula sa sarili mong domain, gaya ng hello@example.com, hindi sa Gmail o Outlook address. Ang mail mula sa libreng mailbox na ipinapadala sa pamamagitan ng third-party na serbisyo ay bumabagsak sa authentication check at malamang na mafi-filter.

Isaalang-alang ang subdomain na nakalaan lang para sa pagpapadala. Halimbawa, inirerekomenda ng Resend na magpadala mula sa mga subdomain gaya ng updates.example.com para ihiwalay ang sending reputation (ayon sa Setyembre 2026). Pinapanatili rin nitong hiwalay ang email DNS record sa DNS ng pangunahing site mo.

Ibibigay ng provider ang mga DNS record na idadagdag mo sa lugar kung saan pinamamahalaan ang DNS ng domain mo. Kung bago pa sa DNS, ipinapaliwanag muna ng paano gumagana ang domain at DNS ang mga record.

SPF

Ang SPF (Sender Policy Framework) ay TXT record na naglilista kung aling mga server ang maaaring magpadala ng email para sa domain mo. Tinitingnan ng tatanggap kung nasa listahan ang server na nagpapadala.

• Dapat isa lamang ang SPF record ng domain. Kapag nagdagdag ka ng provider, pagsamahin ito sa umiiral na record sa halip na gumawa ng pangalawa.
• Hanggang 10 DNS lookup lamang ang pinapayagan ng SPF kapag sinusuri ito; ang mahahabang chain ng include: ay maaaring lumampas dito at magdulot ng pagkabigo.
• Maraming provider ang nagse-set ng SPF sa return-path subdomain na hinihiling nilang gawin mo, kaya maaaring hindi mo na kailangang galawin ang pangunahing SPF record mo.

DKIM

Ang DKIM (DomainKeys Identified Mail) ay nagdaragdag ng cryptographic signature sa bawat mensahe. Pinipirmahan ito ng provider gamit ang private key; ikaw ang naglalathala ng katumbas na public key bilang DNS record (TXT o CNAME, depende sa provider). Sinusuri ng tatanggap ang signature para matiyak na galing ito sa awtorisadong nagpadala at hindi binago sa daan.

Karamihan ng hakbang na "verify domain" ng provider mo ay tungkol sa DKIM. Huwag itong laktawan.

DMARC

Pinag-uugnay ng DMARC ang dalawa pa. Ito ay TXT record sa _dmarc.yourdomain.com na nagsasabi sa mga tatanggap ng:

• Alignment: ang domain sa nakikitang From address ay dapat tumugma sa domain na pumasa sa SPF o DKIM.
• Policy: ano ang gagawin sa mail na pumapalya: p=none (i-report lang), p=quarantine (ituring na kahina-hinala, kadalasang spam) o p=reject.
• Mga report: saan ipapadala ang aggregate report (rua=), para makita mo kung sino ang nagpapadala bilang domain mo.

Makatwirang landas ang magsimula sa p=none at reporting address, kumpirmahing pumapasa ang lehitimong mail mo, saka lumipat sa quarantine at sa huli ay reject. Ginagawa rin ng mahigpit na policy na mas mahirap gayahin ng iba ang domain mo.

Ano ang hinihingi ng Gmail

Ayon sa mga gabay ng Google para sa nagpapadala, simula Setyembre 2026:

• Lahat ng nagpapadala sa personal na Gmail account ay kailangan ng SPF o DKIM, wastong forward at reverse DNS para sa sending server, TLS, at spam rate na mas mababa sa 0.3% sa Postmaster Tools.
• Bulk sender (higit sa 5,000 mensahe kada araw sa Gmail) ay kailangan ng SPF at DKIM, DMARC record (pinapayagan ang p=none policy), From-domain alignment, at one-click unsubscribe pati nakikitang unsubscribe link sa marketing at subscribed na mensahe.

Ang provider ang gumagawa ng server-side na bahagi. Ang DNS record at ang paghawak sa unsubscribe ay responsibilidad mo. Kahit malayo ka pa sa 5,000 kada araw, ang pagtugon sa mga patakaran ng bulk ang pinakasimpleng paraan para maging ligtas.

Ilagay ang pagpapadala sa app mo

Kapag na-verify na ang domain:

1. I-save ang API key bilang server-side secret; huwag kailanman sa front-end code. Tingnan ang ano ang environment variables at secrets.
2. Magpadala mula sa server, pagkatapos magtagumpay ang aksyong nag-trigger ng email.
3. Huwag paghintayin ang user sa email. Para sa mas higit pa sa pinakasimpleng app, ilagay sa queue ang pagpapadala at mag-retry sa mga pansamantalang error, para hindi bumagal ang sign-up dahil sa mabagal na tugon ng provider.
4. I-log ang resulta, gaya ng message ID at status ng provider, nang hindi nilalagay ang key o buong nilalaman ng mensaheng may personal na data.
5. Hawakan ang webhook para sa bounce at complaint; ihinto ang pagpapadala sa mga address na hard-bounce o nag-mark sa iyo bilang spam.

Isang prompt na sumasaklaw sa batayan:

Magpadala ng transactional email gamit ang [PROVIDER] gamit ang server secret na [ENV_NAME], mula sa "Acme hello@mail.acme.com". Magpadala ng welcome email pagkatapos ng sign-up at booking confirmation pagkatapos ma-save ang booking. Panatilihin ang mga template sa code, kasama ang plain-text na bersyon sa tabi ng HTML. Ilagay sa queue ang mga pagpapadala at mag-retry ng pansamantalang error hanggang tatlong beses. I-log ang mga pagkabigo gamit ang error ng provider pero huwag ang API key. Magdagdag ng webhook endpoint na mamarkahan ang mga address bilang hindi maa-deliver sa hard bounce at complaint, at lalaktawan ang mga ito sa susunod.

Ang mga account email (verification link, magic link at password reset) ay bahagi ng login. Ipinapaliwanag ng paano magdagdag ng login sa app mo kung paano nagkakasama ang mga flow na ito; gawing single-use at maikli ang bisa ng mga link na ito.

Mga gawi para sa deliverability

Ang authentication ang nagpapakita sa iyo bilang lehitimo. Ang ugali ang nagpapanatili sa iyo sa inbox.

• Magpadala lamang ng inaasahan ng mga tao. Kumpirmadong sign-up, malinaw na opt-in para sa marketing, walang biniling listahan.
• Gawing madali ang pag-unsubscribe sa anumang hindi tahasang transactional, at igalang agad ito.
• Painitin ang bagong domain. Ang bagong domain na nagpapadala ng libo-libong mensahe sa unang araw ay mukhang kahina-hinala. Simulan sa transactional mail at dahan-dahang dagdagan ang dami.
• Panatilihing malinis ang listahan. Alisin agad ang hard bounce at isaalang-alang na alisin ang mga taong matagal nang walang binubuksan.
• Sumulat na parang tao. Malinaw na subject, kilalang From name, plain-text na bahagi, kaunting larawan, at link sa sarili mong domain. Iwasan ang link shortener.
• Magmonitor. I-register ang domain mo sa Google Postmaster Tools at paminsan-minsang basahin ang DMARC report.
• Gumamit ng totoong reply-to na may nagbabasa. Magandang senyales ang mga reply, at kapaki-pakinabang na feedback.

Pagsubok nang hindi nag-i-spam ng kahit sino

• Gamitin ang test mode o sandbox ng provider kung meron, o magpadala sa mga address na pag-aari mo.
• Sa development, magpadala sa catch-all test inbox sa halip na sa totoong user; ang database na puno ng mukhang totoong address ay madaling paraan para aksidenteng mag-email sa mga estranghero.
• Tingnan ang bawat template sa ilang client: Gmail sa web, mail app sa telepono, Outlook, at dark mode.
• Tingnan ang message headers ng test email: ipinapakita nito kung pumasa ang SPF, DKIM at DMARC.

Mga batayang legal

Nag-iiba ang patakaran sa bawat bansa. Sa pangkalahatan, kailangan ng marketing email ng pahintulot sa maraming lugar, dapat tukuyin ang nagpapadala, at dapat may gumaganang unsubscribe; iba ang trato sa transactional email, pero hindi ito dapat gamitin para isingit ang marketing. Kung nangongolekta ka ng address mula sa waitlist page, sabihin kung ano ang ipapadala at iimbakin mo, at kailan at paano nag-sign up ang bawat tao. Kapag may pag-aalinlangan, tingnan ang mga patakarang nalalapat sa mga user mo.

Checklist ng email

• Napili ang sending provider; nakatago ang API key bilang server secret
• Nagpapadala mula sa sarili mong domain o subdomain, hindi libreng mailbox
• Nadagdag at pumapasa ang SPF, DKIM at DMARC record
• Hiwalay ang transactional at marketing mail
• Naka-queue at may retry ang mga pagpapadala; naka-log ang resulta
• Hinahawakan ang webhook para sa bounce at complaint
• May unsubscribe sa hindi-transactional na mail, at agad itong iginagalang
• Nasubukan ang mga template sa ilang client; ang test mail ay hindi kailanman umaabot sa totoong user

Pagpapadala ng email mula sa Mythex app

Walang kasamang built-in na serbisyo sa pagpapadala ng email ang Mythex para sa mga app na ginagawa mo, kaya dadalhin mo ang sarili mong provider gaya ng Resend, SendGrid o Postmark. I-save ang API key nito bilang project secret; maaaring hilingin ito ng agent gamit ang secrets card sa chat, at sabihin ang mga email na kailangan mo sa simpleng salita. May starter prompt sa docs sa magpadala ng email mula sa app mo. Kung binili mo ang domain mo sa pamamagitan ng Mythex sa Pro, maaari mong idagdag ang TXT at CNAME record ng provider sa DNS settings ng domain; tingnan ang custom domains.

Mga tanong