તમારી એપમાંથી ઇમેઇલ કેવી રીતે મોકલવા (અને ઇનબોક્સમાં પહોંચાડવા)

તમારી એપમાંથી વિશ્વસનીય રીતે ઇમેઇલ મોકલવા માટે, તમારા પોતાના મેઇલબોક્સને બદલે ઇમેઇલ મોકલતો પ્રોવાઇડર વાપરો, તમારા પોતાના ડોમેઇનના એડ્રેસ પરથી મોકલો, અને પ્રોવાઇડર આપે તે DNS રેકોર્ડ ઉમેરો જેથી SPF, DKIM અને DMARC ત્રણેય પાસ થાય. ટ્રાન્ઝેક્શનલ ઇમેઇલ — પાસવર્ડ રીસેટ, રસીદ, પુષ્ટિ — ને માર્કેટિંગ ઇમેઇલથી અલગ રાખો, દરેકને ફક્ત એવા લોકોને મોકલો જે તેની અપેક્ષા રાખે છે, અને બાઉન્સ તથા અનસબ્સ્ક્રાઇબને સંભાળો. સૌથી પહેલાં ઓથેન્ટિકેશન સાચું કરો; એપના ઇમેઇલ સ્પામમાં જવાનું આ સૌથી સામાન્ય કારણ છે.

ટ્રાન્ઝેક્શનલ વિરુદ્ધ માર્કેટિંગ ઇમેઇલ

આ બે પ્રકારના ઇમેઇલ કોડમાં એકસરખા દેખાય છે, પરંતુ ઇનબોક્સ પ્રોવાઇડરો અને કાયદા દ્વારા તેમની સાથે ખૂબ જુદો વ્યવહાર થાય છે.

તેમને અલગ રાખો. જો માર્કેટિંગ કેમ્પેઇનને સ્પામ ફરિયાદો મળે, તો એ જ સ્ટ્રીમમાંથી જતા પાસવર્ડ રીસેટને તેની અસર ન થવી જોઈએ. સામાન્ય અભિગમ છે અલગ સબડોમેઇન — જેમ કે એકાઉન્ટના ઇમેઇલ માટે mail.example.com અને ન્યૂઝલેટર માટે news.example.com — અને કેટલાક પ્રોવાઇડરો બંનેને આંતરિક રીતે અલગ રાખે છે. દાખલા તરીકે, Postmark સપ્ટેમ્બર 2026 સુધીમાં તેના ટ્રાન્ઝેક્શનલ અને બ્રોડકાસ્ટ "મેસેજ સ્ટ્રીમ"ને અલગ મોકલવાના ઇન્ફ્રાસ્ટ્રક્ચર પર ચાલતા તરીકે વર્ણવે છે.

પ્રોવાઇડર પસંદ કરવો

તમારી એપે પોતાના સર્વર પરથી ખુદ ઇમેઇલ મોકલવા ન જોઈએ. મોકલવાના પ્રોવાઇડર ઇન્ફ્રાસ્ટ્રક્ચર, IP પ્રતિષ્ઠા, ફરી પ્રયાસો અને બાઉન્સ પ્રક્રિયા સંભાળે છે. જાણીતા વિકલ્પોમાં Postmark, Resend, SendGrid, Amazon SES અને Mailgun સામેલ છે; દરેક પાસે HTTP API અને SMTP ઍક્સેસ છે, અને કિંમતો તથા પ્લાન બદલાતા રહે છે, તેથી તેમની પોતાની સાઇટ પર સરખામણી કરો.

શું સરખાવવું:

• ફોકસ. કેટલાક પ્રોવાઇડરો ટ્રાન્ઝેક્શનલ ઇમેઇલ પર ધ્યાન આપે છે; અન્ય ટ્રાન્ઝેક્શનલ અને માર્કેટિંગને સાથે રાખે છે.
• ડેવલપર અનુભવ. સ્પષ્ટ API, તમારી ભાષા માટે સત્તાવાર લાઇબ્રેરીઓ, અને ઉપયોગી લોગ જે બતાવે કે દરેક સંદેશ પહોંચ્યો, બાઉન્સ થયો કે સ્પામ તરીકે ચિહ્નિત થયો.
• વેબહૂક બાઉન્સ, ફરિયાદો અને ડિલિવરી માટે, જેથી તમારી એપ તેના પર પ્રતિક્રિયા આપી શકે.
• ટેમ્પ્લેટ — પ્રોવાઇડર પર સંગ્રહિત, અથવા તમારા પોતાના કોડમાં. કોડમાં રાખવાથી તેમના વર્ઝન બને છે અને તેમનું ટેસ્ટિંગ થઈ શકે છે.
• પ્રદેશ અને ડેટા હેન્ડલિંગ, જો ડેટા ક્યાં પ્રોસેસ થશે તે વિશે તમારી કોઈ જરૂરિયાત હોય.
• તમારા વોલ્યુમ પર ખર્ચ, જેમાં મફત ટિયર વટાવી જવા પર શું થાય તે પણ સામેલ છે.

