உங்கள் app-இலிருந்து email அனுப்புவது எப்படி (inbox-இல் சேர்வதற்காக)

உங்கள் app-இலிருந்து email-ஐ நம்பகமாக அனுப்ப, உங்கள் சொந்த mailbox-க்குப் பதிலாக ஒரு email sending provider-ஐப் பயன்படுத்துங்கள்; உங்கள் சொந்த domain-இல் உள்ள முகவரியிலிருந்து அனுப்புங்கள்; provider தரும் DNS பதிவுகளைச் சேர்த்து SPF, DKIM, DMARC மூன்றும் தேர்ச்சி பெறுவதை உறுதி செய்யுங்கள். Transactional email — கடவுச்சொல் மீட்டமைப்பு, ரசீதுகள், உறுதிப்படுத்தல்கள் — ஐ marketing email-இலிருந்து பிரித்து வையுங்கள்; ஒவ்வொன்றையும் அதை எதிர்பார்ப்பவர்களுக்கு மட்டுமே அனுப்புங்கள்; bounce-களையும் unsubscribe-களையும் கையாளுங்கள். முதலில் authentication-ஐ சரியாக அமையுங்கள்; app email spam-இல் போவதற்கு இதுவே அடிக்கடி காரணம்.

Transactional vs marketing email

இந்த இரண்டு வகை emails code-இல் ஒரே மாதிரி தெரிந்தாலும், inbox providers-உம் சட்டமும் அவற்றை மிகவும் வேறுபட்டு நடத்துகின்றன.

இவற்றைப் பிரித்து வையுங்கள். ஒரு marketing campaign-க்கு spam புகார்கள் வந்தால், அதே stream-இலிருந்து செல்லும் கடவுச்சொல் மீட்டமைப்புகள் பாதிக்கப்படுவதை நீங்கள் விரும்ப மாட்டீர்கள். பொதுவான அணுகுமுறை தனித்தனி subdomain-கள் — கணக்கு emails-க்கு mail.example.com, newsletter-களுக்கு news.example.com போல. சில providers இவற்றை உள்ளேயே பிரிக்கின்றன. உதாரணமாக Postmark, செப்டம்பர் 2026 நிலவரப்படி, தங்கள் transactional மற்றும் broadcast "message streams"-ஐ தனித்தனி sending infrastructure-இல் இயக்குவதாக விவரிக்கிறது.

Provider-ஐத் தேர்ந்தெடுப்பது

உங்கள் app தனது சொந்த server-இலிருந்து email-ஐ நேரடியாக அனுப்பக் கூடாது. Sending providers infrastructure, IP நற்பெயர், மீண்டும் முயற்சிகள், bounce செயலாக்கம் ஆகியவற்றைக் கவனித்துக்கொள்கின்றன. அறியப்பட்ட தேர்வுகள்: Postmark, Resend, SendGrid, Amazon SES, Mailgun. ஒவ்வொன்றுக்கும் HTTP API மற்றும் SMTP அணுகல் உண்டு; விலைகளும் திட்டங்களும் மாறக்கூடியவை, எனவே அவற்றின் சொந்த தளங்களில் ஒப்பிடுங்கள்.

ஒப்பிட வேண்டியவை:

• கவனம். சில providers transactional email-இல் மட்டும் கவனம் செலுத்துகின்றன; மற்றவை transactional மற்றும் marketing இரண்டையும் இணைக்கின்றன.
• Developer அனுபவம். தெளிவான API, உங்கள் மொழிக்கான அதிகாரப்பூர்வ libraries, ஒவ்வொரு செய்தி வழங்கப்பட்டதா, bounce ஆனதா, spam எனக் குறிக்கப்பட்டதா என்று காட்டும் பயனுள்ள logs.
• Webhooks bounces, புகார்கள், deliveries-க்கு, உங்கள் app அவற்றுக்கு பதிலளிக்க.
• Templates — provider-இல் சேமிக்கப்பட்டவை, அல்லது உங்கள் code-இல். Code-இல் வைத்தால் அவை versioned ஆகும், சோதிக்கவும் முடியும்.
• பகுதியும் தரவு கையாளலும், தரவு எங்கே செயலாக்கப்படுகிறது என்பதில் தேவைகள் இருந்தால்.
• உங்கள் அளவில் செலவு, இலவச tier-ஐத் தாண்டினால் என்ன ஆகும் என்பதும் சேர்த்து.

