Why are we seeing automatic opens and clicks on Office 365 hosted recipient domains?
Matthew Whittaker
Co-founder & CTO, Suped
Published 6 Aug 2025
Updated 24 May 2026
9 min read
Summarize with
Yes, automatic opens and clicks on Office 365 hosted recipient domains are usually caused by Microsoft Defender for Office 365, Exchange Online Protection, Safe Links, or another security layer in front of the recipient mailbox. Safe Links is the common cause for link clicks. Automatic opens usually come from a security scanner or mail client fetching the tracking pixel before the recipient reads the message.
The important part is control. If the recipient domain is hosted on Microsoft 365, the recipient tenant decides whether links are rewritten, scanned, detonated, or excluded. A sender can measure and filter the resulting events, but cannot turn off another company's Microsoft 365 security scanning.
- Direct answer: Office 365 hosted domains are not always showing human engagement. Many early opens and clicks are scanner activity.
- Main click source: Safe Links and related URL inspection can request links, including unsubscribe links.
- Main sender fix: Classify bot events in analytics, keep unsubscribe endpoints safe, and monitor authentication separately.
What is causing the opens and clicks
When I see a cluster of Office 365 recipient domains opening and clicking within seconds of delivery, I assume security scanning until the evidence says otherwise. Corporate Microsoft 365 tenants often inspect links before delivery, at the time of click, or both. Some tenants also run third-party gateways before Microsoft, so the visible pattern can look like Microsoft activity even when another filter is involved.
Microsoft Defender portal Safe Links policy settings
There are two separate signals to handle. An open is a remote image request, usually a tracking pixel. A click is a request to a tracked URL. They can happen together, but they do not prove the same thing. Safe Links explains many automatic clicks. Image prefetching, gateway analysis, or client behavior explains many automatic opens.
|
|
|
|---|---|---|
0-10s click | Scanner | Suppress |
All links hit | URL scan | Cluster |
No session | Bot | Exclude |
Later repeat | Person | Count |
Common Office 365 scanner patterns
The first mistake to avoid
Do not treat every Microsoft 365 click as either fake or real. Treat it as unclassified until you compare timing, IP ownership, user agent, link breadth, landing page behavior, and whether the same recipient later repeats the action in a normal browser session.
What Microsoft is actually doing
Microsoft 365 filtering is recipient-side protection. The sender hands the message to the receiving system. The receiving system then evaluates sender reputation, authentication, URLs, attachments, content, tenant policy, and user history. Microsoft has its own guidance for external senders in Microsoft troubleshooting, but the sender still has to infer scanner behavior from event data.
Safe Links can rewrite URLs and check them when the message is delivered or when a user clicks. Some configurations and security stacks also crawl body links. That crawl can touch every link in the message, including preference center links, terms links, social links, and unsubscribe links.
Flowchart showing how Office 365 security scanning can create events
Sender controls
- Measure: Record event timing, IPs, user agents, URL count, and landing page sessions.
- Harden: Make GET requests harmless for sensitive actions such as unsubscribes.
- Report: Separate scanner clicks from human clicks in campaign dashboards.
Recipient admin controls
- Policy: Adjust Safe Links and tenant URL protection settings.
- Exclude: Add trusted domains or URLs to allowed or do-not-rewrite lists.
- Scope: Apply exceptions to specific users, groups, or accepted domains.
Can Microsoft skip unsubscribe links
In practice, you should assume the scanner can click unsubscribe links. That does not mean Microsoft is trying to unsubscribe the recipient. It means the scanner follows links to inspect the destination. If your unsubscribe endpoint performs the unsubscribe as soon as a GET request arrives, a scanner can trigger a real opt-out.
Do not unsubscribe on GET
A visible unsubscribe link in the email body should load a page where the recipient confirms the change. For standards-based one-click unsubscribe in headers, handle the required POST flow. Keep the body-link GET request safe and idempotent.
Recipient administrators can exclude specific domains or URLs in their own Microsoft 365 policy design. They generally cannot say, "do not scan anything with the word unsubscribe" or "skip anything with opt-out in the anchor text." Phrase-based exceptions create an obvious abuse path because a bad sender can hide a dangerous destination under friendly text.
Safer visible unsubscribe flowtext
GET /unsubscribe?token=abc Return confirmation page, do not change state yet. POST /unsubscribe/confirm Validate token, then unsubscribe the recipient.
That pattern protects people and analytics at the same time. The scanner can load the first URL without changing consent state. A real user can still unsubscribe with a clear confirmation step, and the standards-based header path can process the required one-click request.
How to tell bots from people
I do not rely on one field. User agents are often missing or generic. IP ownership can shift through cloud networks. Timing alone catches obvious scanner traffic, but it also catches a real person who happens to open immediately. A good classifier combines weak signals until the pattern is strong enough to label.
Bot-click confidence by timing
Use timing as one signal, then confirm with URL breadth and landing behavior.
Immediate
0-10 sec
Treat as scanner until disproven.
Early
10-60 sec
Review with other signals.
Normal
1-30 min
Likely human if session data exists.
Confirmed
Action
Count when a session or conversion follows.
The strongest scanner signature is breadth. A person rarely clicks every link in a newsletter at the same second. A security system often touches the hero link, footer links, privacy link, preference center, and unsubscribe link in a tight group. The separate bot-click identification workflow is useful when you need to formalize that logic.
- Timing: Clicks within a few seconds of delivery are scanner candidates, especially at scale.
- Breadth: Every link hit at once is stronger evidence than one quick click.
- Session: No cookies, no JavaScript, and no page depth point away from a person.
- Repeat: A later click from a normal browser can be counted as the human action.
Simple scanner classification logictext
if seconds_since_delivery < 10 and links_clicked >= 3: mark event_group as scanner_candidate if no_browser_session and no_conversion: keep scanner_candidate label if later_human_session_exists: count later event as human engagement
What to change in analytics
The reporting fix is not to delete all Microsoft traffic. The fix is to maintain two metrics: raw events and qualified engagement. Raw events explain what your tracking system received. Qualified engagement is what you use for campaign decisions, lead scoring, sales alerts, and automation.
I also avoid triggering high-value automations from a single click when the recipient domain is Microsoft-hosted. A scanner click should not move a lead to a sales sequence, mark an account as active, or suppress a contact because it touched the unsubscribe page.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If I need to prove whether a real message produces scanner events, I send it through the email tester and compare headers, authentication, message rendering, and click timing against production logs. That does not disable Microsoft scanning, but it gives a clean baseline before blaming the campaign platform.
For scoring, I prefer thresholds that require a second signal. A click plus a browser session is stronger than a click alone. A click plus a form submit is stronger again. A click that happens before a normal open, touches every link, and never creates a browser session belongs in a scanner bucket.
Raw event reporting
Raw reporting keeps the original open and click events for auditability. It helps engineering debug scanner behavior and compare vendor logs.
- Use: Incident review, deliverability debugging, and event pipeline checks.
- Risk: It inflates engagement when used in marketing reports.
Qualified engagement
Qualified engagement filters events through timing, session, and conversion logic before it influences decisions.
- Use: Lead scoring, audience targeting, and conversion analysis.
- Risk: Over-filtering hides legitimate fast responders.
Where authentication and Suped fit
DMARC, SPF, and DKIM do not cause automatic Office 365 clicks. They also do not switch Safe Links off. They matter because Microsoft evaluates authentication and reputation before it decides how much trust to place in a message. A clean authentication setup reduces avoidable filtering pressure, even though scanning still happens in many tenants.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Suped, our DMARC and email authentication platform, is useful here because this problem often mixes two questions: "is Microsoft scanning my links?" and "is Microsoft distrusting my domain?" Those need different evidence. Suped brings DMARC reporting, SPF and DKIM checks, blocklist monitoring, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and real-time alerts into one operational view.
For most teams, Suped is the strongest practical overall fit when they need DMARC monitoring, sender authentication diagnostics, and blocklist monitoring in the same workflow. Blocklist (blacklist) checks matter because URL and domain reputation issues can coexist with bot clicks, and separating those issues keeps the investigation grounded.
Basic DMARC record for reportingtext
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100
A quick domain health checker run also helps separate authentication problems from analytics noise. If SPF, DKIM, DMARC, reverse DNS, or MTA-STS are broken, fix those independently. If authentication is clean and the clicks are instant, broad, and sessionless, treat the Office 365 events as scanner activity.
The clean investigation split
- Authentication: Use DMARC, SPF, and DKIM evidence to prove the sender is legitimate.
- Reputation: Check domain and IP reputation, including blocklist and blacklist signals.
- Engagement: Classify opens and clicks using event behavior, not authentication status.
- Remediation: Fix DNS issues in parallel with analytics filtering.
Practical fixes to implement
The practical fix depends on who owns the problem. If you are the sender, you filter the analytics, harden endpoints, and keep authentication clean. If you also control the recipient Microsoft 365 tenant, you can review Safe Links policies and add narrow exceptions for known internal or partner domains.
- Log fields: Capture delivery time, event time, recipient domain, IP, user agent, URL, and session ID.
- Group events: Cluster clicks by message ID and recipient so every-link scans stand out.
- Protect endpoints: Make GET requests read-only for unsubscribe, preference, and account actions.
- Separate metrics: Keep raw events for debugging and qualified engagement for business decisions.
- Escalate narrowly: Ask recipient admins for domain or URL exclusions only when there is a clear business case.
Do not ask every recipient to weaken their filtering. That usually fails and creates risk for them. A narrow exception for a known training platform, internal service, or partner domain is a reasonable request. A blanket request to stop scanning marketing links is not.
What not to change
Do not weaken DMARC policy, remove tracking entirely without a replacement measurement plan, or mark every Microsoft-hosted click as fake. Those changes hide evidence. Fix the classifier and the endpoint behavior first.
Views from the trenches
Best practices
Classify clicks with timing, user agent, landing activity, and link breadth before reporting.
Keep unsubscribe GET requests harmless, then confirm intent on a page or compliant POST.
Monitor authentication and reputation separately so bot clicks do not hide delivery issues.
Common pitfalls
Counting every Microsoft-hosted click as human interest inflates campaign performance data.
Phrase-based exceptions for unsubscribe text do not match how recipient scanning works.
Changing DMARC policy to fix Safe Links clicks confuses authentication with URL scanning.
Expert tips
Compare clicked URLs per message; scanners often touch every link before a person reads it.
Use recipient-domain clustering to find tenant policies instead of blaming one campaign.
Treat blocklist and blacklist signals separately from bot clicks, then investigate overlap.
Marketer from Email Geeks says Safe Links was the likely driver when Office 365 domains produced immediate click activity after delivery.
2023-07-25 - Email Geeks
Marketer from Email Geeks says Defender can click every body link, including unsubscribe links, when a policy scans URLs aggressively.
2023-08-31 - Email Geeks
The practical answer
Automatic opens and clicks on Office 365 hosted recipient domains are expected in many Microsoft 365 environments. They are usually scanner events, not proof that a person read the email or clicked the offer. Safe Links and related filtering explain the click side. Image fetches and gateway analysis explain many automatic opens.
The clean response is to treat the recipient tenant's security controls as fixed, then improve the parts you own. Keep unsubscribe endpoints safe on GET, classify scanner traffic before it reaches reporting, avoid using one raw click for automation, and keep DMARC, SPF, DKIM, MTA-STS, and reputation monitoring healthy so authentication problems do not get mixed up with bot-click noise.