યાદી પર ન્યૂઝલેટર માટે, એપમાં કેમ્પેઇન સુવિધાઓ બનાવવા કરતાં સમર્પિત ન્યૂઝલેટર અથવા ઇમેઇલ માર્કેટિંગ ટૂલ ઘણી વાર વધુ સારું બેસે છે.

તમારું મોકલવાનું ડોમેઇન સેટ કરો

તમારા પોતાના ડોમેઇન પરથી મોકલો — hello@example.com, Gmail કે Outlook એડ્રેસ નહીં. થર્ડ-પાર્ટી સેવા દ્વારા મફત મેઇલબોક્સ એડ્રેસ પરથી મોકલેલો મેઇલ ઓથેન્ટિકેશન તપાસમાં નિષ્ફળ જાય છે અને ફિલ્ટર થવાની શક્યતા વધારે છે.

ફક્ત મોકલવા માટેના સબડોમેઇનનો વિચાર કરો. દાખલા તરીકે, Resend સપ્ટેમ્બર 2026 સુધીમાં મોકલવાની પ્રતિષ્ઠાને અલગ રાખવા updates.example.com જેવા સબડોમેઇન પરથી મોકલવાની ભલામણ કરે છે. તે તમારી મુખ્ય સાઇટના ઇમેઇલ DNS રેકોર્ડને પણ અલગ રાખે છે.

પછી પ્રોવાઇડર તમને DNS રેકોર્ડ આપે છે, જે તમારા ડોમેઇનનું DNS જ્યાં મેનેજ થાય છે ત્યાં ઉમેરવાના હોય છે. જો DNS તમારા માટે નવું હોય, તો ડોમેઇન અને DNS કેવી રીતે કામ કરે છે પહેલાં રેકોર્ડ સમજાવે છે.

SPF

SPF (Sender Policy Framework) એક TXT રેકોર્ડ છે જે યાદી આપે છે કે તમારા ડોમેઇન માટે કયા સર્વર ઇમેઇલ મોકલી શકે છે. પ્રાપ્તકર્તા તપાસે છે કે મોકલનાર સર્વર યાદીમાં છે કે નહીં.

• ડોમેઇન પાસે માત્ર એક SPF રેકોર્ડ હોવો જોઈએ. પ્રોવાઇડર ઉમેરો ત્યારે બીજો રેકોર્ડ ઉમેરવાને બદલે તેને હાલના રેકોર્ડમાં મર્જ કરો.
• SPF નું મૂલ્યાંકન થાય ત્યારે વધુમાં વધુ 10 DNS લુકઅપની મંજૂરી છે; include: એન્ટ્રીની લાંબી સાંકળો તેને વટાવી શકે છે અને નિષ્ફળતા સર્જી શકે છે.
• ઘણા પ્રોવાઇડરો તમને બનાવવા કહેલા રિટર્ન-પાથ સબડોમેઇન પર SPF સેટ કરે છે, તેથી તમારે મુખ્ય SPF રેકોર્ડને સ્પર્શવું ન પડે.

DKIM

DKIM (DomainKeys Identified Mail) દરેક સંદેશમાં ક્રિપ્ટોગ્રાફિક સહી ઉમેરે છે. પ્રોવાઇડર ખાનગી કી વડે સહી કરે છે; તમે મેળ ખાતી જાહેર કી DNS રેકોર્ડ તરીકે પ્રકાશિત કરો છો (પ્રોવાઇડર પ્રમાણે TXT અથવા CNAME). પ્રાપ્તકર્તાઓ સહી તપાસે છે કે સંદેશ અધિકૃત મોકલનારાથી આવ્યો છે અને રસ્તામાં બદલાયો નથી.