பட்டியலுக்கான newsletter-களுக்கு, உங்கள் app-க்குள்ளேயே campaign அம்சங்களை உருவாக்குவதை விட ஒரு பிரத்யேக newsletter அல்லது email marketing கருவி பெரும்பாலும் சிறந்தது.

உங்கள் sending domain-ஐ அமையுங்கள்

உங்கள் சொந்த domain-இலிருந்து அனுப்புங்கள் — hello@example.com, Gmail அல்லது Outlook முகவரி அல்ல. மூன்றாம் தரப்பு சேவை வழியாக இலவச mailbox முகவரியிலிருந்து அனுப்படும் mail authentication சோதனைகளில் தோல்வியடைந்து வடிகட்டப்பட வாய்ப்பு அதிகம்.

அனுப்புவதற்கென ஒரு subdomain-ஐக் கவனியுங்கள். உதாரணமாக Resend, நற்பெயரைத் தனிமைப்படுத்த updates.example.com போன்ற subdomain-களிலிருந்து அனுப்ப பரிந்துரைக்கிறது (செப்டம்பர் 2026 நிலவரப்படி). இது email DNS பதிவுகளை உங்கள் முக்கிய தளத்தின் பதிவுகளிலிருந்து தனியாக வைத்திருக்கவும் உதவுகிறது.

உங்கள் domain-இன் DNS நிர்வகிக்கப்படும் இடத்தில் சேர்க்க வேண்டிய DNS பதிவுகளை provider தரும். DNS உங்களுக்குப் புதிதாக இருந்தால், domains மற்றும் DNS எப்படி வேலை செய்கின்றன என்பது பதிவுகளை முதலில் விளக்குகிறது.

SPF

SPF (Sender Policy Framework) என்பது உங்கள் domain-க்காக email அனுப்பக்கூடிய servers-ஐ பட்டியலிடும் TXT பதிவு. பெறும் servers, அனுப்பும் server பட்டியலில் உள்ளதா என்று சரிபார்க்கின்றன.

• ஒரு domain-க்கு ஒரே ஒரு SPF பதிவு மட்டுமே இருக்க வேண்டும். ஒரு provider சேர்த்தால், இரண்டாவது பதிவைச் சேர்க்காமல் அதை ஏற்கெனவே உள்ள பதிவில் இணையுங்கள்.
• மதிப்பிடும்போது SPF அதிகபட்சம் 10 DNS lookups வரை அனுமதிக்கும்; நீண்ட include: சங்கிலிகள் இதை மீறி தோல்விகளை ஏற்படுத்தலாம்.
• பல providers, நீங்கள் உருவாக்கச் சொல்லும் ஒரு return-path subdomain-இல் SPF-ஐ அமைக்கின்றன; அப்போது உங்கள் முக்கிய SPF பதிவை நீங்கள் தொட வேண்டியதே இல்லை.

DKIM

DKIM (DomainKeys Identified Mail) ஒவ்வொரு செய்திக்கும் ஒரு cryptographic கையொப்பத்தைச் சேர்க்கிறது. Provider ஒரு private key மூலம் கையொப்பமிடுகிறது; பொருந்தும் public key-ஐ நீங்கள் DNS பதிவாக (provider-ஐப் பொறுத்து TXT அல்லது CNAME) வெளியிடுகிறீர்கள். செய்தி அங்கீகரிக்கப்பட்ட அனுப்புநரிடமிருந்து வந்ததா, வழியில் மாற்றப்படவில்லையா என்று பெறுநர்கள் கையொப்பத்தைச் சரிபார்க்கின்றனர்.

உங்கள் provider-இன் "domain சரிபார்ப்பு" படி பெரும்பாலும் DKIM பற்றியதுதான். இதைத் தவிர்க்காதீர்கள்.

DMARC

