SPF, DKIM at DMARC para sa online store: patakaran ng Gmail at Yahoo

Alamin ang SPF, DKIM at DMARC, ang hinihingi ng Gmail, Yahoo at Outlook.com sa mga sender, ang setup sa Shopify at WooCommerce, at paano umabot sa p=reject.

Pangkat Editoryal ng FixReports12 minutong pagbasa

Para masunod ang mga patakaran ng Gmail at Yahoo para sa mga sender, kailangan ng bawat online store ng SPF o DKIM sa domain na ginagamit nito sa pagpapadala ng email. Ang mga bulk sender naman ay kailangan ng pareho, kasama ang DMARC record na hindi bababa sa p=none, at dapat naka-align ang nakikitang From domain sa SPF o DKIM. Kailangan ding mag-alok ang mga bulk sender ng one-click unsubscribe sa marketing email at panatilihing mas mababa sa 0.3% ang naiulat nilang spam rate. Sa Shopify, ibig sabihin nito ay i-authenticate mo ang iyong sender domain sa admin at magdagdag ng DMARC record; sa WooCommerce, ibig sabihin nito ay magpadala sa pamamagitan ng isang authenticated na email provider. Kapag ipinakita na ng mga DMARC report na pumapasa ang lahat ng lehitimong email mo, puwede mo nang ilipat ang policy papunta sa p=reject.

Mga pangunahing punto

  • Mula Pebrero 1, 2024, hinihingi ng Gmail sa lahat ng sender na mag-set up ng SPF o DKIM, at sa mga bulk sender na mag-set up ng SPF, DKIM at DMARC (Google (magbubukas sa bagong tab)).
  • Itinuturing ka ng Gmail na bulk sender kapag nakapagpadala ka ng halos 5,000 mensahe sa mga personal na Gmail account sa loob ng 24 oras, at hindi nag-e-expire ang status na iyon (Gmail FAQ (magbubukas sa bagong tab)).
  • Simula Nobyembre 2025, pinaigting ng Gmail ang pagpapatupad sa trapikong hindi sumusunod, kasama ang pansamantala at permanenteng pag-reject (Gmail FAQ (magbubukas sa bagong tab)).
  • Mula Mayo 5, 2025, hinihingi na ng Outlook.com ang SPF, DKIM at DMARC sa mga domain na nagpapadala ng higit sa 5,000 email kada araw (Microsoft (magbubukas sa bagong tab)).
  • Pinapayagan ng SPF ang hanggang 10 term na nagku-query sa DNS sa bawat check; kapag lumampas dito, permerror ang resulta (RFC 7208 (magbubukas sa bagong tab)).
  • Na-update ang DMARC noong Mayo 2026: ang RFC 9989 (magbubukas sa bagong tab) na ang pumalit sa RFC 7489, at pinalitan nito ang pct tag ng t.

Ano talaga ang ginagawa ng SPF, DKIM at DMARC?

Inililista ng SPF kung sino ang puwedeng magpadala para sa domain mo, pinipirmahan ng DKIM ang bawat mensahe, at iniuugnay ng DMARC ang dalawa sa From address na nakikita ng mga customer mo.

RecordAno ang pinapatunayan nitoSaan ito nakalagayStandard
SPFAwtorisado ang sending server para sa domain na ginamit sa envelope (MAIL FROM)TXT record sa domainRFC 7208 (magbubukas sa bagong tab)
DKIMPinirmahan ng domain ang mensahe at hindi ito nabago habang ipinapadalaTXT record sa selector._domainkey.example.comRFC 6376 (magbubukas sa bagong tab)
DMARCPumasa ang SPF o DKIM para sa domain na naka-align sa nakikitang From domain; sinasabi nito sa mga receiver kung ano ang gagawin kapag pumalya ito at kung saan ipapadala ang mga reportTXT record sa _dmarc.example.comRFC 9989 (magbubukas sa bagong tab)