પ્રોવાઇડરનું "ડોમેઇન વેરિફાઇ કરો" પગલું મોટાભાગે DKIM વિશે જ છે. તેને છોડશો નહીં.

DMARC

DMARC બાકીના બંનેને એકસાથે જોડે છે. તે _dmarc.yourdomain.com પર એક TXT રેકોર્ડ છે, જે પ્રાપ્તકર્તાઓને કહે છે:

• એલાઇનમેન્ટ: દેખાતા From એડ્રેસનું ડોમેઇન, SPF કે DKIM પાસ કરનાર ડોમેઇન સાથે મેળ ખાવું જોઈએ.
• નીતિ: નિષ્ફળ થતા મેઇલ સાથે શું કરવું — p=none (ફક્ત રિપોર્ટ કરો), p=quarantine (શંકાસ્પદ ગણો, ઘણી વાર સ્પામ) અથવા p=reject.
• રિપોર્ટ: એગ્રિગેટ રિપોર્ટ ક્યાં મોકલવા (rua=), જેથી તમે જોઈ શકો કે તમારા ડોમેઇન વતી કોણ મોકલી રહ્યું છે.

સમજદાર માર્ગ છે p=none અને રિપોર્ટિંગ સરનામાથી શરૂ કરવું, ખાતરી કરવી કે તમારો કાયદેસર મેઇલ પાસ થાય છે, પછી quarantine અને આખરે reject પર જવું. કડક નીતિ અન્ય લોકો માટે તમારા ડોમેઇનને સ્પૂફ કરવાનું પણ ઘણું મુશ્કેલ બનાવે છે.

Gmail શું માગે છે

સપ્ટેમ્બર 2026 સુધીમાં, Google ની મોકલનાર માર્ગદર્શિકા કહે છે:

• બધા મોકલનારાઓ વ્યક્તિગત Gmail ખાતાઓ પર મોકલવા માટે SPF અથવા DKIM, મોકલતા સર્વર માટે માન્ય ફોરવર્ડ અને રિવર્સ DNS, TLS, અને Postmaster Tools માં 0.3% થી નીચે સ્પામ દર જરૂરી છે.
• બલ્ક મોકલનારાઓ (Gmail પર દરરોજ 5,000 થી વધુ સંદેશા) ને SPF અને DKIM, DMARC રેકોર્ડ (p=none નીતિ માન્ય છે), From-ડોમેઇન એલાઇનમેન્ટ, અને માર્કેટિંગ તથા સબ્સ્ક્રાઇબ કરેલા સંદેશ પર વન-ક્લિક અનસબ્સ્ક્રાઇબ તેમજ દેખાતી અનસબ્સ્ક્રાઇબ લિંક જોઈએ.

સર્વર-બાજુના ભાગો તમારો પ્રોવાઇડર સંભાળે છે. DNS રેકોર્ડ અને અનસબ્સ્ક્રાઇબનું સંચાલન તમારું છે. ભલે તમે દરરોજ 5,000 ની નજીક ન હો, બલ્ક નિયમોનું પાલન સુરક્ષિત રહેવાનો સૌથી સરળ રસ્તો છે.

મોકલવાનું એપમાં બનાવો

એકવાર ડોમેઇન વેરિફાઇ થઈ જાય પછી:

1. API કી સર્વર-બાજુના સિક્રેટ તરીકે સંગ્રહો — ક્યારેય ફ્રન્ટ-એન્ડ કોડમાં નહીં. એન્વાયર્નમેન્ટ વેરિયેબલ અને સિક્રેટ્સ શું છે જુઓ.
2. સર્વર પરથી મોકલો, જે ક્રિયા ઇમેઇલને ટ્રિગર કરે તે સફળ થયા પછી.
3. વપરાશકર્તાને ઇમેઇલ માટે રાહ ન જોવડાવો. સૌથી સરળ એપ સિવાય બધા માટે, મોકલવાનું કતારમાં મૂકો અને અસ્થાયી નિષ્ફળતાઓ પર ફરી પ્રયાસ કરો, જેથી પ્રોવાઇડરનો ધીમો પ્રતિસાદ સાઇન-અપને ધીમું ન કરે.
4. પરિણામ લોગ કરો — પ્રોવાઇડરનો મેસેજ ID અને સ્થિતિ — કી કે વ્યક્તિગત ડેટા ધરાવતા સંપૂર્ણ સંદેશ લોગ કર્યા વગર.
5. બાઉન્સ અને ફરિયાદો માટે વેબહૂક સંભાળો: જે સરનામાં હાર્ડ બાઉન્સ થાય અથવા તમને સ્પામ તરીકે ચિહ્નિત કરે, તેમને મોકલવાનું બંધ કરો.

