Base ng kaalaman

Magpadala ng email sa pamamagitan ng iyong sariling Amazon SES account

Ikonekta ang iyong sariling Amazon SES account sa pamamagitan ng SMTP: pagpili ng isang rehiyon at pananatili rito, Easy DKIM, paglabas sa sandbox BAGO ka kumonekta, at kung bakit ang mga kredensyal ng SMTP ay hindi ang iyong AWS access key.

Kakailanganin ninyo ng isang AWS account at access sa DNS ng inyong domain. Ang SES ang pinakamurang opsyon sa listahang ito nang malayuan, at ang may pinakamaraming hakbang.

Ang sariling dokumentasyon ng Amazon: Pag-verify ng isang domain · Pagkuha ng mga kredensyal ng SMTP · Paglabas sa sandbox

⭐ Kumokonekta kami sa SES sa pamamagitan ng SMTP interface nito, hindi ng REST API nito. Iyon ang dahilan kung bakit hinihingan kayo ng isang SMTP username at password sa halip na isang AWS access key. Parehong naghahatid ng eksaktong parehong mensahe ang dalawang paraan; iniiwasan ng SMTP ang isang buong uri ng mga problema sa AWS request-signing na napakahirap i-diagnose mula sa labas, at ito ang interface kung saan naglalathala ang Amazon ng mga kredensyal partikular na upang magamit ito ng mga tool na tulad ng sa amin.

1. Pumili ng isang rehiyon at manatili roon

Ang SES ay panrehiyon. Ang lahat sa ibaba — ang inyong na-verify na domain, ang inyong mga kredensyal, ang inyong quota sa pagpapadala — ay nabibilang sa isang rehiyon ng AWS at hindi umiiral sa alinmang iba pa.

Piliin ang pinakamalapit sa inyong mga kliyente (eu-west-1 para sa Europe, us-east-1 para sa North America) at tandaan ito. Ang pag-verify sa inyong domain sa Ireland at pagkatapos ay paglikha ng mga kredensyal sa Frankfurt ang pinakakaraniwang paraan upang masayang ang isang hapon dito, at ang error na idinudulot nito ay walang sinasabi tungkol sa mga rehiyon.

2. I-verify ang inyong domain

Amazon SES console → Identities → Create identity → Domain. Maglagay ng subdomain tulad ng mail.yourdomain.com.

I-on ang Easy DKIM at piliin ang RSA_2048_BIT. Bibigyan kayo ng SES ng tatlong record ng CNAME:

TypeHost
CNAME<token1>._domainkey.mail.yourdomain.com
CNAME<token2>._domainkey.mail.yourdomain.com
CNAME<token3>._domainkey.mail.yourdomain.com

Idagdag ang lahat ng tatlo. Karaniwang natatapos ang pag-verify sa loob ng isang oras.

⭐ Paganahin din ang isang custom MAIL FROM domain (bounce.mail.yourdomain.com) at idagdag ang mga record ng MX at SPF TXT na hinihingi nito. Kung wala ito, ang inyong envelope sender ay amazonses.com, kaya nag-a-align ang SPF sa Amazon sa halip na sa inyo, at umaasa lamang kayo sa DKIM.

3. Lumabas sa sandbox — ito ang hakbang na nakakaligtaan ng mga tao

⛔⛔ Ang isang bagong SES account ay nasa isang sandbox at maaari lamang magpadala sa mga address na hiwalay ninyong na-verify. Tatanggapin nito ang lahat ng iba pa at wala itong ihahatid sa alinman sa mga iyon.

Ito mismo ang pagkabigo na nilalayong mahuli ng aming hakbang sa pag-verify: sa sandbox, tinatanggap ng SES ang inyong mensahe nang may karaniwang tugon ng tagumpay at pagkatapos ay ibinabasura ito. Kung ive-verify ninyo ang aming setup sa pamamagitan ng pagpapadala ng pagsubok sa isang address na nagkataong na-verify ninyo sa AWS, gagana ito — at pagkatapos ay maglalaho ang bawat mensahe sa isang totoong kliyente.

Account dashboard → Request production access. Nagtatanong ang Amazon kung ano ang inyong ipinapadala at kung paano ninyo pinangangasiwaan ang mga bounce; ang ilang tapat na pangungusap tungkol sa mga transactional notification para sa inyong sariling mga kliyente ay karaniwang naaaprubahan sa loob ng 24 oras.

⭐ Gawin ito bago ninyo ikonekta ang SES dito. Walang ide-debug pagkatapos, dahil walang nabibigo.