Madaling makaligtaan ang alignment. Puwedeng pumasa sa SPF ang email platform mo para sa sarili nitong bounce domain habang ang domain ng store mo ang ipinapakita ng From address. Pumapasa sa SPF ang mensaheng iyon pero babagsak ito sa DMARC maliban kung pinirmahan ang DKIM gamit ang domain mo.

Ano ang hinihingi ng Gmail at Yahoo sa mga sender?

Pareho silang humihingi ng authentication sa bawat sender, at may mas mahigpit silang patakaran para sa mga bulk sender.

Para sa lahat ng sender, hinihingi ng Gmail ang SPF o DKIM, valid na forward at reverse DNS, TLS, formatting ayon sa RFC 5322 at spam rate na mas mababa sa 0.3% sa Postmaster Tools (Google (magbubukas sa bagong tab)). Hinihingi naman ng Yahoo ang kahit SPF o DKIM man lang at spam rate na mas mababa sa 0.3% (Yahoo Sender Hub (magbubukas sa bagong tab)). Para sa mga bulk sender:

RequirementGmailYahoo
SPF at DKIMParehoPareho
DMARCKailangan; puwedeng none ang policyValid na policy na hindi bababa sa p=none, at dapat pumasa ang DMARC
AlignmentNaka-align ang From domain sa SPF o DKIM domainGanoon din; tinatanggap ang relaxed alignment
One-click unsubscribeMga marketing at subscribed na mensahe, ayon sa RFC 8058, kasama ang nakikitang linkList-Unsubscribe header na may one-click support para sa mga marketing at subscribed na mensahe
Pagsunod sa mga unsubscribeSa loob ng 48 oras (rekomendado)Sa loob ng 2 araw
Spam rateMas mababa sa 0.3%; inirerekomenda ng Google na mas mababa sa 0.10%Mas mababa sa 0.3%

May ilang detalyeng mahalaga para sa mga store:

  • Nagbibilang ang Gmail ayon sa domain. Kasama sa bilang para sa 5,000 na limit ang lahat ng mensahe mula sa iisang primary domain, kaya nagsasama-sama ang mga order email, marketing at sagot ng support.
  • Ang mga personal na Gmail account lang ang binibilang. Hindi saklaw ng mga guideline ang mga mensaheng ipinadala sa mga Google Workspace account.
  • Exempted ang transactional na email sa one-click unsubscribe. Kailangan pa rin ng authentication ang mga order confirmation.

Gumagamit ang one-click unsubscribe ng dalawang header na nakasaad sa RFC 8058 (magbubukas sa bagong tab), na humihingi rin ng valid na DKIM signature na sumasaklaw sa mga ito:

List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Para matiyak na idinadagdag ng marketing platform mo ang mga ito, buksan ang raw source ng isa sa sarili mong mga campaign.

Ano ang nagbago pagkatapos ng Pebrero 2024?

Unti-unting humigpit ang pagpapatupad, at gumamit na rin ng katulad na mga patakaran ang ibang mailbox provider.

PetsaPagbabagoSource
Pebrero 2024Nagkabisa ang mga requirement ng Gmail at Yahoo (unti-unting ipinatupad ng Yahoo)Google (magbubukas sa bagong tab), Yahoo (magbubukas sa bagong tab)
Hunyo 2024Gmail: hindi na kwalipikado sa mitigation ang mga bulk sender na may spam rate na higit sa 0.3%Gmail FAQ (magbubukas sa bagong tab)
Hunyo 1, 2024Deadline ng Gmail para sa one-click unsubscribe ng mga sender na may unsubscribe link naGmail FAQ (magbubukas sa bagong tab)
Mayo 5, 2025Mga requirement ng Outlook.com para sa mga domain na nagpapadala ng higit sa 5,000 email kada araw; ayon sa update ng Microsoft noong Abril 29, nire-reject ang mga pumapalyang mensahe gamit ang 550 5.7.515Microsoft (magbubukas sa bagong tab)
Nobyembre 2025Pinaigting ng Gmail ang pagpapatupad, kasama ang pansamantala at permanenteng pag-rejectGmail FAQ (magbubukas sa bagong tab)
Mayo 2026Pinalitan ng RFC 9989 ang RFC 7489 bilang DMARC specificationIETF (magbubukas sa bagong tab)