મૂળભૂત બાબતો આવરી લેતો એક પ્રોમ્પ્ટ:

[PROVIDER] સાથે સર્વર સિક્રેટ [ENV_NAME] વાપરીને ટ્રાન્ઝેક્શનલ ઇમેઇલ મોકલો, "Acme hello@mail.acme.com" પરથી. સાઇન-અપ પછી સ્વાગત ઇમેઇલ અને બુકિંગ સાચવ્યા પછી બુકિંગની પુષ્ટિ મોકલો. ટેમ્પ્લેટ કોડમાં રાખો, HTML સાથે સાદા-ટેક્સ્ટ વર્ઝન પણ રાખો. મોકલવાનું કતારમાં મૂકો અને અસ્થાયી નિષ્ફળતાઓ પર ત્રણ વખત સુધી ફરી પ્રયાસ કરો. પ્રોવાઇડરની ભૂલ સાથે નિષ્ફળતાઓ લોગ કરો, પરંતુ API કી ક્યારેય નહીં. એક વેબહૂક એન્ડપોઇન્ટ ઉમેરો જે હાર્ડ બાઉન્સ અને ફરિયાદો પર સરનામાંને અપહોંચાડી શકાય તેવા તરીકે ચિહ્નિત કરે, અને ભવિષ્યમાં તે સરનામાં છોડી દો.

એકાઉન્ટના ઇમેઇલ — ચકાસણી લિંક, મેજિક લિંક અને પાસવર્ડ રીસેટ — લૉગિનનો ભાગ છે. તમારી એપમાં લૉગિન કેવી રીતે ઉમેરવું સમજાવે છે કે આ ફ્લો એકસાથે કેવી રીતે બેસે છે; આ લિંક એક જ વાર વાપરી શકાય અને ટૂંકા સમય માટે માન્ય હોય તેવી બનાવો.

ડિલિવરેબિલિટીની ટેવો

ઓથેન્ટિકેશન તમને વિચારણામાં લાવે છે. વર્તન તમને ઇનબોક્સમાં રાખે છે.

• લોકો જેની અપેક્ષા રાખે તે જ મોકલો. પુષ્ટિ થયેલા સાઇન-અપ, માર્કેટિંગ માટે સ્પષ્ટ opt-in, ખરીદેલી યાદીઓ નહીં.
• અનસબ્સ્ક્રાઇબ સરળ બનાવો જે મેઇલ સખત રીતે ટ્રાન્ઝેક્શનલ નથી તેના પર, અને તરત જ તેનું માન રાખો.
• નવાં ડોમેઇન ધીમે ધીમે ગરમ કરો. એક નવું ડોમેઇન પહેલા દિવસે હજારો સંદેશા મોકલે તો શંકાસ્પદ લાગે. તમારા ટ્રાન્ઝેક્શનલ મેઇલથી શરૂઆત કરો અને વોલ્યુમ ધીમે ધીમે વધારો.
• યાદીઓ સ્વચ્છ રાખો. હાર્ડ બાઉન્સ તરત દૂર કરો, અને જે લોકોએ લાંબા સમયથી કંઈ ખોલ્યું નથી તેમને દૂર કરવાનો વિચાર કરો.
• માણસની જેમ લખો. સ્પષ્ટ વિષય, ઓળખી શકાય તેવું From નામ, સાદો-ટેક્સ્ટ ભાગ, ઓછી છબીઓ અને તમારા પોતાના ડોમેઇનની લિંક. લિંક શોર્ટનર ટાળો.
• મોનિટર કરો. તમારું ડોમેઇન Google Postmaster Tools માં નોંધાવો અને સમયાંતરે DMARC રિપોર્ટ વાંચો.
• વાસ્તવિક reply-to વાપરો જે કોઈ વાંચે છે. જવાબો એક સારો સંકેત છે, અને ઉપયોગી પ્રતિસાદ પણ.

કોઈને સ્પામ કર્યા વગર ટેસ્ટ કરવું

