Itigil ang paghuhula sa iyong DNS: isang gabay na developer-friendly sa MX, SPF, DKIM at DMARC

Bakit mahalaga ngayon ang mga email DNS record

Dati, opsyonal ang email authentication. Sa 2026, pangunahing kailangan na ito. Parehong ipinapatupad ng Gmail at Outlook ang SPF at DKIM para sa mga bulk sender, at mabilis nang nagiging mandatory ang DMARC para sa anumang domain na nagpapadala ng transactional email. Kapag mali ang iyong DNS records, hindi dumarating ang iyong mga email—walang bounce, walang babala, katahimikan lang.

Ang problema ay dokumentado ang mga record na ito na parang RFCs, hindi parang mga tool. Karamihan sa mga developer ay nagka-copy-paste ng mga halimbawa mula sa setup guide ng kanilang email provider at umaasang magiging maayos ang lahat. Gumagana iyon hanggang kailanganin mong mag-troubleshoot, magdagdag ng pangalawang sending service, o ipaliwanag sa kliyente kung bakit napupunta sa spam ang mga email mula sa kanilang contact form.

Tatalakayin ng gabay na ito ang MX, SPF, DKIM at DMARC sa pagkakasunod-sunod na malamang mo silang makakaharap, na may sapat na detalye para ma-configure sila nang tama at sapat na konteksto para ma-debug sila kapag nasira.

MX records: kung saan napupunta ang inbound email

Sinasabi ng MX records sa internet kung aling mga mail server ang tumatanggap ng email para sa iyong domain. Sila ang pinakasimple sa apat, pero sila rin ang pinakamadaling ma-misconfigure.

May dalawang bahagi ang isang MX record: priority number at hostname. Mas mababang priority number ang unang sinusubukan. Kung gumagamit ka ng Google Workspace, maaaring ganito ang hitsura ng iyong MX records:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Mahalaga ang trailing dots—senyales ang mga ito na fully qualified ang hostname. Karamihan sa DNS providers ay awtomatikong nagdaragdag nito, pero hindi lahat.

Karaniwang pagkakamali: pagtuturo ng MX records sa A record sa halip na hostname, pagtatakda ng lahat ng priority sa parehong numero (na nagpapawalang-saysay sa pagkakaroon ng backups), o pagkalimutang alisin ang lumang MX records kapag lumipat ka ng provider. Hindi basta nakatengga nang walang epekto ang stale MX records—maaari silang magdulot ng mail loops o split delivery sa dalawang inbox.

Kung nagpapatakbo ka ng sarili mong contact form at gusto mong umiwas sa spam nang hindi umaasa sa third-party services, kapaki-pakinabang na panimulang punto ang pag-unawa kung paano nagiging spam vectors ang forms.

SPF: aling mga server ang pinapayagang magpadala bilang ikaw

Ang SPF (Sender Policy Framework) ay isang TXT record na naglilista ng mga IP address at domain na awtorisadong magpadala ng email sa ngalan ng iyong domain. Ito ang unang check na ginagawa ng karamihan sa mga mail server kapag nakatanggap sila ng mensaheng nagsasabing mula ito sa iyo.

Ganito ang hitsura ng basic SPF record:

v=spf1 include:_spf.google.com ~all

Hatiin natin:

• v=spf1 declares the SPF version
• include:_spf.google.com delegates to Google's SPF record
• ~all is a soft fail—reject mail from unlisted sources, but don't be too strict

Maaari mo ring gamitin ang ip4: o ip6: para i-whitelist ang partikular na mga address, o ang a at mx para i-reference ang A at MX records ng iyong domain. Kinokontrol ng all mechanism sa dulo kung ano ang mangyayari sa mail mula sa mga source na hindi mo inilista: ang -all ay hard fail (reject), ang ~all ay soft fail (markahan bilang kahina-hinala), ang ?all ay neutral (walang opinyon), at ang +all ay free-for-all (huwag gamitin ito).