Saklaw ng mga patakaran ng Outlook.com ang mga consumer address nito (outlook.com, hotmail.com at live.com), at hinihingi nitong pumasa ang SPF at DKIM at magkaroon ng DMARC na hindi bababa sa p=none na naka-align sa SPF o DKIM.

Paano i-set up ang SPF, DKIM at DMARC sa Shopify?

I-authenticate ang sender domain mo sa Shopify admin, saka magdagdag ng isang DMARC record sa DNS host mo.

Ayon sa gabay ng Shopify sa pag-set up ng email (magbubukas sa bagong tab), mula Pebrero 1, 2024, hinihingi ng Gmail at Yahoo ang authenticated na domain at DMARC record para makapagpadala mula sa branded na address. Kung hindi naka-configure ang mga authentication record, papalitan ng Shopify ang sender address mo sa format na store+123@shopifyemail.com. Ang mga hakbang:

  1. Sa Shopify admin, pumunta sa Settings > Notifications.
  2. Sa seksiyong Sender email, i-click ang authenticate your domain.
  3. Idagdag sa DNS provider mo ang bawat CNAME record na ipinapakita. Puwedeng mag-iba ang bilang ng mga ito. Ayon sa Shopify, ang mga record na ito ang bahala sa SPF at DKIM ng sender address mo, at hindi mo na kailangang magdagdag ng mga IP address.
  4. Maghintay ng hanggang 48 oras para tumalab ang mga pagbabago sa DNS.
  5. Magdagdag ng TXT record na may pangalang _dmarc at value na v=DMARC1; p=none;, na ginagamit ng Shopify bilang default.

Kung binili mo ang domain mo sa Shopify o inilipat mo ito roon, ang Shopify na ang mamamahala sa mga record na ito para sa iyo. Nagbababala rin ang Shopify na iisang DMARC record lang ang puwede sa isang domain, at dapat alisin o palitan ng r ang mga strict alignment setting (adkim=s o aspf=s).

Saklaw lang ng authentication ng Shopify ang email na ipinapadala ng Shopify. Kung gumagamit ka ng ibang platform para sa mga campaign, ng help desk, o ng Google Workspace para sa email ng staff, kailangan ng bawat isa ng sarili nitong DKIM setup at, kung ginagamit nito ang domain mo para sa mga bounce, ng sarili nitong SPF entry.

Paano i-set up ang email authentication para sa WooCommerce?

Ipadala ang email ng WooCommerce sa pamamagitan ng isang dedicated na provider na pumipirma gamit ang domain mo, gaya ng inirerekomenda mismo ng dokumentasyon ng WooCommerce.

Nagpapadala ang WooCommerce ng email gamit ang wp_mail() function ng WordPress, at inirerekomenda ng email FAQ (magbubukas sa bagong tab) nito ang isang dedicated na SMTP provider dahil mas maaasahan ito kaysa sa mail function ng sarili mong server. Karaniwang setup:

  1. Pumili ng transactional email provider at i-verify ang domain mo roon. Ibibigay sa iyo ng provider ang mga DKIM record at ang SPF include na ipa-publish mo.
  2. Ikonekta ang WordPress sa provider na iyon gamit ang isang SMTP o API plugin.
  3. Itakda ang From address sa WooCommerce > Settings > Emails sa isang address na nasa sarili mong domain. Nagbababala ang WooCommerce na malamang mapunta sa spam o ma-block ang pampublikong address, gaya ng nasa Gmail o Yahoo.
  4. Mag-publish ng DMARC record sa _dmarc.yourdomain.
  5. Tingnan ang WooCommerce > Status > Logs at i-filter ang source na transactional-emails para makita kung aling mga mensahe ang naipadala o pumalya.