DMARC மற்ற இரண்டையும் ஒன்றிணைக்கிறது. இது _dmarc.yourdomain.com இல் உள்ள ஒரு TXT பதிவு, இது பெறுநர்களிடம் சொல்கிறது:

• Alignment: தெரியும் From முகவரியின் domain, SPF அல்லது DKIM-இல் தேர்ச்சி பெற்ற domain-உடன் பொருந்த வேண்டும்.
• கொள்கை: தோல்வியடையும் mail-க்கு என்ன செய்வது — p=none (அறிக்கை மட்டும்), p=quarantine (சந்தேகத்திற்குரியதாக கருது, பெரும்பாலும் spam), அல்லது p=reject.
• அறிக்கைகள்: மொத்த அறிக்கைகள் எங்கே அனுப்பப்பட வேண்டும் (rua=), உங்கள் domain-ஆக யார் அனுப்புகிறார்கள் என்று பார்க்க.

நல்ல வழி p=none மற்றும் ஒரு அறிக்கை முகவரியுடன் தொடங்குவது; உங்கள் சட்டபூர்வமான mail தேர்ச்சி பெறுவதை உறுதி செய்த பிறகு quarantine-க்கும், பின்னர் reject-க்கும் மாறுங்கள். கடுமையான கொள்கை, மற்றவர்கள் உங்கள் domain-ஐ போலியாக பயன்படுத்துவதை மிகவும் கடினமாக்கும்.

Gmail-இன் தேவைகள்

செப்டம்பர் 2026 நிலவரப்படி, Google-இன் sender வழிகாட்டுதல்கள் சொல்வது:

• எல்லா அனுப்புநர்களும் தனிப்பட்ட Gmail கணக்குகளுக்கு SPF அல்லது DKIM, அனுப்பும் servers-க்கு செல்லுபடியாகும் forward மற்றும் reverse DNS, TLS, மற்றும் Postmaster Tools-இல் 0.3%-க்குக் கீழே spam விகிதம் வைத்திருக்க வேண்டும்.
• Bulk அனுப்புநர்கள் (ஒரு நாளைக்கு Gmail-க்கு 5,000-க்கும் மேல்) SPF மற்றும் DKIM, ஒரு DMARC பதிவு (p=none கொள்கை அனுமதிக்கப்படும்), From domain alignment, மற்றும் marketing அல்லது சந்தா செய்த செய்திகளில் ஒரு-கிளிக் unsubscribe மற்றும் தெரியும் unsubscribe link ஆகியவற்றைக் கொண்டிருக்க வேண்டும்.

Server பக்க பகுதிகளை உங்கள் provider கவனிக்கிறது. DNS பதிவுகளும் unsubscribe கையாளுதலும் உங்கள் பொறுப்பு. நீங்கள் ஒரு நாளைக்கு 5,000-க்கு அருகிலும் இல்லாவிட்டாலும், bulk விதிகளைப் பூர்த்தி செய்வதே பாதுகாப்பாக இருப்பதற்கான எளிய வழி.

Sending-ஐ உங்கள் app-இல் இணையுங்கள்

Domain சரிபார்க்கப்பட்ட பிறகு:

1. API key-ஐ சேமியுங்கள் server பக்க secret ஆக — ஒருபோதும் front-end code-இல் அல்ல. environment variables மற்றும் secrets என்றால் என்ன என்று பாருங்கள்.
2. Server-இலிருந்து அனுப்புங்கள், email-ஐத் தூண்டும் செயல் வெற்றியடைந்த பின்.
3. பயனர் email-க்காகக் காத்திருக்க விடாதீர்கள். எளிய app-ஐத் தாண்டிய எதற்கும், அனுப்புவதை வரிசையில் வைத்து தற்காலிக தோல்விகளில் மீண்டும் முயற்சியுங்கள்; provider மெதுவாக பதிலளித்தால் sign-up மெதுவாகக் கூடாது.
4. முடிவை பதிவு செய்யுங்கள் — provider-இன் message ID மற்றும் நிலை — key-யையோ தனிப்பட்ட தரவு கொண்ட முழு செய்தி உடல்களையோ பதிவு செய்யாமல்.
5. Bounces மற்றும் புகார்களுக்கான webhooks-ஐ கையாளுங்கள்: hard bounce ஆகும் அல்லது உங்களை spam எனக் குறிக்கும் முகவரிகளுக்கு அனுப்புவதை நிறுத்துங்கள்.