May dalawang matalim na gilid ang SPF. Una, nasisira ito kapag na-forward ang email, dahil wala sa iyong SPF record ang forwarding server. Pangalawa, may lookup limit na sampung DNS query ang SPF records. Kung magsasama ka ng napakaraming third-party services, lalampas ka sa limit at titigil sa paggana ang SPF. Ang ayos dito ay i-flatten ang iyong SPF record—palitan ang mga include: directive ng aktwal na IP ranges—pero nangangailangan ito ng maintenance kapag binago ng providers ang kanilang IPs.

DKIM: cryptographic proof ng pagkakakilanlan ng sender

Nagdaragdag ang DKIM (DomainKeys Identified Mail) ng digital signature sa iyong outbound email. Tinitingnan ng receiving server ang signature laban sa public key na naka-publish sa iyong DNS. Kung valid ang signature at hindi nabago ang mensahe, pasado ang DKIM.

Hindi tulad ng SPF, nakakalampas sa forwarding ang DKIM, dahil kasama ng mensahe ang signature. Mas flexible din ito—maaari kang magkaroon ng maraming DKIM key para sa iba't ibang sending service, bawat isa ay may sariling selector.

Ganito ang hitsura ng DKIM DNS record:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Arbitrary ang selector (default sa halimbawang ito)—ang iyong email provider ang pumipili nito. Ang p= value ang public key, karaniwang isang mahabang base64-encoded string. Ginagawa ng iyong email provider ang private key at ginagamit ito para pirmahan ang mga outgoing message.

Halos palaging ang iyong email provider ang humahawak sa DKIM setup. Trabaho mo ang kopyahin ang TXT record na ibinibigay nila at i-paste ito sa iyong DNS. Ang mahirap na bahagi ay hindi lahat ng DNS provider ay mahusay humawak ng mahahabang TXT record—puwede nilang i-truncate ang mga ito o hingin na hatiin mo ang value sa maraming quoted string.

Para i-verify na gumagana ang DKIM, magpadala ng test email sa isang Gmail address at tingnan ang headers. Hanapin ang dkim=pass sa Authentication-Results header.

DMARC: policy enforcement at reporting

Pinag-uugnay ng DMARC (Domain-based Message Authentication, Reporting and Conformance) ang SPF at DKIM at sinasabi sa receiving servers kung ano ang gagawin kapag nabigo ang authentication. Pinapagana rin nito ang reporting, para makita mo kung sino ang nagpapadala ng email bilang iyong domain—parehong lehitimo at spoofed.

Ganito ang hitsura ng minimal DMARC record:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none means monitor only—don't reject or quarantine failed messages
• rua=mailto:[email protected] specifies where to send aggregate reports

Kapag kampante ka nang gumagana ang SPF at DKIM, maaari mong higpitan ang policy sa p=quarantine (ipadala sa spam ang mga failure) o p=reject (i-bounce sila nang tuluyan). Maaari ka ring magtakda ng subdomain policy gamit ang sp= at tukuyin ang porsyento ng mga mensaheng lalagyan ng policy gamit ang pct=.

Ang DMARC reports ay mga XML file na ipinapadala araw-araw ng major receivers. Mahaba at mahirap basahin ang raw na mga ito, pero eksaktong sinasabi nila kung aling mga mensahe ang pumasa o nabigo sa authentication at bakit. Kung may nakikita kang lehitimong mail na nare-reject, ipapakita sa iyo ng reports kung aling SPF o DKIM check ang nabibigo.

Isang dapat bantayan: nangangailangan ng alignment ang DMARC. Para sa SPF, dapat tumugma ang domain sa Return-Path header sa domain sa From header (o maging subdomain). Para sa DKIM, dapat tumugma ang d= domain sa DKIM signature sa From domain. Kung gumagamit ka ng third-party sending service, kailangan nilang suportahan ang custom return paths o DKIM signing gamit ang iyong domain, hindi ang sa kanila.