Kung nagpapadala rin ng email para sa domain ang web host mo, i-authenticate ito o i-off. Babagsak sa DMARC ang anumang system na nagpapadala bilang domain mo nang walang naka-align na SPF o DKIM.

Ano ang 10-lookup limit ng SPF at paano ka mananatili sa ilalim nito?

Hanggang 10 term lang na nangangailangan ng DNS query ang puwedeng gamitin ng isang SPF check; kapag lumampas kahit isa, permerror na ang resulta, kaya hindi papasa ang SPF.

Inililista ng RFC 7208, section 4.6.4 (magbubukas sa bagong tab) ang mga term na binibilang: ang mga mechanism na include, a, mx, ptr at exists, at ang redirect modifier. Hindi binibilang ang mga mechanism na ip4, ip6 at all. Binibilang din ang mga include na nasa loob ng iyong mga include, dahil ang limit ay para sa buong evaluation. Inirerekomenda rin ng RFC na limitahan sa dalawa ang mga "void lookup" (mga query na walang ibinabalik na sagot), at sinasabi nitong hindi dapat i-publish ang ptr mechanism.

Mga paraan para manatili sa ilalim ng 10:

  • Alisin ang mga include para sa mga serbisyong hindi mo na ginagamit.
  • Gumamit ng ip4 o ip6 para sa mga server na ikaw mismo ang nagpapatakbo at may fixed na address.
  • Ilipat ang marketing email sa isang subdomain gaya ng news.example.com, na may sarili nitong SPF record at sariling bilang.
  • Huwag kailanman mag-publish ng dalawang SPF record. Ipinagbabawal ng RFC 7208 ang maraming record, at permerror ang ibinabalik ng evaluation.
example.com.        TXT  "v=spf1 include:_spf.google.com include:spf.example-esp.com ~all"
news.example.com.   TXT  "v=spf1 include:spf.example-marketing.com ~all"

Ang spf.example-esp.com at spf.example-marketing.com ay halimbawa lang; palitan ang mga ito ng anumang sabihin ng mga provider mo na gamitin.

Paano ilipat ang DMARC mula p=none papuntang p=reject?

Magsimula sa p=none na may reporting, ayusin ang bawat lehitimong source na lumalabas sa mga report, saka higpitan ang policy.

YugtoRecordLayunin
1. Pagmo-monitorv=DMARC1; p=none; rua=mailto:dmarc@example.comMangolekta ng mga aggregate report kung sino ang nagpapadala bilang domain mo
2. Pag-aayosWalang pagbabagoTiyaking pumapasa ang bawat lehitimong source sa naka-align na SPF o DKIM
3. Quarantinev=DMARC1; p=quarantine; rua=mailto:dmarc@example.comNapupunta sa spam ang email na pumapalya
4. Rejectv=DMARC1; p=reject; rua=mailto:dmarc@example.comTinatanggihan ang email na pumapalya

Lumipat lang sa susunod na yugto kapag ipinakita ng mga report na pumapasa ang store platform, marketing tool, help desk at email ng staff mo. Nakasaad sa RFC 9990 (magbubukas sa bagong tab) ang mga aggregate report. Kung nasa ibang domain ang rua address, gaya ng isang reporting service, kailangang mag-publish ang domain na iyon ng record na nagpapahintulot sa mga report.

Nagmumungkahi ang mga mas lumang gabay na mag-roll out gamit ang pct=25 o pct=50. Inalis ng RFC 9989 ang pct ("historic" na ngayon ang registry entry nito) dahil hindi pare-pareho ang pagpapatupad sa mga value na hindi 0 o 100. Bilang kapalit, hinihiling ng t=y sa mga receiver na ipatupad ang kasunod na mas mababang policy, halimbawa quarantine sa halip na reject. Gamitin ang t=y sa halip na mga partial na porsiyento kung gusto mo ng trial na hakbang.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

