ਆਪਣੀ ਐਪ ਤੋਂ ਈਮੇਲ ਕਿਵੇਂ ਭੇਜੀਏ (ਅਤੇ ਇਨਬਾਕਸ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਾਈਏ)
ਆਪਣੀ ਐਪ ਤੋਂ ਈਮੇਲ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਭੇਜਣ ਲਈ, ਆਪਣੇ ਨਿੱਜੀ ਮੇਲਬਾਕਸ ਦੀ ਥਾਂ ਈਮੇਲ ਭੇਜਣ ਵਾਲਾ ਪ੍ਰਦਾਤਾ ਵਰਤੋ, ਆਪਣੇ ਡੋਮੇਨ ਦੇ ਪਤੇ ਤੋਂ ਭੇਜੋ, ਅਤੇ ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਦਿੱਤੇ DNS ਰਿਕਾਰਡ ਜੋੜੋ ਤਾਂ ਜੋ SPF, DKIM ਅਤੇ DMARC ਤਿੰਨੇ ਪਾਸ ਹੋਣ। ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ ਈਮੇਲ, ਜਿਵੇਂ ਪਾਸਵਰਡ ਰੀਸੈੱਟ, ਰਸੀਦਾਂ ਅਤੇ ਪੁਸ਼ਟੀਆਂ, ਨੂੰ ਮਾਰਕੀਟਿੰਗ ਈਮੇਲ ਤੋਂ ਵੱਖ ਰੱਖੋ, ਹਰ ਇੱਕ ਨੂੰ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਨੂੰ ਭੇਜੋ ਜੋ ਇਸ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਾਊਂਸ ਤੇ ਅਨਸਬਸਕ੍ਰਾਈਬ ਨੂੰ ਸੰਭਾਲੋ। ਪਹਿਲਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਠੀਕ ਕਰੋ; ਐਪ ਈਮੇਲ ਸਪੈਮ ਵਿੱਚ ਜਾਣ ਦਾ ਇਹ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ।
ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ ਬਨਾਮ ਮਾਰਕੀਟਿੰਗ ਈਮੇਲ
ਇਹ ਦੋਵੇਂ ਕਿਸਮਾਂ ਕੋਡ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਲੱਗਦੀਆਂ ਹਨ, ਪਰ ਇਨਬਾਕਸ ਪ੍ਰਦਾਤਾ ਅਤੇ ਕਾਨੂੰਨ ਇਨ੍ਹਾਂ ਨਾਲ ਬਹੁਤ ਵੱਖਰਾ ਵਿਹਾਰ ਕਰਦੇ ਹਨ।
| ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਲ | ਮਾਰਕੀਟਿੰਗ (ਬਲਕ) | |
|---|---|---|
| ਕਿਸ ਕਾਰਨ ਭੇਜੀ ਜਾਂਦੀ ਹੈ | ਯੂਜ਼ਰ ਦੇ ਕਿਸੇ ਕੰਮ ਕਰਕੇ | ਤੁਹਾਡੇ ਸਮੇਂ-ਸਾਰਣੀ ਜਾਂ ਮੁਹਿੰਮ ਅਨੁਸਾਰ |
| ਉਦਾਹਰਨਾਂ | ਸਾਈਨ-ਅੱਪ ਪੁਸ਼ਟੀ, ਪਾਸਵਰਡ ਰੀਸੈੱਟ, ਮੈਜਿਕ ਲਿੰਕ, ਰਸੀਦ, ਬੁਕਿੰਗ ਯਾਦ-ਦਹਾਨੀ, "ਕਿਸੇ ਨੇ ਜਵਾਬ ਦਿੱਤਾ" | ਨਿਊਜ਼ਲੈਟਰ, ਉਤਪਾਦ ਦਾ ਐਲਾਨ, ਪ੍ਰਮੋਸ਼ਨ, ਮੁੜ-ਜੁੜਾਅ |
| ਪ੍ਰਾਪਤਕਰਤਾ | ਇੱਕ ਵੇਲੇ ਇੱਕ ਵਿਅਕਤੀ | ਇੱਕੋ ਵੇਲੇ ਬਹੁਤ ਸਾਰੇ |
| ਸਹਿਮਤੀ | ਕੰਮ ਤੋਂ ਹੀ ਮੰਨੀ ਜਾਂਦੀ ਹੈ | ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ, ਨਾਲ ਆਸਾਨ ਅਨਸਬਸਕ੍ਰਾਈਬ |
| ਸਮਾਂ | ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪਹੁੰਚਣੀ ਚਾਹੀਦੀ ਹੈ | ਕੁਝ ਮਿੰਟ ਠੀਕ ਹਨ |
| ਕਿੱਥੋਂ ਭੇਜਣੀ ਹੈ | ਤੁਹਾਡੀ ਐਪ ਤੋਂ, 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 ਤੱਕ, Google ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ ਲਈ DMARC ਮੰਗਦਾ ਹੈ ਜੋ Gmail ਪਤਿਆਂ ਨੂੰ ਰੋਜ਼ 5,000 ਤੋਂ ਵੱਧ ਸੁਨੇਹੇ ਭੇਜਦੇ ਹਨ, ਅਤੇ DMARC ਰਿਕਾਰਡ ਤੁਹਾਡੇ ਡੋਮੇਨ ਨੂੰ ਜਾਅਲੀ ਵਰਤੋਂ ਤੋਂ ਵੀ ਬਚਾਉਂਦਾ ਹੈ। ਰਿਪੋਰਟਾਂ ਜਾਂਚਦੇ ਹੋਏ p=none ਨੀਤੀ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨਾ ਠੀਕ ਹੈ।