Paano i-audit ang kasalukuyan mong setup

Karamihan sa DNS issues ay hindi nakikita hanggang magdulot sila ng problema. Narito kung paano tingnan ang iyong records bago may masira:

1. I-query ang iyong MX records: dig MX example.com should return your mail server hostnames and priorities. Verify they match your email provider's documentation.

1. Suriin ang SPF syntax: dig TXT example.com and look for the v=spf1 record. Run it through an SPF validator to catch syntax errors and lookup limit violations.

1. I-verify ang DKIM keys: Send a test email and inspect the DKIM-Signature header. Extract the selector and domain, then query dig TXT selector._domainkey.example.com to confirm the public key exists.

1. I-validate ang DMARC policy: dig TXT _dmarc.example.com should return your DMARC record. Make sure rua= points to an address you actually monitor.

1. Subukan end-to-end: Use a service like mail-tester.com or send to a Gmail address and check the full headers. Look for spf=pass, dkim=pass, and dmarc=pass in the Authentication-Results header.

Kung dina-debug mo kung bakit hindi dumarating ang emails, headers ang pinakamahusay mong tool. Karamihan sa mail clients ay nagpapahintulot na makita mo ang raw headers—sa Gmail, buksan ang mensahe, i-click ang tatlong tuldok, at piliin ang 'Show original'. Eksaktong sasabihin sa iyo ng Authentication-Results header kung aling check ang nabigo at bakit.

Kailan gagamit ng subdomain policies

Kung nagpapadala ka ng email mula sa maraming subdomain—halimbawa, newsletter.example.com para sa marketing at app.example.com para sa transactional mail—maaari kang magtakda ng DMARC policies per subdomain. Hinahayaan ka nitong magpatupad ng mahigpit na policies sa mga subdomain na kontrolado mo habang pinananatiling mas maluwag ang policy sa main domain mo.

Ang kapalit nito ay complexity. Kailangan ng bawat subdomain ng sarili nitong SPF, DKIM, at DMARC records, at kailangan mong subaybayan kung aling sending services ang awtorisado para sa aling subdomains. Para sa karamihan ng maliliit na team, mas simple at kasing-secure ang isang domain na maayos ang configuration.

Ano ang gagawin kapag nasira ang authentication

Ang pinakakaraniwang failure mode ay pagdaragdag ng bagong sending service nang hindi ina-update ang DNS. Kung magsisimula kang gumamit ng bagong transactional email provider, kailangan mong idagdag ang kanilang SPF include o IP range, i-configure ang DKIM signing gamit ang iyong domain, at i-verify ang DMARC alignment.

Ang pangalawang pinakakaraniwang issue ay forwarding. Kung ipa-forward ng users ang iyong email sa ibang address, mabibigo ang SPF dahil wala sa iyong SPF record ang forwarding server. Karaniwang nakakalampas sa forwarding ang DKIM, kaya hangga't pasado ang DKIM at pinapayagan ng iyong DMARC policy ang partial alignment, dapat ma-deliver pa rin ang mensahe. Kung may nakikita kang forwarded mail na nare-reject, tingnan ang iyong DMARC policy—ang p=reject na may strict alignment ay sisira sa forwarding.

Ang pangatlong issue ay DNS propagation. Maaaring abutin ng ilang oras bago mag-propagate ang mga pagbabago sa DNS records, at iba't ibang mail server ang nagka-cache ng records sa magkakaibang haba ng oras. Kung kaka-update mo lang ng record at hindi ito gumagana, maghintay ng ilang oras at subukan muli. Maaari mong tingnan ang propagation gamit ang tool tulad ng whatsmydns.net.

Mahahalagang punto

