bodnar1212 · March 30, 2026 15:41
diff --git a/gistfile1.txt b/gistfile1.txt
 # Domain Reputation Issue - Browser Security Warnings

 ## The Problem

 Your website is being blocked by browser security systems, showing warning pages that prevent users from accessing it.

 **Microsoft Edge** - Microsoft Defender SmartScreen shows a red warning page: **"This site has been reported as unsafe"**.

 **Google Chrome** - Google Safe Browsing may show a red warning page: **"Deceptive site ahead"** or **"The site ahead contains harmful programs"**.

 **Email links (Microsoft 365 / Outlook)** - Microsoft Defender for Office 365 Safe Links intercepts clicked links and shows: **"This website is classified as malicious"** with the URL rewritten through `safelinks.protection.outlook.com`.

 ### Why this is happening

 Your website is hosted on a shared cloud platform. The platform hosts many websites as subdomains under one parent domain. At some point, one or more other websites on the same platform were reported as hosting phishing or malicious content. Browser security systems (Microsoft SmartScreen, Google Safe Browsing) then flagged the **entire parent domain**, which means all websites hosted on it - including yours - are now blocked.

 ### What this is NOT

 - This is **not** a problem with your website content - your website is clean and legitimate
 - This is **not** caused by your browser or computer settings - it is a server-side reputation issue on Microsoft's and/or Google's end
 - This is **not** a TLD (top-level domain) ban - see the section below

 ### About TLD reputation

 Chrome and Edge **do not blacklist entire top-level domains**. For example, if your website uses a `.site` domain, the `.site` TLD itself is not blocked - the issue is with the specific domain or subdomain that was flagged.

 However, TLD reputation matters significantly in practice, and choosing the right TLD is an important factor in your overall domain trust - even though it alone will not cause or prevent blocking.

 **Why `.com` matters:**

 `.com` is the most widely trusted TLD on the internet. It has been in use since 1985, has the largest number of legitimate registrations, and carries the highest baseline trust score across virtually all security systems. Websites on `.com` domains:

 - Start with a higher default trust score in browser security filters, spam filters, and corporate security gateways
 - Are less likely to be flagged by automated heuristics, because the ratio of legitimate-to-abusive `.com` domains is far better than newer TLDs
 - Are treated as the "expected" TLD by most users and security teams - anything else may receive additional scrutiny simply for being unfamiliar
 - Have the strongest track record with email deliverability systems (see section below)

 **However, `.com` is NOT a 100% solution.** A `.com` domain on the same shared hosting platform would face the exact same blocking if the parent domain is flagged. `.com` does not make you immune to:

 - Shared domain reputation issues - if `platform.com` hosts abusive subdomains, all subdomains are affected regardless of the parent TLD
 - Blocklist inclusion - Spamhaus, SURBL, and other blocklists flag specific domains, not TLDs. A `.com` domain can be blocklisted just as easily as any other
 - SmartScreen and Safe Browsing flags - these systems evaluate domains individually, not by TLD. A flagged `.com` domain is blocked the same way as a flagged `.site` domain
 - New domain reputation - a brand-new `.com` domain with no history still has zero reputation and can be flagged if suspicious signals appear

 **The TLD hierarchy in practice:**

 | TLD category         | Examples                                                                 | Baseline trust | Abuse rate | Notes                                                                                                                                                              |
 | -------------------- | ------------------------------------------------------------------------ | -------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | Legacy/established   | `.com`, `.org`, `.net`                                             | Highest        | Low        | Decades of history, stricter registration at scale, universally recognized                                                                                         |
 | Government/education | `.gov`, `.edu`                                                       | Very high      | Very low   | Restricted registration, inherently trusted                                                                                                                        |
 | Country codes        | `.co.uk`, `.de`, `.fr`, `.nl`                                    | High           | Low        | Strong reputation in their regions, regulated by national authorities                                                                                              |
 | Google-operated      | `.app`, `.dev`, `.page`                                            | Good           | Low        | Require HTTPS, operated by Google with active abuse monitoring                                                                                                     |
 | Mid-tier new gTLDs   | `.site`, `.online`, `.store`, `.io`                              | Moderate       | Moderate   | Legitimate and widely used, but newer and cheaper than `.com`, so they receive more scrutiny from security filters                                               |
 | High-risk new gTLDs  | `.top`, `.xyz`, `.icu`, `.click`, `.buzz`, `.rest`, `.gdn` | Low            | Very high  | Spam rates exceeding 80-90% on some of these TLDs according to Spamhaus. Extremely cheap registration ($1-2/year) with minimal verification attracts massive abuse |

 **Key statistics:**

 - Spamhaus reports that new gTLDs collectively account for approximately 40% of all domain-based spam, despite representing a much smaller share of total domain registrations
 - The worst new gTLDs (`.top`, `.xyz`, `.icu`) have abuse rates 50-100x higher than `.com`
 - `.site` falls in the middle - it is not among the worst TLDs, but its newer status and lower cost compared to `.com` mean it is under more scrutiny than legacy TLDs
 - Even within `.com`, domains registered through cheap registrars with minimal verification have higher abuse rates - TLD alone does not tell the full story

 **Key takeaway:** Choosing `.com` gives you the best starting position, but it is not a silver bullet. The primary problem in this case is shared domain reputation, not TLD choice. A `.com` custom domain that you own and control independently is the strongest solution - not because of the TLD alone, but because it combines the most trusted TLD with independent reputation that is not tied to a shared platform.

 ### About TLD reputation and email deliverability

 TLD choice has a **more pronounced impact on email deliverability** than on browser security warnings. Email is where TLD reputation becomes a practical, day-to-day issue that directly affects whether your messages reach recipients.

 **Why email systems care more about TLDs:**

 Email spam filters process billions of messages daily and use statistical models that weigh hundreds of signals. The TLD of domains appearing in email links is one of those signals. Because the volume of email abuse is so much higher than web abuse, email filters are more aggressive in applying reputation-based scoring:

 - **Gmail** - Google's spam filter uses machine learning that has learned strong correlations between certain TLDs and spam. A link to a `.top` domain in an email body will receive a higher spam score than the same link on a `.com` domain, all else being equal.
 - **Microsoft Outlook/365** - Microsoft Defender for Office 365 Safe Links evaluates link reputation at click time. Domains on lower-reputation TLDs have a lower starting trust score and are more likely to be blocked or flagged during the real-time scan.
 - **Corporate email gateways** (Proofpoint, Mimecast, Barracuda) - many enterprise email security products allow administrators to configure TLD-level policies. Some organizations block entire TLDs as a security measure. This is most common for the high-risk gTLDs (`.top`, `.xyz`, `.icu`), but some overly aggressive policies also block mid-tier TLDs.
 - **Spamhaus DBL** - the most widely used domain blocklist, used by thousands of mail servers. Spamhaus tracks abuse statistics per TLD and applies different scrutiny levels based on the TLD's overall abuse rate.

 **How `.com` helps with email specifically:**

 - `.com` links in emails are almost never blocked purely because of the TLD - there is no legitimate security product that flags `.com` as a suspicious TLD
 - Corporate email gateways that block by TLD will never block `.com`
 - Email marketing platforms (Mailchimp, SendGrid, HubSpot) apply less scrutiny to `.com` links in campaign content
 - When a `.com` domain is falsely flagged, the dispute resolution process is typically faster because security vendors prioritize `.com` reviews

 **But `.com` still does not solve everything for email:**

 - If the `.com` domain is on a shared hosting platform, the same shared reputation problem applies
 - A brand-new `.com` domain with no sending history still needs a warm-up period before sending large email campaigns
 - `.com` does not exempt you from needing proper email authentication (SPF, DKIM, DMARC)
 - A `.com` domain that appears on Spamhaus DBL or SURBL will be blocked just as effectively as any other TLD

 **Practical impact by email context:**

 | Email scenario                                  | TLD impact   | Explanation                                                                               |
 | ----------------------------------------------- | ------------ | ----------------------------------------------------------------------------------------- |
 | Personal email (Gmail, Outlook.com)             | Low-moderate | Gmail and Outlook weigh TLD as one of many signals; proper authentication matters more    |
 | Corporate email (Proofpoint, Mimecast)          | High         | Some organizations block entire TLDs;`.com` is safest for reaching corporate recipients |
 | Email marketing (Mailchimp, SendGrid)           | Moderate     | Marketing platforms scan link quality; links on high-risk TLDs may trigger warnings       |
 | Transactional email (order confirmations, etc.) | Low-moderate | Usually trusted because of sender reputation; but link reputation still applies           |
 | Cold outreach / sales emails                    | High         | Unknown senders + links on non-`.com` TLDs compound spam signals significantly          |

 **Recommendation:** If email deliverability is important to your business - and it almost always is - use a `.com` custom domain for all links in emails. This does not guarantee delivery, but it removes TLD reputation as a negative factor and gives you the highest possible baseline trust. Combined with proper email authentication (SPF, DKIM, DMARC) and a clean sending reputation, `.com` provides the strongest foundation.

 ---

 ## How to Verify the Issue

 ### Check if Microsoft flags the domain (Edge)

 1. Open **Microsoft Edge**
 2. Navigate to your website URL
 3. If you see the red SmartScreen warning ("This site has been reported as unsafe"), the domain is flagged by Microsoft

 ### Check if Google flags the domain (Chrome)

 1. Open **Google Chrome**
 2. Navigate to your website URL
 3. If you see a red warning ("Deceptive site ahead"), the domain is flagged by Google
 4. You can also check without visiting the site: go to https://transparencyreport.google.com/safe-browsing/search and enter your URL

 ### Check reputation across multiple vendors

 1. Go to: https://www.virustotal.com/
 2. Enter your website URL in the search bar
 3. Review which security vendors (if any) flag the domain
 4. Check the "Relations" tab to see if other subdomains on the same parent domain are flagged

 ---

 ## What is a False Positive?

 A false positive occurs when a security system incorrectly identifies a safe, legitimate website as malicious. In this case, your website is not hosting any phishing, malware, or harmful content - but the browser's security filter has flagged it anyway. This typically happens because your website shares a parent domain with other websites on the same cloud platform, and one or more of those other websites were involved in actual malicious activity. The security system then applies the block too broadly, catching legitimate websites in the process.

 False positives are a common problem on shared cloud platforms. Microsoft and Google both provide mechanisms to dispute these incorrect classifications, but the process requires manual submission and review.

 ## How to Report a False Positive to Microsoft

 Microsoft does not provide a standalone web form for disputing SmartScreen website false positives. The only reliable method is through the warning page itself.

 ### Step-by-step process

 1. Open your blocked website URL in **Microsoft Edge**
 2. On the red warning page, click **"More information"** (expandable section at the bottom)
 3. Click **"Report that this site does not contain threats"**
 4. Fill out the form with:
   - Your website URL
   - Explanation of what your website is, who operates it, and that it contains no phishing, malware, or malicious content
 5. Submit the form
 6. You will receive a confirmation email from the **SmartScreen Reputation Group**
 7. **Reply to that confirmation email** with additional context:
   - Confirm that the cloud platform is a legitimate SaaS provider
   - Note that the parent domain hosts many legitimate websites
   - Mention that the flagging is likely caused by abuse on a different subdomain, not yours
   - Attach a screenshot of your legitimate website content if possible
   - Include a VirusTotal scan result showing the website is clean (https://www.virustotal.com/)

 ### Tips to strengthen your false positive report

 - **Provide evidence** - include screenshots of your website content showing it is a normal business or event page
 - **Reference your platform** - explain that the cloud platform is a well-known SaaS provider with thousands of legitimate users
 - **Show third-party verification** - run a scan on VirusTotal or Google Safe Browsing and include the results showing no threats detected
 - **Be specific** - explain exactly what your website does (e.g. "This is an event registration page for a professional conference") rather than just saying "this site is safe"
 - **Mention the shared domain issue** - make it clear that the flagging is a side effect of the shared parent domain, not a result of your website's content

 ### Expected response time

 Microsoft states 24 hours, but real-world reports from other platform operators indicate it can take **days to weeks**. Reply to the confirmation email periodically to keep the case active.

 ---

 ## How to Report to Google Safe Browsing (Chrome)

 If Google Chrome shows a warning (red "Deceptive site ahead" page):

 1. Go to: https://safebrowsing.google.com/safebrowsing/report_error/?hl=en
 2. Enter your website URL
 3. In the comments, explain what your website is and that it contains no phishing, malware, or deceptive content
 4. Submit the report

 Google typically responds **faster** than Microsoft - usually within a few days.

 Additionally, if you have access to **Google Search Console** for the domain:

 1. Go to: https://search.google.com/search-console
 2. Select the affected domain
 3. Check the **Security & Manual Actions** → **Security Issues** section
 4. If there are flagged issues, you can request a review directly from there

 ---

 ## How to Fix Email Link Blocking (Microsoft 365 Safe Links)

 If the link is being blocked when clicked from Outlook / Microsoft 365 email, this is **Microsoft Defender for Office 365 Safe Links** - a separate system from SmartScreen.

 ### For the email recipient

 - **Workaround:** Copy the original URL and paste it directly into the browser address bar. This bypasses Safe Links.

 ### For the organization's IT admin

 1. Go to the Microsoft 365 Defender portal: https://security.microsoft.com
 2. Navigate to **Policies & rules** → **Threat policies** → **Safe Links**
 3. Add the domain to the **"Do not rewrite the following URLs"** list
 4. Alternatively, submit the URL for review:
   - Go to **Actions & Submissions** → **Submissions** → **URLs** tab
   - Submit the blocked URL and select **"Should not have been blocked"**

 ---

 ## Temporary Solution: Change the Subdomain Name

 If the flagging targets a specific subdomain rather than the entire parent domain, requesting a new subdomain name from the cloud platform can help. The new subdomain name should be meaningful and related to your business or event, not a random string. For example, a conference website should use something like `conference-name-2026.platform.site` rather than `abc123xyz.platform.site`. Auto-generated or random-looking subdomain names can themselves trigger additional suspicion from security filters.

 However, be aware of the side effects:

 - **All existing links break** - any links shared via email, social media, documents, or bookmarks will stop working
 - **SEO impact** - search engines have already indexed the old URL, and the new subdomain starts with zero search history
 - **Email deliverability** - previously sent emails with the old link will lead to a dead page
 - **Not a permanent fix** - if the entire parent domain is flagged (not just your subdomain), the new subdomain will be blocked too
 - **The problem can repeat** - as long as you are on a shared domain, other users' abuse can trigger the same issue again

 This is a quick workaround, not a lasting solution. Use it to restore access while working on a custom domain setup.

 ---

 ## Long-Term Solution: Use a Custom Domain

 The most reliable way to prevent this issue from happening again is to use your own custom domain instead of a subdomain on the shared cloud platform.

 ### Why this matters

 When your website runs on a shared platform subdomain (e.g. `yoursite.platform.site`), your website's reputation is tied to every other website on that platform. If any other user on the platform creates malicious content, the entire parent domain can be flagged - and your legitimate website gets blocked along with it. You have no control over this, and the dispute process with Microsoft and Google can take weeks.

 When you use your own custom domain (e.g. `yourdomain.com`), your website has its **own independent reputation**. Even if the shared platform domain gets flagged, your custom domain remains unaffected. Your reputation depends only on your own content.

 ### Benefits of a custom domain

 - **Independent reputation** - your domain cannot be blocked because of someone else's content on the same platform
 - **No dependency on the platform's abuse management** - you are not waiting for the platform to clean up other users' malicious subdomains
 - **Professional appearance** - visitors see your brand in the address bar, not the platform's domain
 - **Better email deliverability** - emails containing links to your custom domain are less likely to be intercepted by Safe Links or spam filters
 - **SEO advantage** - search engines treat custom domains as more authoritative than subdomains on shared platforms

 ### Choosing a TLD for your custom domain

 When registering a custom domain, **`.com` is the strongest choice** for overall trust and email deliverability. However, the specific TLD matters less than having your own independent domain. Any custom domain - even on `.site` or `.online` - is dramatically better than staying on a shared platform subdomain, because you control your own reputation.

 If `.com` is not available for your desired name, good alternatives in order of preference:

 1. `.com` - best baseline trust, best email deliverability, universally recognized
 2. `.org`, `.net` - established legacy TLDs with strong reputation
 3. Country codes (`.co.uk`, `.de`, `.fr`, etc.) - excellent for regional businesses
 4. `.co`, `.io`, `.app`, `.dev` - modern TLDs with good reputation
 5. `.site`, `.online`, `.store` - acceptable, but expect slightly more scrutiny from email filters and corporate gateways
 6. Avoid: `.top`, `.xyz`, `.icu`, `.click`, `.buzz` - high abuse rates make these a poor choice for any professional use

 ---

 ## Reference Links

 | Resource                                     | URL                                                                                                |
 | -------------------------------------------- | -------------------------------------------------------------------------------------------------- |
 | Google Safe Browsing - report false positive | https://safebrowsing.google.com/safebrowsing/report_error/?hl=en                                   |
 | Google Safe Browsing - check domain status   | https://transparencyreport.google.com/safe-browsing/search                                         |
 | Google Search Console - security issues      | https://search.google.com/search-console                                                           |
 | Microsoft Edge SmartScreen troubleshooting   | https://learn.microsoft.com/en-us/troubleshoot/microsoft-edge/development/unexpected-block-warning |
 | VirusTotal - check domain reputation         | https://www.virustotal.com/                                                                        |
 | Spamhaus TLD Statistics                      | https://www.spamhaus.org/statistics/tlds/                                                          |
 | MXToolbox Blocklist Check                    | https://mxtoolbox.com/blacklists.aspx                                                              |
 | Mail-Tester                                  | https://www.mail-tester.com/                                                                       |
	# Domain Reputation Issue - Browser Security Warnings

	## The Problem

	Your website is being blocked by browser security systems, showing warning pages that prevent users from accessing it.

	Microsoft Edge - Microsoft Defender SmartScreen shows a red warning page: "This site has been reported as unsafe".

	Google Chrome - Google Safe Browsing may show a red warning page: "Deceptive site ahead" or "The site ahead contains harmful programs".

	Email links (Microsoft 365 / Outlook) - Microsoft Defender for Office 365 Safe Links intercepts clicked links and shows: "This website is classified as malicious" with the URL rewritten through `safelinks.protection.outlook.com`.

	### Why this is happening

	Your website is hosted on a shared cloud platform. The platform hosts many websites as subdomains under one parent domain. At some point, one or more other websites on the same platform were reported as hosting phishing or malicious content. Browser security systems (Microsoft SmartScreen, Google Safe Browsing) then flagged the entire parent domain, which means all websites hosted on it - including yours - are now blocked.

	### What this is NOT

	- This is not a problem with your website content - your website is clean and legitimate
	- This is not caused by your browser or computer settings - it is a server-side reputation issue on Microsoft's and/or Google's end
	- This is not a TLD (top-level domain) ban - see the section below

	### About TLD reputation

	Chrome and Edge do not blacklist entire top-level domains. For example, if your website uses a `.site` domain, the `.site` TLD itself is not blocked - the issue is with the specific domain or subdomain that was flagged.

	However, TLD reputation matters significantly in practice, and choosing the right TLD is an important factor in your overall domain trust - even though it alone will not cause or prevent blocking.

	Why `.com` matters:

	`.com` is the most widely trusted TLD on the internet. It has been in use since 1985, has the largest number of legitimate registrations, and carries the highest baseline trust score across virtually all security systems. Websites on `.com` domains:

	- Start with a higher default trust score in browser security filters, spam filters, and corporate security gateways
	- Are less likely to be flagged by automated heuristics, because the ratio of legitimate-to-abusive `.com` domains is far better than newer TLDs
	- Are treated as the "expected" TLD by most users and security teams - anything else may receive additional scrutiny simply for being unfamiliar
	- Have the strongest track record with email deliverability systems (see section below)

	However, `.com` is NOT a 100% solution. A `.com` domain on the same shared hosting platform would face the exact same blocking if the parent domain is flagged. `.com` does not make you immune to:

	- Shared domain reputation issues - if `platform.com` hosts abusive subdomains, all subdomains are affected regardless of the parent TLD
	- Blocklist inclusion - Spamhaus, SURBL, and other blocklists flag specific domains, not TLDs. A `.com` domain can be blocklisted just as easily as any other
	- SmartScreen and Safe Browsing flags - these systems evaluate domains individually, not by TLD. A flagged `.com` domain is blocked the same way as a flagged `.site` domain
	- New domain reputation - a brand-new `.com` domain with no history still has zero reputation and can be flagged if suspicious signals appear

	The TLD hierarchy in practice:

	\| TLD category \| Examples \| Baseline trust \| Abuse rate \| Notes \|
	\| -------------------- \| ------------------------------------------------------------------------ \| -------------- \| ---------- \| ------------------------------------------------------------------------------------------------------------------------------------------------------------------ \|
	\| Legacy/established \| `.com`, `.org`, `.net` \| Highest \| Low \| Decades of history, stricter registration at scale, universally recognized \|
	\| Government/education \| `.gov`, `.edu` \| Very high \| Very low \| Restricted registration, inherently trusted \|
	\| Country codes \| `.co.uk`, `.de`, `.fr`, `.nl` \| High \| Low \| Strong reputation in their regions, regulated by national authorities \|
	\| Google-operated \| `.app`, `.dev`, `.page` \| Good \| Low \| Require HTTPS, operated by Google with active abuse monitoring \|
	\| Mid-tier new gTLDs \| `.site`, `.online`, `.store`, `.io` \| Moderate \| Moderate \| Legitimate and widely used, but newer and cheaper than `.com`, so they receive more scrutiny from security filters \|
	\| High-risk new gTLDs \| `.top`, `.xyz`, `.icu`, `.click`, `.buzz`, `.rest`, `.gdn` \| Low \| Very high \| Spam rates exceeding 80-90% on some of these TLDs according to Spamhaus. Extremely cheap registration ($1-2/year) with minimal verification attracts massive abuse \|

	Key statistics:

	- Spamhaus reports that new gTLDs collectively account for approximately 40% of all domain-based spam, despite representing a much smaller share of total domain registrations
	- The worst new gTLDs (`.top`, `.xyz`, `.icu`) have abuse rates 50-100x higher than `.com`
	- `.site` falls in the middle - it is not among the worst TLDs, but its newer status and lower cost compared to `.com` mean it is under more scrutiny than legacy TLDs
	- Even within `.com`, domains registered through cheap registrars with minimal verification have higher abuse rates - TLD alone does not tell the full story

	Key takeaway: Choosing `.com` gives you the best starting position, but it is not a silver bullet. The primary problem in this case is shared domain reputation, not TLD choice. A `.com` custom domain that you own and control independently is the strongest solution - not because of the TLD alone, but because it combines the most trusted TLD with independent reputation that is not tied to a shared platform.

	### About TLD reputation and email deliverability

	TLD choice has a more pronounced impact on email deliverability than on browser security warnings. Email is where TLD reputation becomes a practical, day-to-day issue that directly affects whether your messages reach recipients.

	Why email systems care more about TLDs:

	Email spam filters process billions of messages daily and use statistical models that weigh hundreds of signals. The TLD of domains appearing in email links is one of those signals. Because the volume of email abuse is so much higher than web abuse, email filters are more aggressive in applying reputation-based scoring:

	- Gmail - Google's spam filter uses machine learning that has learned strong correlations between certain TLDs and spam. A link to a `.top` domain in an email body will receive a higher spam score than the same link on a `.com` domain, all else being equal.
	- Microsoft Outlook/365 - Microsoft Defender for Office 365 Safe Links evaluates link reputation at click time. Domains on lower-reputation TLDs have a lower starting trust score and are more likely to be blocked or flagged during the real-time scan.
	- Corporate email gateways (Proofpoint, Mimecast, Barracuda) - many enterprise email security products allow administrators to configure TLD-level policies. Some organizations block entire TLDs as a security measure. This is most common for the high-risk gTLDs (`.top`, `.xyz`, `.icu`), but some overly aggressive policies also block mid-tier TLDs.
	- Spamhaus DBL - the most widely used domain blocklist, used by thousands of mail servers. Spamhaus tracks abuse statistics per TLD and applies different scrutiny levels based on the TLD's overall abuse rate.

	How `.com` helps with email specifically:

	- `.com` links in emails are almost never blocked purely because of the TLD - there is no legitimate security product that flags `.com` as a suspicious TLD
	- Corporate email gateways that block by TLD will never block `.com`
	- Email marketing platforms (Mailchimp, SendGrid, HubSpot) apply less scrutiny to `.com` links in campaign content
	- When a `.com` domain is falsely flagged, the dispute resolution process is typically faster because security vendors prioritize `.com` reviews

	But `.com` still does not solve everything for email:

	- If the `.com` domain is on a shared hosting platform, the same shared reputation problem applies
	- A brand-new `.com` domain with no sending history still needs a warm-up period before sending large email campaigns
	- `.com` does not exempt you from needing proper email authentication (SPF, DKIM, DMARC)
	- A `.com` domain that appears on Spamhaus DBL or SURBL will be blocked just as effectively as any other TLD

	Practical impact by email context:

	\| Email scenario \| TLD impact \| Explanation \|
	\| ----------------------------------------------- \| ------------ \| ----------------------------------------------------------------------------------------- \|
	\| Personal email (Gmail, Outlook.com) \| Low-moderate \| Gmail and Outlook weigh TLD as one of many signals; proper authentication matters more \|
	\| Corporate email (Proofpoint, Mimecast) \| High \| Some organizations block entire TLDs;`.com` is safest for reaching corporate recipients \|
	\| Email marketing (Mailchimp, SendGrid) \| Moderate \| Marketing platforms scan link quality; links on high-risk TLDs may trigger warnings \|
	\| Transactional email (order confirmations, etc.) \| Low-moderate \| Usually trusted because of sender reputation; but link reputation still applies \|
	\| Cold outreach / sales emails \| High \| Unknown senders + links on non-`.com` TLDs compound spam signals significantly \|

	Recommendation: If email deliverability is important to your business - and it almost always is - use a `.com` custom domain for all links in emails. This does not guarantee delivery, but it removes TLD reputation as a negative factor and gives you the highest possible baseline trust. Combined with proper email authentication (SPF, DKIM, DMARC) and a clean sending reputation, `.com` provides the strongest foundation.

	---

	## How to Verify the Issue

	### Check if Microsoft flags the domain (Edge)

	1. Open Microsoft Edge
	2. Navigate to your website URL
	3. If you see the red SmartScreen warning ("This site has been reported as unsafe"), the domain is flagged by Microsoft

	### Check if Google flags the domain (Chrome)

	1. Open Google Chrome
	2. Navigate to your website URL
	3. If you see a red warning ("Deceptive site ahead"), the domain is flagged by Google
	4. You can also check without visiting the site: go to https://transparencyreport.google.com/safe-browsing/search and enter your URL

	### Check reputation across multiple vendors

	1. Go to: https://www.virustotal.com/
	2. Enter your website URL in the search bar
	3. Review which security vendors (if any) flag the domain
	4. Check the "Relations" tab to see if other subdomains on the same parent domain are flagged

	---

	## What is a False Positive?

	A false positive occurs when a security system incorrectly identifies a safe, legitimate website as malicious. In this case, your website is not hosting any phishing, malware, or harmful content - but the browser's security filter has flagged it anyway. This typically happens because your website shares a parent domain with other websites on the same cloud platform, and one or more of those other websites were involved in actual malicious activity. The security system then applies the block too broadly, catching legitimate websites in the process.

	False positives are a common problem on shared cloud platforms. Microsoft and Google both provide mechanisms to dispute these incorrect classifications, but the process requires manual submission and review.

	## How to Report a False Positive to Microsoft

	Microsoft does not provide a standalone web form for disputing SmartScreen website false positives. The only reliable method is through the warning page itself.

	### Step-by-step process

	1. Open your blocked website URL in Microsoft Edge
	2. On the red warning page, click "More information" (expandable section at the bottom)
	3. Click "Report that this site does not contain threats"
	4. Fill out the form with:
	- Your website URL
	- Explanation of what your website is, who operates it, and that it contains no phishing, malware, or malicious content
	5. Submit the form
	6. You will receive a confirmation email from the SmartScreen Reputation Group
	7. Reply to that confirmation email with additional context:
	- Confirm that the cloud platform is a legitimate SaaS provider
	- Note that the parent domain hosts many legitimate websites
	- Mention that the flagging is likely caused by abuse on a different subdomain, not yours
	- Attach a screenshot of your legitimate website content if possible
	- Include a VirusTotal scan result showing the website is clean (https://www.virustotal.com/)

	### Tips to strengthen your false positive report

	- Provide evidence - include screenshots of your website content showing it is a normal business or event page
	- Reference your platform - explain that the cloud platform is a well-known SaaS provider with thousands of legitimate users
	- Show third-party verification - run a scan on VirusTotal or Google Safe Browsing and include the results showing no threats detected
	- Be specific - explain exactly what your website does (e.g. "This is an event registration page for a professional conference") rather than just saying "this site is safe"
	- Mention the shared domain issue - make it clear that the flagging is a side effect of the shared parent domain, not a result of your website's content

	### Expected response time

	Microsoft states 24 hours, but real-world reports from other platform operators indicate it can take days to weeks. Reply to the confirmation email periodically to keep the case active.

	---

	## How to Report to Google Safe Browsing (Chrome)

	If Google Chrome shows a warning (red "Deceptive site ahead" page):

	1. Go to: https://safebrowsing.google.com/safebrowsing/report_error/?hl=en
	2. Enter your website URL
	3. In the comments, explain what your website is and that it contains no phishing, malware, or deceptive content
	4. Submit the report

	Google typically responds faster than Microsoft - usually within a few days.

	Additionally, if you have access to Google Search Console for the domain:

	1. Go to: https://search.google.com/search-console
	2. Select the affected domain
	3. Check the Security & Manual Actions → Security Issues section
	4. If there are flagged issues, you can request a review directly from there

	---

	## How to Fix Email Link Blocking (Microsoft 365 Safe Links)

	If the link is being blocked when clicked from Outlook / Microsoft 365 email, this is Microsoft Defender for Office 365 Safe Links - a separate system from SmartScreen.

	### For the email recipient

	- Workaround: Copy the original URL and paste it directly into the browser address bar. This bypasses Safe Links.

	### For the organization's IT admin

	1. Go to the Microsoft 365 Defender portal: https://security.microsoft.com
	2. Navigate to Policies & rules → Threat policies → Safe Links
	3. Add the domain to the "Do not rewrite the following URLs" list
	4. Alternatively, submit the URL for review:
	- Go to Actions & Submissions → Submissions → URLs tab
	- Submit the blocked URL and select "Should not have been blocked"

	---

	## Temporary Solution: Change the Subdomain Name

	If the flagging targets a specific subdomain rather than the entire parent domain, requesting a new subdomain name from the cloud platform can help. The new subdomain name should be meaningful and related to your business or event, not a random string. For example, a conference website should use something like `conference-name-2026.platform.site` rather than `abc123xyz.platform.site`. Auto-generated or random-looking subdomain names can themselves trigger additional suspicion from security filters.

	However, be aware of the side effects:

	- All existing links break - any links shared via email, social media, documents, or bookmarks will stop working
	- SEO impact - search engines have already indexed the old URL, and the new subdomain starts with zero search history
	- Email deliverability - previously sent emails with the old link will lead to a dead page
	- Not a permanent fix - if the entire parent domain is flagged (not just your subdomain), the new subdomain will be blocked too
	- The problem can repeat - as long as you are on a shared domain, other users' abuse can trigger the same issue again

	This is a quick workaround, not a lasting solution. Use it to restore access while working on a custom domain setup.

	---

	## Long-Term Solution: Use a Custom Domain

	The most reliable way to prevent this issue from happening again is to use your own custom domain instead of a subdomain on the shared cloud platform.

	### Why this matters

	When your website runs on a shared platform subdomain (e.g. `yoursite.platform.site`), your website's reputation is tied to every other website on that platform. If any other user on the platform creates malicious content, the entire parent domain can be flagged - and your legitimate website gets blocked along with it. You have no control over this, and the dispute process with Microsoft and Google can take weeks.

	When you use your own custom domain (e.g. `yourdomain.com`), your website has its own independent reputation. Even if the shared platform domain gets flagged, your custom domain remains unaffected. Your reputation depends only on your own content.

	### Benefits of a custom domain

	- Independent reputation - your domain cannot be blocked because of someone else's content on the same platform
	- No dependency on the platform's abuse management - you are not waiting for the platform to clean up other users' malicious subdomains
	- Professional appearance - visitors see your brand in the address bar, not the platform's domain
	- Better email deliverability - emails containing links to your custom domain are less likely to be intercepted by Safe Links or spam filters
	- SEO advantage - search engines treat custom domains as more authoritative than subdomains on shared platforms

	### Choosing a TLD for your custom domain

	When registering a custom domain, `.com` is the strongest choice for overall trust and email deliverability. However, the specific TLD matters less than having your own independent domain. Any custom domain - even on `.site` or `.online` - is dramatically better than staying on a shared platform subdomain, because you control your own reputation.

	If `.com` is not available for your desired name, good alternatives in order of preference:

	1. `.com` - best baseline trust, best email deliverability, universally recognized
	2. `.org`, `.net` - established legacy TLDs with strong reputation
	3. Country codes (`.co.uk`, `.de`, `.fr`, etc.) - excellent for regional businesses
	4. `.co`, `.io`, `.app`, `.dev` - modern TLDs with good reputation
	5. `.site`, `.online`, `.store` - acceptable, but expect slightly more scrutiny from email filters and corporate gateways
	6. Avoid: `.top`, `.xyz`, `.icu`, `.click`, `.buzz` - high abuse rates make these a poor choice for any professional use

	---

	## Reference Links

	\| Resource \| URL \|
	\| -------------------------------------------- \| -------------------------------------------------------------------------------------------------- \|
	\| Google Safe Browsing - report false positive \| https://safebrowsing.google.com/safebrowsing/report_error/?hl=en \|
	\| Google Safe Browsing - check domain status \| https://transparencyreport.google.com/safe-browsing/search \|
	\| Google Search Console - security issues \| https://search.google.com/search-console \|
	\| Microsoft Edge SmartScreen troubleshooting \| https://learn.microsoft.com/en-us/troubleshoot/microsoft-edge/development/unexpected-block-warning \|
	\| VirusTotal - check domain reputation \| https://www.virustotal.com/ \|
	\| Spamhaus TLD Statistics \| https://www.spamhaus.org/statistics/tlds/ \|
	\| MXToolbox Blocklist Check \| https://mxtoolbox.com/blacklists.aspx \|
	\| Mail-Tester \| https://www.mail-tester.com/ \|
No results found