4. Gumawa ng mga kredensyal ng SMTP

SES console → SMTP settings → Create SMTP credentials.

Lumilikha ito ng isang IAM user na may send-only permission at nagbibigay sa inyo ng isang SMTP username at isang SMTP password.

⛔ Ang mga ito ay hindi ang inyong AWS access key at secret. Hango ang mga ito mula sa isang IAM secret sa pamamagitan ng isang partikular na algorithm at hindi maaaring pagpalitin ang mga ito. Ang pag-paste ng isang AWS secret access key rito ay magdudulot ng pagkabigo sa pagpapatunay sa bawat pagkakataon, at sasabihin lamang ng error na tinanggihan ang mga kredensyal.

⚠️ Isang beses lamang ipinapakita ang password. I-download ang CSV bago ninyo lisanin ang page.

5. Ikonekta ito sa Zinn®

Buksan ang Email sending sa inyong dashboard:

  • Provider — Amazon SES
  • Send from this domain — mail.yourdomain.com
  • AWS region — ang rehiyon mula sa hakbang 1, hal. eu-west-1
  • SMTP username — mula sa hakbang 4
  • Port — iwanan sa 587
  • SES SMTP password — mula sa hakbang 4

Bumubuo kami ng host para sa inyo (email-smtp.<region>.amazonaws.com), kaya walang hostname na posibleng ma-mistype.

6. Ipadala ang pagsubok at ilagay ang code

Pindutin ang Send test message sa isang inbox sa isang ibang domain na hindi ninyo na-verify sa AWS — mainam ang isang personal na Gmail address, dahil ito ang nagpapatunay na nakalabas na kayo sa sandbox. Basahin ang code at ilagay ito.

Kapag hindi ito gumagana

"Email address is not verified" habang nagpapadala sa isang totoong kliyente — nasa sandbox pa rin kayo. Hakbang 3.

535 Authentication Credentials Invalid — ginamit ninyo ang inyong AWS access key sa halip na mga kredensyal ng SMTP (hakbang 4), o ang mga kredensyal ay nabibilang sa ibang rehiyon mula sa inyong inilagay.

"Maximum sending rate exceeded" — ang isang bagong production account ay nagsisimula sa 14 na mensahe bawat segundo at 50,000 bawat araw. Napakaraming notification niyon, ngunit kung naglilipat kayo ng isang malaking base ng kliyente, humiling muna ng pagtaas.

Gumana ito sa pagsubok at huminto sa produksyon — tingnan ang dashboard ng Reputation ng SES. Awtomatikong ipinapahinto pansamantala ng Amazon ang pagpapadala kapag ang bounce o complaint rate ay lumampas sa kanilang limitasyon, at madali itong lumampas gamit ang isang lumang listahan ng kliyente.

Pinakabago mula sa blog

Ang aming mga isinulat tungkol sa hosting, SEO, at pagpapatakbo ng mga site nang malawakan.

SEO at Pagbuo ng Link mula sa Hosting Layer: Pananaw ng isang Operator sa 2026

Kung paano hinuhubog ng hosting ang pag-index at link equity sa 2026: pagpapanatiling naka-index ang mga page, pagsusuri sa mga lumang domain bago magtayo sa mga ito, pagbuo ng link nang walang bakas ng search engine, at tapat na pagtingin sa kung ano ang kaya at hindi kayang gawin ng imprastraktura para sa SEO.

Basahin ang post →

Paggawang Mabilis at Ligtas sa WordPress: Isang Checklist sa Pagganap at Plugin

Isang praktikal na checklist para sa mabilis at ligtas na WordPress: pag-cache sa antas ng server, isang object cache bawat site, ang iilang plugin na sulit patakbuhin, pagpapanatiling updated sa stack, at ang mga pahina ng WooCommerce na hinding-hindi mo dapat i-cache.

Basahin ang post →

Paano Pumili ng Managed Web Hosting sa 2026: Gabay ng Mamimili

Kung ano talaga ang nagtatangi sa mahusay na pinamamahalaang hosting mula sa isang murang kahon na may control panel — mga migrasyon, backup, paghihiwalay, totoong pag-cache, at tapat na pag-scale — at kung paano ito huhusgahan bago kayo magpasya.

Basahin ang post →

Basahin ang blog →

Kailangan pa rin ng tulong?

Kasama ang suporta sa bawat plan, bukas ang desk 24 oras bawat araw, at maaari kang sumulat sa amin sa alinman sa aming 58 na mga wika — sasagutin ka namin sa iyong wika.

Makipag-ugnayan sa suporta → Lahat ng artikulo →