அடிப்படைகளை உள்ளடக்கும் ஒரு prompt:

[PROVIDER] மூலம் server secret [ENV_NAME]-ஐப் பயன்படுத்தி transactional email அனுப்பு, "Acme hello@mail.acme.com" என்ற முகவரியிலிருந்து. Sign-up-க்குப் பின் வரவேற்பு email-ம், முன்பதிவு சேமிக்கப்பட்ட பின் முன்பதிவு உறுதிப்படுத்தலும் அனுப்பு. Templates-ஐ code-இல் வைத்திரு, HTML உடன் ஒரு plain-text பதிப்பும் சேர்த்து. அனுப்புவதை வரிசையில் வைத்து தற்காலிக தோல்விகளை மூன்று முறை வரை மீண்டும் முயற்சி செய். தோல்விகளை provider-இன் பிழையுடன் பதிவு செய், ஆனால் API key-ஐ ஒருபோதும் பதிவு செய்யாதே. Hard bounce மற்றும் புகார்களில் முகவரிகளை அனுப்ப முடியாதவை என குறிக்கும் ஒரு webhook endpoint சேர், எதிர்காலத்தில் அந்த முகவரிகளைத் தவிர்.

சரிபார்ப்பு links, magic links மற்றும் கடவுச்சொல் மீட்டமைப்புகள் போன்ற account emails login-இன் ஒரு பகுதி. இந்த flows எப்படி ஒன்றிணைகின்றன என்பதை உங்கள் app-க்கு login சேர்ப்பது எப்படி விளக்குகிறது; இந்த links ஒருமுறை மட்டுமே பயன்படும்படியும் குறுகிய ஆயுளுடையதாகவும் இருக்கட்டும்.

Deliverability பழக்கங்கள்

Authentication உங்கள் mail-ஐ கவனிக்கத்தக்கதாக்கும். நடத்தை உங்களை inbox-இல் வைத்திருக்கும்.

• மக்கள் எதிர்பார்ப்பதை மட்டுமே அனுப்புங்கள். உறுதிப்படுத்தப்பட்ட sign-up-கள், marketing-க்கு தெளிவான opt-in, விலைக்கு வாங்கிய பட்டியல்கள் வேண்டாம்.
• கண்டிப்பாக transactional அல்லாத எதிலும் unsubscribe செய்வதை எளிதாக்குங்கள், உடனே மதியுங்கள்.
• புதிய domain-களை சூடாக்குங்கள். முதல் நாளிலேயே ஆயிரக்கணக்கான செய்திகளை அனுப்பும் புதிய domain சந்தேகமாகத் தெரியும். உங்கள் transactional mail-இலிருந்து தொடங்கி, அளவை படிப்படியாக அதிகரியுங்கள்.
• பட்டியல்களை சுத்தமாக வையுங்கள். Hard bounces-ஐ உடனே நீக்குங்கள்; நீண்ட காலமாக எதையும் திறக்காதவர்களையும் நீக்கக் கருதுங்கள்.
• மனிதர் எழுதுவது போல எழுதுங்கள். தெளிவான subject, அடையாளம் காணக்கூடிய From பெயர், plain-text பகுதி, சில படங்கள், உங்கள் சொந்த domain-க்கான links. Link shorteners-ஐத் தவிர்க்கவும்.
• கண்காணியுங்கள். உங்கள் domain-ஐ Google Postmaster Tools-இல் பதிவு செய்து, அவ்வப்போது DMARC அறிக்கைகளைப் படியுங்கள்.
• யாராவது படிக்கும் உண்மையான reply-to பயன்படுத்துங்கள். பதில்கள் நல்ல சமிக்ஞையும் பயனுள்ள கருத்தும்.

யாரையும் spam செய்யாமல் சோதிப்பது

