ನಿಮ್ಮ ಆ್ಯಪ್ನಿಂದ ಇಮೇಲ್ ಕಳುಹಿಸುವುದು ಹೇಗೆ (ಮತ್ತು ಇನ್ಬಾಕ್ಸ್ಗೆ ತಲುಪಿಸುವುದು)
ನಿಮ್ಮ ಆ್ಯಪ್ನಿಂದ ಇಮೇಲ್ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಳುಹಿಸಲು, ನಿಮ್ಮ ಸ್ವಂತ ಮೇಲ್ಬಾಕ್ಸ್ ಬದಲು ಇಮೇಲ್ ಕಳುಹಿಸುವ ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಿ, ನಿಮ್ಮ ಸ್ವಂತ ಡೊಮೇನ್ನ ವಿಳಾಸದಿಂದ ಕಳುಹಿಸಿ, ಮತ್ತು SPF, DKIM ಮತ್ತು DMARC ಎಲ್ಲವೂ ಪಾಸ್ ಆಗುವಂತೆ ಪೂರೈಕೆದಾರರು ನೀಡುವ DNS ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸಿ. ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಇಮೇಲ್ — ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವಿಕೆ, ರಸೀದಿಗಳು, ದೃಢೀಕರಣಗಳು — ಅನ್ನು ಮಾರ್ಕೆಟಿಂಗ್ ಇಮೇಲ್ನಿಂದ ಬೇರ್ಪಡಿಸಿಡಿ, ಪ್ರತಿಯೊಂದನ್ನೂ ಅದನ್ನು ನಿರೀಕ್ಷಿಸುವ ಜನರಿಗೆ ಮಾತ್ರ ಕಳುಹಿಸಿ, ಮತ್ತು ಬೌನ್ಸ್ ಹಾಗೂ ಅನ್ಸಬ್ಸ್ಕ್ರೈಬ್ ನಿರ್ವಹಿಸಿ. ಮೊದಲು ದೃಢೀಕರಣವನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿ; ಆ್ಯಪ್ ಇಮೇಲ್ ಸ್ಪ್ಯಾಮ್ಗೆ ಹೋಗಲು ಇದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ vs ಮಾರ್ಕೆಟಿಂಗ್ ಇಮೇಲ್
ಈ ಎರಡು ರೀತಿಯ ಇಮೇಲ್ ಕೋಡ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣಿಸಿದರೂ, ಇನ್ಬಾಕ್ಸ್ ಪೂರೈಕೆದಾರರು ಮತ್ತು ಕಾನೂನಿನಿಂದ ಬಹಳ ವಿಭಿನ್ನವಾಗಿ ಪರಿಗಣಿಸಲ್ಪಡುತ್ತವೆ.
| ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ | ಮಾರ್ಕೆಟಿಂಗ್ (ಬಲ್ಕ್) | |
|---|---|---|
| ಪ್ರಚೋದನೆ | ಬಳಕೆದಾರರು ಮಾಡಿದ ಯಾವುದೋ ಕ್ರಿಯೆ | ನಿಮ್ಮ ವೇಳಾಪಟ್ಟಿ ಅಥವಾ ಅಭಿಯಾನ |
| ಉದಾಹರಣೆಗಳು | ಸೈನ್-ಅಪ್ ದೃಢೀಕರಣ, ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವಿಕೆ, ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್, ರಸೀದಿ, ಬುಕಿಂಗ್ ಜ್ಞಾಪನೆ, "ಯಾರೋ ಉತ್ತರಿಸಿದ್ದಾರೆ" | ಸುದ್ದಿಪತ್ರ, ಉತ್ಪನ್ನ ಪ್ರಕಟಣೆ, ಪ್ರಚಾರ, ಮರು-ತೊಡಗಿಸಿಕೊಳ್ಳುವಿಕೆ |
| ಸ್ವೀಕರಿಸುವವರು | ಒಬ್ಬರೇ ವ್ಯಕ್ತಿ ಒಂದೊಂದಾಗಿ | ಅನೇಕರು ಒಮ್ಮೆಲೇ |
| ಒಪ್ಪಿಗೆ | ಕ್ರಿಯೆಯಿಂದಲೇ ಸೂಚಿತ | ಅನುಮತಿ ಬೇಕು, ಸುಲಭ ಅನ್ಸಬ್ಸ್ಕ್ರೈಬ್ ಜೊತೆಗೆ |
| ಸಮಯ | ಸೆಕೆಂಡುಗಳಲ್ಲಿ ತಲುಪಬೇಕು | ನಿಮಿಷಗಳಾದರೂ ಪರವಾಗಿಲ್ಲ |
| ಎಲ್ಲಿಂದ ಕಳುಹಿಸಬೇಕು | ನಿಮ್ಮ ಆ್ಯಪ್, API ಮೂಲಕ | ಸುದ್ದಿಪತ್ರ ಟೂಲ್ ಅಥವಾ ಪೂರೈಕೆದಾರರ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ವೈಶಿಷ್ಟ್ಯ |
ಅವುಗಳನ್ನು ಬೇರೆ ಬೇರೆಯಾಗಿ ಇರಿಸಿ. ಮಾರ್ಕೆಟಿಂಗ್ ಅಭಿಯಾನಕ್ಕೆ ಸ್ಪ್ಯಾಮ್ ದೂರುಗಳು ಬಂದರೆ, ಅದೇ ಸ್ಟ್ರೀಮ್ನ ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವಿಕೆಗಳಿಗೂ ಹಾನಿಯಾಗುವುದು ನಿಮಗೆ ಬೇಡ. ಸಾಮಾನ್ಯ ವಿಧಾನವೆಂದರೆ ಪ್ರತ್ಯೇಕ ಸಬ್ಡೊಮೇನ್ಗಳು — ಉದಾಹರಣೆಗೆ ಖಾತೆ ಇಮೇಲ್ಗೆ 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 ಹತ್ತಿರವೂ ಇಲ್ಲದಿದ್ದರೂ, ಬಲ್ಕ್ ನಿಯಮಗಳನ್ನು ಪಾಲಿಸುವುದು ಸುರಕ್ಷಿತವಾಗಿರಲು ಸರಳ ದಾರಿ.
ಆ್ಯಪ್ನಲ್ಲಿ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಸೇರಿಸುವುದು
ಕಳುಹಿಸುವ ಡೊಮೇನ್ ಪರಿಶೀಲಿಸಿದ ನಂತರ:
- API ಕೀಯನ್ನು ಸರ್ವರ್-ಬದಿಯ ಸೀಕ್ರೆಟ್ ಆಗಿ ಸಂಗ್ರಹಿಸಿ — ಎಂದಿಗೂ ಫ್ರಂಟ್-ಎಂಡ್ ಕೋಡ್ನಲ್ಲಿ ಅಲ್ಲ. ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯಬಲ್ಗಳು ಮತ್ತು ಸೀಕ್ರೆಟ್ಗಳು ಎಂದರೇನು ನೋಡಿ.
- ಸರ್ವರ್ನಿಂದ ಕಳುಹಿಸಿ, ಇಮೇಲ್ ಪ್ರಚೋದಿಸುವ ಕ್ರಿಯೆ ಯಶಸ್ವಿಯಾದ ನಂತರ.
- ಇಮೇಲ್ಗಾಗಿ ಬಳಕೆದಾರರನ್ನು ಕಾಯಿಸಬೇಡಿ. ಸರಳ ಆ್ಯಪ್ಗಿಂತ ಹೆಚ್ಚಿನದಕ್ಕೆ, ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಸರದಿಯಲ್ಲಿ ಇರಿಸಿ ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯಗಳಿಗೆ ಮರು-ಪ್ರಯತ್ನಿಸಿ, ಇದರಿಂದ ಪೂರೈಕೆದಾರರ ನಿಧಾನ ಪ್ರತಿಕ್ರಿಯೆ ಸೈನ್-ಅಪ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸುವುದಿಲ್ಲ.
- ಫಲಿತಾಂಶವನ್ನು ಲಾಗ್ ಮಾಡಿ — ಪೂರೈಕೆದಾರರ ಸಂದೇಶ ID ಮತ್ತು ಸ್ಥಿತಿ — ಕೀ ಅಥವಾ ವೈಯಕ್ತಿಕ ಡೇಟಾ ಇರುವ ಪೂರ್ಣ ಸಂದೇಶ ದೇಹವನ್ನು ಲಾಗ್ ಮಾಡದೆ.
- ಬೌನ್ಸ್ ಮತ್ತು ದೂರುಗಳಿಗಾಗಿ ವೆಬ್ಹುಕ್ಗಳನ್ನು ನಿರ್ವಹಿಸಿ: ಹಾರ್ಡ್ ಬೌನ್ಸ್ ಆಗುವ ಅಥವಾ ನಿಮ್ಮನ್ನು ಸ್ಪ್ಯಾಮ್ ಎಂದು ಗುರುತಿಸುವ ವಿಳಾಸಗಳಿಗೆ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ.
ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡ ಒಂದು ಪ್ರಾಂಪ್ಟ್:
[PROVIDER] ಬಳಸಿ ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಇಮೇಲ್ ಕಳುಹಿಸಿ, ಸರ್ವರ್ ಸೀಕ್ರೆಟ್ [ENV_NAME] ಬಳಸಿ, "Acme hello@mail.acme.com" ವಿಳಾಸದಿಂದ. ಸೈನ್-ಅಪ್ ನಂತರ ಸ್ವಾಗತ ಇಮೇಲ್ ಮತ್ತು ಬುಕಿಂಗ್ ಉಳಿಸಿದ ನಂತರ ಬುಕಿಂಗ್ ದೃಢೀಕರಣ ಕಳುಹಿಸಿ. ಟೆಂಪ್ಲೇಟ್ಗಳನ್ನು ಕೋಡ್ನಲ್ಲಿ ಇರಿಸಿ, HTML ಜೊತೆಗೆ ಸರಳ-ಪಠ್ಯ ಆವೃತ್ತಿಯೂ ಇರಲಿ. ಕಳುಹಿಸುವಿಕೆಗಳನ್ನು ಸರದಿಯಲ್ಲಿರಿಸಿ ಮತ್ತು ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯಗಳನ್ನು ಮೂರು ಬಾರಿ ಮರು-ಪ್ರಯತ್ನಿಸಿ. ವೈಫಲ್ಯಗಳನ್ನು ಪೂರೈಕೆದಾರರ ದೋಷದೊಂದಿಗೆ ಲಾಗ್ ಮಾಡಿ, ಆದರೆ API ಕೀಯನ್ನು ಎಂದಿಗೂ ಲಾಗ್ ಮಾಡಬೇಡಿ. ಹಾರ್ಡ್ ಬೌನ್ಸ್ ಮತ್ತು ದೂರುಗಳಲ್ಲಿ ವಿಳಾಸಗಳನ್ನು ಬಳಸಲಾಗದು ಎಂದು ಗುರುತಿಸುವ ವೆಬ್ಹುಕ್ ಎಂಡ್ಪಾಯಿಂಟ್ ಸೇರಿಸಿ, ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಆ ವಿಳಾಸಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಿ.
ಖಾತೆ ಇಮೇಲ್ಗಳು — ದೃಢೀಕರಣ ಲಿಂಕ್ಗಳು, ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್ಗಳು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವಿಕೆಗಳು — ಲಾಗಿನ್ನ ಭಾಗ. ನಿಮ್ಮ ಆ್ಯಪ್ಗೆ ಲಾಗಿನ್ ಸೇರಿಸುವುದು ಹೇಗೆ ಈ ಹರಿವುಗಳು ಹೇಗೆ ಹೊಂದುತ್ತವೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ; ಈ ಲಿಂಕ್ಗಳನ್ನು ಒಮ್ಮೆ-ಮಾತ್ರ ಬಳಸಬಹುದಾದ ಮತ್ತು ಕಡಿಮೆ ಅವಧಿಯದ್ದಾಗಿ ಇರಿಸಿ.
ತಲುಪಿಸುವಿಕೆಯ ಅಭ್ಯಾಸಗಳು
ಪ್ರಮಾಣೀಕರಣವು ನಿಮ್ಮನ್ನು ಪರಿಗಣಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ವರ್ತನೆ ನಿಮ್ಮನ್ನು ಇನ್ಬಾಕ್ಸ್ನಲ್ಲಿ ಉಳಿಸುತ್ತದೆ.
- ಜನರು ನಿರೀಕ್ಷಿಸುವುದನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಿ. ದೃಢೀಕರಿಸಿದ ಸೈನ್-ಅಪ್ಗಳು, ಮಾರ್ಕೆಟಿಂಗ್ಗೆ ಸ್ಪಷ್ಟ ಒಪ್ಪಿಗೆ, ಖರೀದಿಸಿದ ಪಟ್ಟಿಗಳಿಲ್ಲ.
- ಚಂದಾದಾರಿಕೆ ರದ್ದುಗೊಳಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಅಲ್ಲದ ಎಲ್ಲದರ ಮೇಲೆ, ಮತ್ತು ತಕ್ಷಣ ಗೌರವಿಸಿ.
- ಹೊಸ ಡೊಮೇನ್ಗಳನ್ನು ಬೆಚ್ಚಗಾಗಿಸಿ. ಮೊದಲ ದಿನವೇ ಸಾವಿರಾರು ಸಂದೇಶ ಕಳುಹಿಸುವ ಹೊಸ ಡೊಮೇನ್ ಅನುಮಾನಾಸ್ಪದವಾಗಿ ಕಾಣುತ್ತದೆ. ನಿಮ್ಮ ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಮೇಲ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಕ್ರಮೇಣ ಪ್ರಮಾಣ ಹೆಚ್ಚಿಸಿ.
- ಪಟ್ಟಿಗಳನ್ನು ಸ್ವಚ್ಛವಾಗಿಡಿ. ಹಾರ್ಡ್ ಬೌನ್ಸ್ಗಳನ್ನು ತಕ್ಷಣ ತೆಗೆಯಿರಿ, ಮತ್ತು ಬಹಳ ಕಾಲ ಏನನ್ನೂ ತೆರೆಯದವರನ್ನು ತೆಗೆಯುವುದನ್ನು ಪರಿಗಣಿಸಿ.
- ಮನುಷ್ಯರಂತೆ ಬರೆಯಿರಿ. ಸ್ಪಷ್ಟ ವಿಷಯ, ಗುರುತಿಸಬಹುದಾದ From ಹೆಸರು, ಸರಳ-ಪಠ್ಯ ಭಾಗ, ಕಡಿಮೆ ಚಿತ್ರಗಳು ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಡೊಮೇನ್ಗೆ ಲಿಂಕ್ಗಳು. ಲಿಂಕ್ ಶಾರ್ಟ್ನರ್ಗಳನ್ನು ತಪ್ಪಿಸಿ.
- ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ನಿಮ್ಮ ಡೊಮೇನ್ ಅನ್ನು Google Postmaster Tools ನಲ್ಲಿ ನೋಂದಾಯಿಸಿ ಮತ್ತು ಆಗಾಗ್ಗೆ DMARC ವರದಿಗಳನ್ನು ಓದಿ.
- ನಿಜವಾದ ರಿಪ್ಲೈ-ಟು ಬಳಸಿ ಯಾರಾದರೂ ಓದುವಂತಹದ್ದು. ಉತ್ತರಗಳು ಉತ್ತಮ ಸಂಕೇತ ಮತ್ತು ಉಪಯುಕ್ತ ಪ್ರತಿಕ್ರಿಯೆ.
ಯಾರಿಗೂ ಸ್ಪ್ಯಾಮ್ ಮಾಡದೆ ಪರೀಕ್ಷಿಸುವುದು
- ಲಭ್ಯವಿದ್ದರೆ ನಿಮ್ಮ ಪೂರೈಕೆದಾರರ ಟೆಸ್ಟ್ ಮೋಡ್ ಅಥವಾ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಬಳಸಿ, ಅಥವಾ ನಿಮ್ಮದೇ ಆಗಿರುವ ವಿಳಾಸಗಳಿಗೆ ಕಳುಹಿಸಿ.
- ಡೆವಲಪ್ಮೆಂಟ್ನಲ್ಲಿ, ನೈಜ ಬಳಕೆದಾರರ ಬದಲು ಕ್ಯಾಚ್-ಆಲ್ ಟೆಸ್ಟ್ ಇನ್ಬಾಕ್ಸ್ಗೆ ಕಳುಹಿಸಿ; ನೈಜವಾಗಿ ಕಾಣುವ ವಿಳಾಸಗಳಿಂದ ತುಂಬಿದ ಸೀಡ್ ಮಾಡಿದ ಡೇಟಾಬೇಸ್ ಅಪರಿಚಿತರಿಗೆ ಆಕಸ್ಮಿಕವಾಗಿ ಇಮೇಲ್ ಮಾಡಲು ಸುಲಭ ದಾರಿ.
- ಪ್ರತಿ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಹಲವಾರು ಕ್ಲೈಂಟ್ಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿ — ವೆಬ್ನಲ್ಲಿ Gmail, ಫೋನ್ ಮೇಲ್ ಆ್ಯಪ್, Outlook — ಮತ್ತು ಡಾರ್ಕ್ ಮೋಡ್ನಲ್ಲಿ.
- ಪರೀಕ್ಷಾ ಇಮೇಲ್ನ ಹೆಡರ್ಗಳನ್ನು ನೋಡಿ: SPF, DKIM ಮತ್ತು DMARC ಪಾಸ್ ಆಗಿವೆಯೇ ಎಂದು ಅವು ತೋರಿಸುತ್ತವೆ.
ಕಾನೂನಿನ ಮೂಲಭೂತ ಅಂಶಗಳು
ನಿಯಮಗಳು ದೇಶದಿಂದ ದೇಶಕ್ಕೆ ಬದಲಾಗುತ್ತವೆ. ಸ್ಥೂಲವಾಗಿ, ಮಾರ್ಕೆಟಿಂಗ್ ಇಮೇಲ್ಗೆ ಅನೇಕ ಕಡೆ ಒಪ್ಪಿಗೆ ಬೇಕು, ಕಳುಹಿಸುವವರನ್ನು ಗುರುತಿಸಬೇಕು, ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅನ್ಸಬ್ಸ್ಕ್ರೈಬ್ ನೀಡಬೇಕು; ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಇಮೇಲ್ ಬೇರೆಯಾಗಿ ಪರಿಗಣಿಸಲ್ಪಡುತ್ತದೆ, ಆದರೆ ಅದರಲ್ಲಿ ಮಾರ್ಕೆಟಿಂಗ್ ತುರುಕಬಾರದು. ನೀವು ವಿಳಾಸಗಳನ್ನು ವೇಟ್ಲಿಸ್ಟ್ ಪುಟ ಮೂಲಕ ಸಂಗ್ರಹಿಸಿದರೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಯಾವಾಗ ಮತ್ತು ಹೇಗೆ ಸೈನ್ ಅಪ್ ಮಾಡಿದರು ಮತ್ತು ನೀವು ಏನನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ ಮತ್ತು ಸಂಗ್ರಹಿಸುತ್ತೀರಿ ಎಂದು ಹೇಳಿ. ಸಂದೇಹವಿದ್ದರೆ, ನಿಮ್ಮ ಬಳಕೆದಾರರು ಇರುವ ಸ್ಥಳದ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಇಮೇಲ್ ಪರಿಶೀಲನಾಪಟ್ಟಿ
- ಕಳುಹಿಸುವ ಪೂರೈಕೆದಾರರನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ; API ಕೀ ಸರ್ವರ್ ಸೀಕ್ರೆಟ್ ಆಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ
- ನಿಮ್ಮ ಸ್ವಂತ ಡೊಮೇನ್ ಅಥವಾ ಸಬ್ಡೊಮೇನ್ನಿಂದ ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ, ಉಚಿತ ಮೇಲ್ಬಾಕ್ಸ್ನಿಂದ ಅಲ್ಲ
- SPF, DKIM ಮತ್ತು DMARC ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸಲಾಗಿದೆ ಮತ್ತು ಪಾಸ್ ಆಗುತ್ತಿವೆ
- ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಮತ್ತು ಮಾರ್ಕೆಟಿಂಗ್ ಮೇಲ್ ಬೇರ್ಪಟ್ಟಿವೆ
- ಕಳುಹಿಸುವಿಕೆಗಳು ಸರದಿಯಲ್ಲಿವೆ ಮತ್ತು ಮರು-ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ; ಫಲಿತಾಂಶಗಳು ಲಾಗ್ ಆಗಿವೆ
- ಬೌನ್ಸ್ ಮತ್ತು ದೂರು ವೆಬ್ಹುಕ್ಗಳನ್ನು ನಿರ್ವಹಿಸಲಾಗಿದೆ
- ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಅಲ್ಲದ ಮೇಲ್ನಲ್ಲಿ ಅನ್ಸಬ್ಸ್ಕ್ರೈಬ್ ಇದೆ ಮತ್ತು ತಕ್ಷಣ ಗೌರವಿಸಲಾಗುತ್ತಿದೆ
- ಟೆಂಪ್ಲೇಟ್ಗಳನ್ನು ಹಲವು ಕ್ಲೈಂಟ್ಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ; ಪರೀಕ್ಷಾ ಮೇಲ್ ನೈಜ ಬಳಕೆದಾರರನ್ನು ತಲುಪುವುದಿಲ್ಲ
Mythex ಆ್ಯಪ್ನಿಂದ ಇಮೇಲ್ ಕಳುಹಿಸುವುದು
ನೀವು ನಿರ್ಮಿಸುವ ಆ್ಯಪ್ಗಳಿಗೆ Mythex ಅಂತರ್ನಿರ್ಮಿತ ಇಮೇಲ್ ಕಳುಹಿಸುವ ಸೇವೆಯನ್ನು ಒಳಗೊಂಡಿಲ್ಲ, ಆದ್ದರಿಂದ Resend, SendGrid ಅಥವಾ Postmark ನಂತಹ ಪೂರೈಕೆದಾರರನ್ನು ನೀವೇ ತರಬೇಕು. ಅದರ API ಕೀಯನ್ನು ಪ್ರಾಜೆಕ್ಟ್ ಸೀಕ್ರೆಟ್ ಆಗಿ ಸಂಗ್ರಹಿಸಿ — ಏಜೆಂಟ್ ಚಾಟ್ನಲ್ಲಿ ಸೀಕ್ರೆಟ್ಸ್ ಕಾರ್ಡ್ ಮೂಲಕ ಅದನ್ನು ಕೇಳಬಹುದು — ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದ ಇಮೇಲ್ಗಳನ್ನು ಸರಳ ಪದಗಳಲ್ಲಿ ಕೇಳಿ. ಆ್ಯಪ್ನಿಂದ ಇಮೇಲ್ ಕಳುಹಿಸಿ ಡಾಕ್ಸ್ನಲ್ಲಿ ಆರಂಭಿಕ ಪ್ರಾಂಪ್ಟ್ ಇದೆ. ನೀವು Pro ನಲ್ಲಿ Mythex ಮೂಲಕ ಡೊಮೇನ್ ಖರೀದಿಸಿದ್ದರೆ, ಡೊಮೇನ್ನ DNS ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿ ಪೂರೈಕೆದಾರರ TXT ಮತ್ತು CNAME ದಾಖಲೆಗಳನ್ನು ಸೇರಿಸಬಹುದು; ಕಸ್ಟಮ್ ಡೊಮೇನ್ಗಳು ನೋಡಿ.
ಪ್ರಶ್ನೆಗಳು
ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಮತ್ತು ಮಾರ್ಕೆಟಿಂಗ್ ಇಮೇಲ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು?
ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಇಮೇಲ್ ಬಳಕೆದಾರರು ಮಾಡಿದ ಯಾವುದೋ ಕ್ರಿಯೆಯಿಂದ ಹೋಗುತ್ತದೆ ಮತ್ತು ನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತದೆ — ಪಾಸ್ವರ್ಡ್ ಮರುಹೊಂದಿಸುವಿಕೆ, ರಸೀದಿ ಅಥವಾ ಬುಕಿಂಗ್ ದೃಢೀಕರಣ. ಮಾರ್ಕೆಟಿಂಗ್ ಇಮೇಲ್ ನಿಮ್ಮ ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ ಅನೇಕ ಜನರಿಗೆ ಹೋಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಸುದ್ದಿಪತ್ರ ಮತ್ತು ಪ್ರಕಟಣೆಗಳು. ಇವುಗಳ ಒಪ್ಪಿಗೆ ನಿಯಮಗಳು ಬೇರೆ, ಆದ್ದರಿಂದ ಪ್ರತ್ಯೇಕ ಸ್ಟ್ರೀಮ್ ಅಥವಾ ಸಬ್ಡೊಮೇನ್ಗಳಿಂದ ಕಳುಹಿಸುವುದು ಉತ್ತಮ.
ನನ್ನ ಆ್ಯಪ್ನ ಇಮೇಲ್ಗಳು ಏಕೆ ಸ್ಪ್ಯಾಮ್ಗೆ ಹೋಗುತ್ತವೆ?
ಸಾಮಾನ್ಯ ಕಾರಣಗಳು: SPF, DKIM ಮತ್ತು DMARC ಹೊಂದಿಸದ ಕಳುಹಿಸುವ ಡೊಮೇನ್, ತೃತೀಯ ಸೇವೆಯ ಮೂಲಕ Gmail ನಂತಹ ಉಚಿತ ವಿಳಾಸದಿಂದ ಕಳುಹಿಸುವುದು, ಯಾವುದೇ ಖ್ಯಾತಿ ಇಲ್ಲದ ಹೊಸ ಡೊಮೇನ್, ಅಥವಾ ಸ್ಪ್ಯಾಮ್ನಂತೆ ಕಾಣುವ ವಿಷಯ ಮತ್ತು ಲಿಂಕ್ಗಳು. ಮೊದಲು ದೃಢೀಕರಣವನ್ನು ಸರಿಪಡಿಸಿ, ನಂತರ ವಿಷಯ ಮತ್ತು ಪ್ರಮಾಣವನ್ನು ನೋಡಿ.
ನನ್ನ Gmail ಖಾತೆಯಿಂದ ಆ್ಯಪ್ ಇಮೇಲ್ ಕಳುಹಿಸಬಹುದೇ?
ಕೆಲವು ವೈಯಕ್ತಿಕ ಪರೀಕ್ಷಾ ಸಂದೇಶಗಳಿಗೆ ಬಹುಶಃ ಸಾಧ್ಯ, ಆದರೆ ನಿಜವಾದ ಆ್ಯಪ್ಗೆ ಅಲ್ಲ. ನಿಮ್ಮ ಸ್ವಂತ ಡೊಮೇನ್ ಇರುವ ಇಮೇಲ್ ಕಳುಹಿಸುವ ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಿ, ಅದು ನೀಡುವ DNS ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿಸಿ, ಮತ್ತು ಆ ಡೊಮೇನ್ನ ವಿಳಾಸದಿಂದ ಕಳುಹಿಸಿ.
ನನಗೆ DMARC ಬೇಕೇ?
ಆಚರಣೆಯಲ್ಲಿ ಹೌದು. ಸೆಪ್ಟೆಂಬರ್ 2026 ರ ಹೊತ್ತಿಗೆ, ದಿನಕ್ಕೆ 5,000 ಕ್ಕಿಂತ ಹೆಚ್ಚು Gmail ವಿಳಾಸಗಳಿಗೆ ಕಳುಹಿಸುವವರಿಗೆ Google DMARC ಅಗತ್ಯವಿದೆ, ಮತ್ತು DMARC ದಾಖಲೆಯು ನಿಮ್ಮ ಡೊಮೇನ್ ನಕಲಿಯಾಗದಂತೆ ರಕ್ಷಿಸುತ್ತದೆ. ವರದಿಗಳನ್ನು ಪರಿಶೀಲಿಸುವಾಗ p=none ನೀತಿಯಿಂದ ಪ್ರಾರಂಭಿಸುವುದು ಸರಿಯಾಗಿದೆ.