• Nire-route ng MX records ang inbound mail; ina-authenticate ng SPF, DKIM at DMARC ang outbound mail. Magkakaiba ang problemang nilulutas nila at kailangan mo ang apat.
• Nasisira ang SPF sa forwarding at may limit na sampung lookup. Nakakalampas sa forwarding ang DKIM pero nangangailangan ng per-service configuration. Pinag-uugnay sila ng DMARC at pinapagana ang reporting.
• Magsimula sa p=none sa DMARC, i-monitor ang reports nang ilang linggo, pagkatapos ay higpitan sa p=quarantine o p=reject kapag kampante ka nang pumapasa ang lehitimong mail.
• Tahimik ang DNS errors. Subukan ang iyong configuration gamit ang totoong email at inspeksyunin ang headers para kumpirmahing pumapasa ang SPF, DKIM at DMARC.
• Kung nasira ang authentication matapos magdagdag ng bagong sending service, tingnan ang SPF includes, DKIM selectors, at DMARC alignment. Sasabihin sa iyo ng headers kung aling check ang nabigo.

FAQ

Q: Maaari ba akong magkaroon ng maraming SPF records?

A: Hindi. Magdudulot ang maraming SPF records na balewalain silang lahat. Kung kailangan mong mag-authorize ng maraming service, gumamit ng include: directives sa loob ng iisang SPF record, o ilista nang direkta ang IP ranges. Bantayan ang ten-lookup limit.

Q: Kailangan ko ba ng DMARC kung ilang email lang ang ipinapadala ko sa isang araw?

A: Oo. Hindi tungkol sa volume ang DMARC—tungkol ito sa pagpapatunay na ikaw nga ang sinasabi mong ikaw. Nakikinabang kahit ang maliliit na domain sa DMARC dahil pinipigilan nito ang spoofing at nagbibigay sa iyo ng visibility sa delivery issues. Magsimula sa p=none at isang reporting address.

Q: Ano ang mangyayari kung parehong mabigo ang DKIM at SPF pero mukhang lehitimo ang email?

A: Depende ito sa iyong DMARC policy. Kung p=none, madi-deliver ang mail na may babala. Kung p=quarantine, mapupunta ito sa spam. Kung p=reject, iba-bounce ito. Ito ang dahilan kung bakit dapat mong i-monitor ang DMARC reports bago magpatupad ng mahigpit na policy—maaaring may lehitimong senders ka na hindi mo alam.

Q: Maaari ko bang gamitin ang parehong DKIM key para sa maraming domain?

A: Technically, oo, pero huwag. Dapat may sariling DKIM key pair ang bawat domain. Mas pinahihirap ng pagbabahagi ng keys ang rotation at pinalalaki ang blast radius kapag na-compromise ang isang private key.

Q: Gaano kadalas ko dapat i-rotate ang DKIM keys?

A: Walang universal rule, pero makatwiran ang isang beses sa isang taon para sa karamihan ng domains. Kung naghihinala kang na-compromise ang isang key, i-rotate agad. Siguraduhing i-publish ang bagong public key sa DNS bago ka magsimulang mag-sign gamit ang bagong private key, at iwan ang lumang key sa DNS nang ilang araw pagkatapos ng rotation para ma-handle ang delayed mail.

<!-- tool-cta:start -->

💡 Subukan ito: Suriin ang naka-publish na patakaran ng anumang domain gamit ang DMARC Lookup upang makita kung paano nagkakatugma sa praktika ang mga MX, SPF at DMARC record.

<!-- tool-cta:end -->

Sources

• RFC 7208: Sender Policy Framework (SPF) — Ang SPF specification, kabilang ang syntax rules at ten-lookup limit.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Ang DKIM specification, na sumasaklaw sa signature generation at verification.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Ang DMARC specification, kabilang ang policy syntax at aggregate reporting format.
• Google Workspace: Prevent spoofing and spam — Praktikal na gabay sa SPF, DKIM at DMARC configuration para sa Google Workspace domains.