• உங்கள் provider-க்கு test mode அல்லது sandbox இருந்தால் அதைப் பயன்படுத்துங்கள், அல்லது நீங்களே வைத்திருக்கும் முகவரிகளுக்கு அனுப்புங்கள்.
• Development-இல், உண்மையான பயனர்களுக்குப் பதிலாக catch-all test inbox-க்கு அனுப்புங்கள்; உண்மையான தோற்றமுள்ள முகவரிகள் நிறைந்த seed database, அந்நியர்களுக்குத் தவறுதலாக email அனுப்புவதற்கான எளிய வழி.
• ஒவ்வொரு template-ஐயும் சில clients-இல் சரிபாருங்கள் — இணையத்தில் Gmail, தொலைபேசி mail app, Outlook — dark mode-உம் சேர்த்து.
• ஒரு test email-இன் message headers-ஐப் பாருங்கள்: SPF, DKIM, DMARC தேர்ச்சி பெற்றனவா என்று அவை காட்டும்.

சட்ட அடிப்படைகள்

விதிகள் நாட்டுக்கு நாடு வேறுபடும். பொதுவாக, marketing email பல இடங்களில் ஒப்புதல் தேவைப்படுத்துகிறது, அனுப்புநரை அடையாளம் காட்ட வேண்டும், வேலை செய்யும் unsubscribe வழங்க வேண்டும்; transactional email வேறுவிதமாக நடத்தப்படுகிறது, ஆனால் அதன் மூலம் marketing-ஐ நுழைக்கப் பயன்படுத்தக் கூடாது. நீங்கள் waitlist பக்கத்திலிருந்து முகவரிகளைச் சேகரித்தால், ஒவ்வொருவரும் எப்போது எப்படி பதிவு செய்தார்கள், என்ன அனுப்புவீர்கள், என்ன சேமிப்பீர்கள் என்பதைத் தெளிவாகச் சொல்லுங்கள். சந்தேகம் இருந்தால், உங்கள் பயனர்கள் இருக்கும் இடத்தின் விதிகளைச் சரிபாருங்கள்.

Email checklist

• Sending provider தேர்வு; API key server secret ஆக சேமிக்கப்பட்டது
• உங்கள் சொந்த domain அல்லது subdomain-இலிருந்து அனுப்புதல், இலவச mailbox அல்ல
• SPF, DKIM, DMARC பதிவுகள் சேர்க்கப்பட்டு தேர்ச்சி பெறுகின்றன
• Transactional மற்றும் marketing mail பிரிக்கப்பட்டுள்ளன
• அனுப்புதல்கள் வரிசையில் வைக்கப்பட்டு மீண்டும் முயற்சிக்கப்படுகின்றன; முடிவுகள் பதிவு செய்யப்படுகின்றன
• Bounce மற்றும் புகார் webhooks கையாளப்படுகின்றன
• Transactional அல்லாத mail-இல் unsubscribe உள்ளது, உடனே மதிக்கப்படுகிறது
• Templates பல clients-இல் சோதிக்கப்பட்டன; சோதனை mail ஒருபோதும் உண்மையான பயனர்களைச் சென்றடையாது

Mythex app-இலிருந்து email அனுப்புவது

நீங்கள் உருவாக்கும் app-களுக்கு Mythex உள்ளமைக்கப்பட்ட email அனுப்பும் சேவையை வழங்கவில்லை; எனவே Resend, SendGrid அல்லது Postmark போன்ற provider-ஐ நீங்கள் கொண்டு வருகிறீர்கள். அதன் API key-ஐ project secret ஆக சேமியுங்கள் — chat-இல் secrets card மூலம் agent அதைக் கேட்கலாம் — தேவையான emails-ஐ எளிய சொற்களில் கேளுங்கள். Starter prompt-க்கு ஆவணங்களில் app-இலிருந்து email அனுப்பு பாருங்கள். Pro-வில் Mythex மூலம் domain வாங்கியிருந்தால், domain-இன் DNS அமைப்புகளில் provider-இன் TXT மற்றும் CNAME பதிவுகளைச் சேர்க்கலாம்; பார்க்க custom domains.

கேள்விகள்