修改身份验证终结点以处理预览流量而不刻录身份验证代码。来自安全链接/ Exchange Online Protection的请求不会包含与正常客户端请求相同的标头;查看安全链接烧录授权代码示例的日志，了解可以拒绝的未授权请求类型。确保端点未完成HEAD请求的授权流程（如果请求的HTTP方法为HEAD，则返回405）;如果安全链接也发出GET请求，那么在继续身份验证流程之前验证UserAgent报头之类的操作可能会起作用。除了涉及某种形式的一次性令牌交换之外，您不需要提供任何有关链接结构或身份验证策略的信息，但您也应该检查IETF RFC，以确认您正确遵守了所使用的任何协议。
其他想法：

• 电子邮件中的URL应始终是HTTPS链接（而不是HTTP）。
• 您可能缺乏电子邮件发件人信誉，无法假定电子邮件是安全的;仔细阅读建立一个优秀的电子邮件发送者声誉的策略。
• 如果链接的域与发件人的域不匹配，您的链接可能被认为是可疑/不安全的。
• 这不是一个很好的解决方案，为抛光产品提供，但尝试包括一个纯文本（不是超链接）版本的网址在电子邮件中;大多数现代电子邮件客户端会注意到它是一个链接，并自动为最终用户超链接它，但安全链接可能是扫描原始电子邮件正文定义的href属性。他们的URL解析历史上一直相当原始，许多人通过找到一些混淆安全链接匹配策略的东西（例如，https://halon.io/blog/fooled-microsofts-safe-link-technology）来绕过它。
• 建议这些用户将您的域名添加到他们的许可列表（“白名单”）中，这样安全链接就会忽略您的链接。