671,693 ਡੋਮੇਨਾਂ ਦੇ ਸਕੈਨ ਤੋਂ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਅੱਧੇ ਤੋਂ ਵੱਧ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਯੋਗ DMARC ਸੈਟਿੰਗਾਂ ਦੀ ਕਮੀ ਹੈ, ਜਿਸ ਨਾਲ AI-ਅਧਾਰਿਤ ਈਮੇਲ ਏਜੰਟਸ ਸਾਖ ਦੇ ਨੁਕਸਾਨ ਅਤੇ ਡਿਲੀਵਰੀ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਦੇ ਖਤਰੇ ਵਿੱਚ ਹਨ। ਇੱਕ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੰਪਿਊਟਰ ਕੀਤੀ ਗਈ (misconfigured) ਡੋਮੇਨ ਪੂਰੇ ਸਵੈ-ਚਾਲਿਤ ਏਜੰਟਸ ਦੇ ਸਾਂਝੇ ਭੇਜਣ ਦੀ ਸਾਖ (sending reputation) ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ।
ਸਕੈਨ ਨੇ ਕੀ ਪ੍ਰਗਟ ਕੀਤਾ
ਡੇਟਾ ਸੈੱਟ ਤਿੰਨ ਵੱਖ-ਵੱਖ DMARC ਸਥਿਤੀਆਂ ਦਿਖਾਉਂਦਾ ਹੈ:
- Enforcing (p=quarantine ਜਾਂ reject) – 49.31 % ਡੋਮੇਨ
- Monitoring (p=none ਰਿਪੋਰਟਾਂ ਦੇ ਨਾਲ) – 25.61 %
- Inert (p=none ਬਿਨਾਂ ਰਿਪੋਰਟਾਂ ਦੇ) – 25.04 %
Inert ਰਿਕਾਰਡ, ਜਿਨ੍ਹਾਂ ਦੀ ਗਿਣਤੀ 117,000 ਤੋਂ ਵੱਧ ਹੈ, ਸਿਰਫ਼ ਪਲੇਸਹੋਲਡਰ ਹਨ: ਇੱਕ ਵੀਹ-ਅੱਖਰਾਂ ਵਾਲੀ ਸਟ੍ਰਿੰਗ ਜੋ ਕੰਪਲਾਇੰਸ ਚੈੱਕਬਾਕਸ ਨੂੰ ਤਾਂ ਪੂਰਾ ਕਰਦੀ ਹੈ ਪਰ ਕੋਈ ਅਸਲ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ। ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ ਇਹ ਹੈ ਕਿ 166,442 ਡੋਮੇਨ ਇੱਕ DMARC ਪਾਲਿਸੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਪਰ ਇੱਕ ਗੈਰ-ਕਾਰਜਸ਼ੀਲ ਰਿਪੋਰਟਿੰਗ (RUA) ਪਤਾ ਦਿੰਦੇ ਹਨ, ਜੋ ਅਸਲ ਵਿੱਚ ਅੰਨ੍ਹੇਵਾਹ ਕੰਮ ਕਰਨ ਦੇ ਬਰਾਬਰ ਹੈ।
ਸਕੈਨ ਤੋਂ ਪਹਿਲੇ ਮਹੀਨੇ ਵਿੱਚ DMARC ਰਿਕਾਰਡਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਵਿੱਚ ਵਾਧਾ ਦੇਖਿਆ ਗਿਆ, ਫਿਰ ਵੀ ਅਸਲ ਵਿੱਚ ਪਾਲਿਸੀ ਲਾਗੂ ਕਰਨ ਵਾਲਾ ਹਿੱਸਾ ਘਟ ਗਿਆ। ਲਗਭਗ ਤਿੰਨ-ਚੌਥਾਈ ਨਵੀਆਂ ਐਂਟਰੀਆਂ "p=none" ਟੈਗ ਹਨ ਜੋ ਲੌਗਿੰਗ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਨਹੀਂ ਕਰਦੇ।
AI ਏਜੰਟਸ ਲਈ ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਏਜੰਟਸ ਉਹ ਸਾਖ (reputation) ਵਿਰਾਸਤ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਭੇਜਣ ਵਾਲਾ ਡੋਮੇਨ ਰੱਖਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਅਜਿਹੇ ਡੋਮੇਨ ਵਿੱਚ ਏਜੰਟ ਜੋੜਦੇ ਹੋ ਜਿਸਦਾ SPF ਰਿਕਾਰਡ ਕਮਜ਼ੋਰ ਹੈ ਜਾਂ DMARC ਪਾਲਿਸੀ inert ਹੈ, ਤਾਂ ਫਲੈਟ (fleet) ਤੋਂ ਜਾਣ ਵਾਲਾ ਹਰ ਆਊਟਬਾਊਂਡ ਮੈਸੇਜ ਇੱਕ ਸਾਂਝੇ ਰੈਪਿਊਟੇਸ਼ਨ ਬੱਕਟ ਵਿੱਚ ਜੁੜਦਾ ਹੈ। ਇੱਕ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੰਪਿਊਟਰ ਕੀਤੀ ਗਈ ਡੋਮੇਨ ਹਰ ਉਸ ਏਜੰਟ ਲਈ ਬਾਊਂਸ-ਬੈਕ, ਥਰੌਟਲਿੰਗ (throttling), ਜਾਂ ਸਿੱਧੀ ਬਲੈਕਲਿਸਟਿੰਗ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ ਜੋ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
ਲੁਕੀ ਹੋਈਆਂ ਲਾਗਤਾਂ
- ਸਾਖ ਦਾ ਨੁਕਸਾਨ (Reputation loss) ਇੱਕੋ ਡੋਮੇਨ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਸਾਰੇ ਏਜੰਟਸ ਵਿੱਚ ਤੁਰੰਤ ਫੈਲ ਜਾਂਦਾ ਹੈ।
- ਡਿਲੀਵਰੇਬਿਲਟੀ ਵਿੱਚ ਗਿਰਾਵਟ ਸਪੋਰਟ ਟਿਕਟਾਂ ਵਧਾਉਂਦੀ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਦੇ ਵਿਸ਼ਵਾਸ ਨੂੰ ਖਤਮ ਕਰਦੀ ਹੈ।
- ਕੰਪਲਾਇੰਸ ਜੋਖਮ ਉਦੋਂ ਵਧਦਾ ਹੈ ਜਦੋਂ ਸੰਸਥਾਵਾਂ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ ਕਿ ਉਹ ਸਪੂਫਿੰਗ (spoofing) ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਰਹੀਆਂ ਹਨ—ਕੋਈ ਕਾਰਜਸ਼ੀਲ RUA ਪਤਾ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕੋਈ ਫੋਰੈਂਸਿਕ ਡੇਟਾ ਨਹੀਂ।
ਇਸ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਿਆ ਜਾਵੇ
- ਰਿਪੋਰਟਿੰਗ ਪਤੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ – ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ DNS ਕੁਐਰੀ ਚਲਾਓ ਕਿ RUA ਪਤਾ ਰੈਜ਼ੋਲਵ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਮੂਹਿਕ ਰਿਪੋਰਟਾਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਦਿੱਖ (visibility) ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ ਦੁਰਵਰਤੋਂ ਪ੍ਰਤੀ ਪ੍ਰਤੀਕਿਰਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ।
- ਰੋਅ (raw) ਰਿਪੋਰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ – ਘੱਟੋ-ਘੱਟ ਦੋ ਹਫ਼ਤਿਆਂ ਲਈ ਸਿੱਧੇ ਤੌਰ 'ਤੇ XML ਜਾਂ JSON ਰਿਪੋਰਟਾਂ ਪ੍ਰਾਪਤ ਕਰੋ। ਵੈਂਡਰ ਡੈਸ਼ਬੋਰਡ ਅਕਸਰ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਛੁਪਾਉਂਦੇ ਹਨ ਜਾਂ ਡੇਟਾ ਨੂੰ ਅਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਇਕੱਠਾ ਕਰਦੇ ਹਨ ਜੋ ਮਹੱਤਵਪੂਰਨ ਰੁਝਾਨਾਂ ਨੂੰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ।
- SPF includes ਨੂੰ ਛਾਂਟੋ – ਕੋਈ ਵੀ ਅਜਿਹਾ “include” ਮਕੈਨਿਜ਼ਮ ਹਟਾ ਦਿਓ ਜਿਸਦੀ ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਛਾਣ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਪਕ SPF ਰਿਕਾਰਡ ਸਪੂਫਰਾਂ ਨੂੰ ਸੱਦਾ ਦਿੰਦਾ ਹੈ ਅਤੇ DNS ਲੁੱਕਅੱਪ ਗਿਣਤੀ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ SPF ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਫਲਤਾ ਦਾ ਖਤਰਾ ਰਹਿੰਦਾ ਹੈ।
- ਏਜੰਟਸ ਨੂੰ ਇੱਕ ਸਬਡੋਮੇਨ 'ਤੇ ਅਲੱਗ ਕਰੋ – AI-ਜਨਰੇਟਡ ਮੇਲ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਸਬਡੋਮੇਨ ਤੈਅ ਕਰੋ, ਆਪਣੀ DKIM ਕੀ (key) ਬਣਾਓ, ਅਤੇ ਸਖ਼ਤ DMARC ਪਾਲਿਸੀ (p=reject) ਲਾਗੂ ਕਰੋ। ਇਹ ਰੋਕਥਾਮ ਕਿਸੇ ਵੀ ਗਲਤੀ ਨੂੰ ਕਾਰਪੋਰੇਟ ਰੂਟ ਦੀ ਬਜਾਏ ਇੱਕ ਸਿੰਗਲ ਨੇਮਸਪੇਸ ਤੱਕ ਸੀਮਤ ਕਰਦੀ ਹੈ।
ਅਗਲੀ ਡਿਪਲਾਈਮੈਂਟ ਮੀਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਡੋਮੇਨ ਦੇ ਵਿਰੁੱਧ ਇੱਕ ਤੇਜ਼ dig ਕਮਾਂਡ ਗੁੰਮ ਹੋਏ MX, SPF, ਜਾਂ DMARC ਐਂਟਰੀਆਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆ ਸਕਦੀ ਹੈ ਜੋ ਹੋਰਨਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਕੋਡ ਰਿਵਿਊਜ਼ ਵਿੱਚੋਂ ਨਿਕਲ ਸਕਦੀਆਂ ਹਨ।
ਵਿਰੋਧੀ ਨੁਕਤਾ
ਡੇਟਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਇਹ ਸਾਵਧਾਨ ਰੁਖ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਨੁਕਸਾਨਦੇਹ ਹੋ ਜਾਂਦਾ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਨਵੇਂ ਰਿਕਾਰਡ inert ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੀ ਘਾਟ ਡੋਮੇਨ ਨੂੰ ਦੁਰਵਰਤੋਂ ਲਈ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਨਿਗਰਾਨੀ (monitoring) ਤੋਂ ਲਾਗੂ ਕਰਨ (enforcement) ਵੱਲ ਜਾਣਾ ਇੱਕ ਵਾਧਾ-ਅਧਾਰਿਤ ਟੈਸਟ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਬਾਈਨਰੀ ਛਾਲ।
ਮੁੱਖ ਗੱਲ (Takeaway)
ਈਮੇਲ ਭੇਜਣ ਵਾਲੇ AI ਏਜੰਟਸ ਆਪਣੇ ਡੋਮੇਨ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਚੇਨ (authentication chain) ਵਿੱਚ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਲਿੰਕ ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਇੱਕ inert DMARC ਰਿਕਾਰਡ ਜਾਂ ਇੱਕ ਟੁੱਟਿਆ ਹੋਇਆ ਰਿਪੋਰਟਿੰਗ ਪਤਾ ਪੂਰੇ ਫਲੈਟ ਦੀ ਡਿਲੀਵਰੇਬਿਲਟੀ ਅਤੇ ਸਾਖ ਨੂੰ ਬਰਬਾਦ ਕਰ ਸਕਦਾ ਹੈ। ਹੁਣੇ ਆਪਣੇ ਈਮੇਲ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਇਸ ਨੂੰ ਸਾਫ਼ ਕਰੋ, ਅਤੇ ਅਲੱਗ ਕਰੋ—ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਰੇਤ 'ਤੇ ਉਸਾਰੀ ਕਰ ਰਹੇ ਹੋ ਜੋ ਸਪੂਫਿੰਗ ਦੀ ਕੋਸ਼ਿਸ਼ ਹੁੰਦੇ ਹੀ ਢਹਿ ਜਾਵੇਗੀ।