• જ્યાં હોય ત્યાં તમારા પ્રોવાઇડરનો ટેસ્ટ મોડ કે સેન્ડબોક્સ વાપરો, અથવા તમારી માલિકીના સરનામાં પર મોકલો.
• ડેવલપમેન્ટમાં, વાસ્તવિક વપરાશકર્તાઓને બદલે કેચ-ઓલ ટેસ્ટ ઇનબોક્સ પર મોકલો; વાસ્તવિક લાગતા સરનામાંથી ભરેલો સીડ કરેલો ડેટાબેઝ અજાણતાં અજાણ્યા લોકોને ઇમેઇલ કરવાનો સરળ રસ્તો છે.
• દરેક ટેમ્પ્લેટ થોડા ક્લાયન્ટમાં તપાસો — વેબ પર Gmail, ફોનની મેઇલ એપ, Outlook — અને ડાર્ક મોડમાં પણ.
• ટેસ્ટ ઇમેઇલના મેસેજ હેડર જુઓ: તે બતાવે છે કે SPF, DKIM અને DMARC પાસ થયા કે નહીં.

કાનૂની મૂળભૂત બાબતો

નિયમો દેશ પ્રમાણે અલગ છે. સામાન્ય રીતે, ઘણી જગ્યાએ માર્કેટિંગ ઇમેઇલને સંમતિ જોઈએ, મોકલનારની ઓળખ આપવી પડે, અને કાર્યરત અનસબ્સ્ક્રાઇબ આપવું પડે; ટ્રાન્ઝેક્શનલ ઇમેઇલ જુદી રીતે ગણાય છે, પરંતુ તેમાં માર્કેટિંગ ચુપચાપ ઘુસાડવા માટે તેનો ઉપયોગ ન થવો જોઈએ. જો તમે વેઇટલિસ્ટ પેજ પરથી સરનામાં એકત્ર કરો, તો કહો કે તમે શું મોકલશો અને સંગ્રહશો, અને દરેક વ્યક્તિએ ક્યારે અને કેવી રીતે સાઇન અપ કર્યું. શંકા હોય તો, તમારા વપરાશકર્તાઓ જ્યાં છે ત્યાંના નિયમો તપાસો.

ઇમેઇલ ચેકલિસ્ટ

• મોકલવાનો પ્રોવાઇડર પસંદ કરાયો; API કી સર્વર સિક્રેટ તરીકે સંગ્રહાયેલી
• તમારા પોતાના ડોમેઇન અથવા સબડોમેઇન પરથી મોકલાય છે, મફત મેઇલબોક્સ પરથી નહીં
• SPF, DKIM અને DMARC રેકોર્ડ ઉમેરાયેલા અને પાસ થતા
• ટ્રાન્ઝેક્શનલ અને માર્કેટિંગ મેઇલ અલગ
• મોકલવાનું કતારમાં મૂકાયું અને ફરી પ્રયાસ થાય; પરિણામો લોગ થાય
• બાઉન્સ અને ફરિયાદના વેબહૂક સંભાળાયા
• બિન-ટ્રાન્ઝેક્શનલ મેઇલ પર અનસબ્સ્ક્રાઇબ, તરત માન્ય
• ટેમ્પ્લેટ ઘણા ક્લાયન્ટમાં ટેસ્ટ થયા; ટેસ્ટ મેઇલ ક્યારેય વાસ્તવિક વપરાશકર્તાઓ સુધી ન પહોંચે

Mythex એપમાંથી ઇમેઇલ મોકલવો

Mythex તમે બનાવેલી એપ માટે બિલ્ટ-ઇન ઇમેઇલ મોકલવાની સેવા શામેલ કરતું નથી, તેથી તમે Resend, SendGrid અથવા Postmark જેવો પ્રોવાઇડર લાવો છો. તેની API કી પ્રોજેક્ટ સિક્રેટ તરીકે સંગ્રહો — એજન્ટ ચેટમાં સિક્રેટ કાર્ડ વડે તેને પૂછી શકે છે — અને તમને જોઈતા ઇમેઇલ સાદા શબ્દોમાં માગો. તમારી એપમાંથી ઇમેઇલ મોકલો માં દસ્તાવેજોમાં સ્ટાર્ટર પ્રોમ્પ્ટ છે. જો તમે Pro પર Mythex દ્વારા ડોમેઇન ખરીદ્યું હોય, તો ડોમેઇનની DNS સેટિંગમાં પ્રોવાઇડરના TXT અને CNAME રેકોર્ડ ઉમેરી શકો છો; જુઓ કસ્ટમ ડોમેઇન.

પ્રશ્નો