How can I prevent Microsoft Defender from triggering unwanted one-click unsubscribes?
Published 3 Jun 2025
Updated 5 Oct 2026
12 min read
Summarize with
Updated on 5 Oct 2026: We clarified RFC 8058 request handling, Safe Links exclusions, and tests for accidental unsubscribes.
You prevent accidental unsubscribes caused by Microsoft Defender fetching URLs by keeping GET and HEAD requests read-only. The unsubscribe link in the email body should open a confirmation or preference page. The body-link unsubscribe should happen only after the recipient submits an HTML form that sends a POST request. For list-header one-click unsubscribe, use RFC 8058 with List-Unsubscribe and List-Unsubscribe-Post, so mailbox-provider UI actions can unsubscribe correctly while scanner GET requests do not change subscriber status.
The wrong fix is trying to identify every Microsoft Defender for Office 365 click by User-Agent, IP address, timing, or Safe Links rewrite pattern. Those signals change, and security scanners use infrastructure that is hard to separate from real users at the point of click. Treat scanner detection as reporting data, not as the control that protects the unsubscribe action.
- Keep GET and HEAD harmless: a link visit can display preferences or return metadata, but it must not change subscription state.
- Use the right POST: a body-link unsubscribe needs a form submission, while header one-click needs the RFC 8058 key-value pair.
- Keep headers separate: one-click belongs in the list headers, while the visible body link should lead to a web page.
- Measure scanners: keep automated clicks out of engagement, churn, and consent reporting whenever you can identify them.
Make unsubscribe links safe to scan
The safest unsubscribe design separates discovery from action. Microsoft Defender, Safe Links, and other scanners can discover and open URLs. That is expected behavior. Your system should assume that any link in the email body and any URL in List-Unsubscribe can be fetched before the recipient touches the message.
This setup still gives recipients an easy unsubscribe path. It just avoids using a raw body-link click as consent. The body link opens a page with a clear unsubscribe button. The header path advertises one-click support to mailbox providers through RFC 8058. The server suppresses the address after a body-form POST or after the mailbox provider sends the RFC 8058 POST in response to the user's unsubscribe request.
Safe list unsubscribe headerstext
List-Unsubscribe: <https://example.com/u/abc>, <mailto:unsubscribe@example.com?subject=unsubscribe> List-Unsubscribe-Post: List-Unsubscribe=One-Click
Keep GET and HEAD harmless
GET and HEAD requests must not change subscription state. GET can display the unsubscribe page or preselect a list; HEAD returns metadata without a response body. Neither should write to the suppression list. RFC 9110 defines both as safe HTTP methods.
- Scanner visit: render the page and record a non-suppressing click event.
- Human action: submit the body form, verify its token, then suppress the address.
- Header one-click: accept the valid token and exact RFC 8058 POST signal for the automated header path.
Implement RFC 8058 correctly
The header endpoint needs more than a POST route. Include one List-Unsubscribe header containing one HTTPS URI, and one List-Unsubscribe-Post header containing the exact value List-Unsubscribe=One-Click. A valid DKIM signature must cover both headers, with both names in its h= tag. Without that DKIM coverage, a receiver should not offer the one-click control. These requirements are defined in RFC 8058.
Put an opaque, hard-to-forge recipient-and-list token in the HTTPS URI. The endpoint must complete the request without cookies, HTTP authorization, a login, or browser-session state. Accept multipart/form-data and application/x-www-form-urlencoded, parsing the same List-Unsubscribe=One-Click field in either encoding. Return success without redirecting the POST. Configure any web application firewall (WAF) to allow this token-validated request without a CAPTCHA or JavaScript challenge.
One-click POST using URL encodinghttp
POST /u/OPAQUE_TOKEN HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Content-Length: 26 List-Unsubscribe=One-Click
- Validate the URI token: confirm that it identifies the intended recipient and mailing list. Preserve any additional message-stream scope your system uses.
- Validate the body: accept the one known key-value pair and reject unrelated state-changing POSTs.
- Make repeats idempotent: a repeated valid request should leave the subscriber suppressed without creating conflicting records.
- Keep retrieval harmless: a GET can render a manual page, and HEAD can return metadata. Neither changes subscription state.
Why Defender causes unwanted unsubscribes
Microsoft Defender for Office 365 uses Safe Links URL scanning during mail flow and verifies links again at click time. Disabling URL rewriting alone still leaves scanning active; specific URL exclusions behave differently. If your unsubscribe endpoint changes subscriber status on GET, an automated fetch looks like recipient action. Microsoft's Safe Links documentation explains the policy settings.
Safe Links scanning and URL rewriting policy settings in Microsoft Defender for Office 365.
This is why the problem often appears uneven. One Microsoft 365 tenant can apply more aggressive URL scanning than another, and policy scope can differ by user, group, or domain. The pattern is documented in public reports such as this Microsoft forum thread, and it matches the broader issue of Office 365 auto-clicking emails.
Unsafe unsubscribe design
- Body link: clicking the URL immediately suppresses the recipient.
- Header URL: a fetched URL changes state without a POST requirement.
- Bot filter: the system relies on IP or User-Agent guessing.
Safe unsubscribe design
- Body link: the URL opens a preference page with a form button.
- Header URL: one-click uses the RFC 8058 POST signal.
- Bot filter: scanner signals improve analytics without protecting state.
Build the unsubscribe flow
Build the visible body-link flow with two separate operations. The first operation is page rendering. The second is suppression. A scanner can complete the first operation all day without changing consent. A recipient must submit the body form before the second operation runs. The header flow remains separate: the mailbox provider sends its one-click POST after the user asks to unsubscribe.
Safe body unsubscribe route patterntext
GET /preferences/unsubscribe?t=TOKEN Validate token authenticity and scope Render preferences page Do not suppress or consume the token HEAD /preferences/unsubscribe?t=TOKEN Return metadata only Do not suppress or consume the token POST /preferences/unsubscribe Validate token and form nonce Suppress recipient Record source as body form POST
For the body link, the token should identify the recipient and list, but a GET containing that token is not permission to suppress. Use it to load the page and prefill the right subscription choices, then require a form submission for the final action. Do not auto-submit the form or call a suppression API when the page loads, including through JavaScript. Do not consume a one-use token on GET or HEAD, since a scanner could otherwise invalidate the recipient's link. For the RFC 8058 endpoint, the valid opaque token and specified one-click field are enough. Do not require a form nonce, cookie, or browser session on that header path.
Scanner-safe unsubscribe flow where GET displays a page and human POST suppresses the recipient.
- Audit endpoints: find every URL that can suppress, opt down, or modify subscription state.
- Split methods: keep GET and HEAD free of subscription changes and write logic on POST.
- Add a form: make the body-link button clear, fast, and accessible, without forcing a login.
- Verify server-side: validate the body form's token and nonce, or the header endpoint's token and RFC 8058 field using either supported encoding.
What to do with body unsubscribe links
The body unsubscribe link is still useful. Recipients expect it, and hiding it pushes people toward spam complaints. Use a two-step unsubscribe for the visible footer link: open a page, then let the recipient confirm removal. This is compatible with RFC 8058 one-click unsubscribe in the message headers, where a valid POST must complete without another confirmation page.
This is also the right place to give people reasonable choices. A recipient can unsubscribe from one newsletter, pause email, or unsubscribe from all marketing. The page should be simple, and the unsubscribe button should work without account creation, password reset, or hidden friction. For a deeper checklist, see these unsubscribe link best practices.
Do not hide the unsubscribe path
The fix is not to remove unsubscribe links, bury them, or make the page harder to use. The fix is to make link prefetching harmless and make the confirmed action explicit.
If your ESP already handles List-Unsubscribe correctly, use its subscription center or hosted preference page for the visible link and verify its behavior. Check custom links for redirects or routes that unsubscribe on GET, including tracking redirects that end at a suppression endpoint.
Testing and monitoring
After changing the flow, test with real inboxes. Send to Microsoft 365, Outlook.com, and other mailbox providers you care about. Logs can show URL scanning before delivery or a visit before the recipient clicks. Check that GET and HEAD never suppress, the body form works after an explicit submission, and the valid RFC 8058 POST completes without another confirmation step.
Repeat GET and HEAD requests, follow body-link redirects, submit the body form once, and repeat the one-click POST using both supported encodings. Check that retrieval never changes subscription state, duplicate valid POSTs are idempotent, and the RFC endpoint returns success without redirects or cookies. In the delivered message, verify that both list headers remain covered by a valid DKIM signature. Keep delivery, scan, click, and suppression events separate in your logs.
A POST alone does not prove human activity. A form nonce protects against forged submissions, but it is not a reliable human-detection control. If logs show valid unsubscribe POSTs before any recipient interaction, preserve the method, content type, parsed field, and timestamp and escalate with the tenant admin and sending platform. Avoid restoring an entire affected list automatically, since that would also undo genuine unsubscribe requests.
Send a campaign sample through Suped's email tester to inspect authentication and unsubscribe headers before a larger send. Suped's product supports this message-level check; use your endpoint logs and Microsoft 365 inbox tests to verify that scanning leaves subscription state unchanged.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Suped's DMARC reporting and email authentication platform supports the surrounding checks by identifying sending sources and SPF or DKIM failures. Use Suped's domain health checker to review DNS and authentication configuration after sending changes. These checks are separate from preventing a URL visit from unsubscribing a recipient.
Safe Links exclusions and their limits
Safe Links exclusions are controlled by the receiving Microsoft 365 tenant. A sender allowlist is not a reliable substitute for fixing the unsubscribe endpoint.
- "Do not rewrite URLs, do checks via SafeLinks API only" stops URL wrapping but keeps pre-delivery scanning and checks in supported Outlook clients.
- "Do not rewrite the following URLs" excludes matching URLs from Safe Links scanning and wrapping during mail flow; time-of-click checks can still block them.
- For a temporary workaround, the tenant admin can test a narrowly scoped URL exclusion in the policy applied to affected recipients.
- Changing one tenant's policy does not protect subscribers in other tenants or stop other link scanners.
Microsoft documents the settings in its Safe Links policy guidance. Keep other email protections enabled while the endpoint is repaired.
When Defender needs remediation
There are still cases where Defender behavior needs attention from the receiving tenant. If only Microsoft 365 recipients at a specific company are affected, ask that tenant's admin to review Safe Links policies, URL detections, and support options. The sender cannot reliably control those tenant-side scans.
The sender-side fix remains the same, even when a tenant escalates with Microsoft: keep retrieval harmless and require a validated POST for suppression. Tenant remediation can reduce repeated page fetches and false engagement. Unexpected valid POSTs need a separate investigation, since the request method alone cannot establish recipient intent.
- Collect timestamps, recipient domains, affected message identifiers, and endpoint logs showing the HTTP method and parsed POST field. Redact live unsubscribe tokens before sharing evidence.
- Escalate narrowly: have the Microsoft 365 admin report the specific false action or overactive policy.
- Use a controlled test campaign with consistent sending domains and authentication, and inspect redirect chains before changing tenant policy.
- Do not denylist: blocking guessed Microsoft IPs or User-Agents creates gaps and breaks real users.
Views from the trenches
Best practices
Use GET only to render a confirmation page, then unsubscribe through a verified POST form.
Put one-click unsubscribe in headers with RFC 8058, not as a body state-change link.
Keep scanner detection as analytics context, not the gate that protects subscriber status.
Common pitfalls
Treating any body link click as consent lets Safe Links and other scanners remove readers.
Relying on Microsoft IP lists fails when scanners use changing routes, proxies, or tenants.
Hiding unsubscribe options can increase spam complaints and damage inbox placement over time.
Expert tips
Store raw click logs separately so automated clicks do not pollute engagement reporting.
Test new sending domains with Office 365 inboxes before large campaigns depend on them.
Use signed recipient-and-list tokens, and keep header POST free of cookies or login state.
Expert view
Expert from Email Geeks says link scanners should not unsubscribe people when the endpoint is designed correctly; a body link should open a page, not suppress immediately.
2024-03-07 - Email Geeks
Expert view
Expert from Email Geeks says the user should click a button on an HTML form, causing an HTTP POST, before the unsubscribe is applied.
2024-03-07 - Email Geeks