Nagbubukas din ng daan sa BIMI ang isang ipinapatupad na policy; ipinapakita ng BIMI ang logo mo sa mga inbox na sumusuporta rito. Para rito, hinihingi ng Gmail ang DMARC na nasa p=quarantine o p=reject at isang Verified Mark Certificate o Common Mark Certificate (Google (magbubukas sa bagong tab)). Para naman sa email na pumapasok sa domain mo, pinapayagan ka ng MTA-STS (RFC 8461 (magbubukas sa bagong tab)) na sabihan ang mga sending server na huwag mag-deliver sa mga mail server mo kapag hindi nag-aalok ang mga ito ng TLS na may pinagkakatiwalaang certificate.

Paano mo masusuri ang mga record ng store mo?

I-query ang tatlong uri ng record gamit ang dig, o gumamit ng checker na babasa sa mga ito para sa iyo.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector._domainkey.example.com

Galing sa provider mo ang DKIM selector, at makikita mo ito sa value na s= ng DKIM-Signature header ng isang mensaheng ipinadala mo. Binabasa ng Ulat sa Email Deliverability ang pampublikong DNS mo, binibilang ang mga SPF lookup, sinusubukan ang mga karaniwang DKIM selector, at sinusuri ang DMARC policy, rua, pct, BIMI at MTA-STS. Nakakatulong ang tamang mga record, pero walang anumang set ng record na garantisadong maglalagay ng email mo sa inbox, dahil tinitimbang din ng mga mailbox provider ang mga reklamo sa spam at ang paraan ng pagpapadala mo.

Mga madalas itanong

Kailangan ko ba ng DMARC kung mas kaunti sa 5,000 email kada araw ang ipinapadala ng store ko?

Sa mga bulk sender lang hinihingi ng Gmail ang DMARC, pero ayon sa Shopify, hinihingi ng Gmail at Yahoo ang authenticated na domain at DMARC record para makapagpadala mula sa branded na address. Mababa ang panganib ng isang p=none record at nagbibigay ito sa iyo ng mga report, kaya dapat mag-publish nito ang karamihan ng mga store.

Puwede bang magkaroon ng dalawang SPF record ang domain ko?

Hindi. Ayon sa RFC 7208, hindi dapat magkaroon ng higit sa isang SPF record ang isang domain, at kapag mayroon, permerror ang ibinabalik ng SPF evaluation. Pagsamahin ang lahat ng sender sa iisang record.

Haharangin ba ng p=reject ang mga order email ng Shopify store ko?

Hindi, kung nakalagay ang mga CNAME record ng Shopify at ipinapakita ng mga DMARC report mo na pumapasa ang email ng Shopify sa naka-align na DKIM. Suriin ang mga report bago lumampas sa p=none, at panatilihing relaxed ang alignment gaya ng inirerekomenda ng Shopify.

Valid pa ba ang pct tag ng DMARC?

Inalis ng RFC 9989, na inilathala noong Mayo 2026, ang pct at ipinakilala nito ang t=y para sa test mode. Humihingi pa rin ng pct=100 ang gabay ng Google sa BIMI, na siyang default kapag wala ang tag, kaya ang hindi paglalagay ng pct ang pinakasimpleng pagpipilian para sa mga bagong record.

Garantisado bang aabot sa inbox ang mga email ko kapag pumasa ang SPF, DKIM at DMARC?

Hindi. Requirement ang authentication, hindi garantiya. Tinitingnan din ng Gmail at Yahoo ang rate ng mga reklamo sa spam, ang paghawak sa mga unsubscribe at ang formatting ng mensahe.

Mga sanggunian

Lahat ng gabay