Claude.ai sign-in (magic link) emails delayed 2-5 minutes since mid-July 2026

Confirming this from Windows 11 — sign-in emails routinely take 5+ minutes for me as well.

What makes the delay worse than it first sounds is how it interacts with the 10-minute expiry on the link. Half the window is typically gone before the email lands, and since nobody sits and watches an inbox for five minutes, it's easy to come back to an already-expired link and have to start the whole thing over. The effectively usable window is much shorter than 10 minutes.

It also compounds across clients. I sign in on five surfaces — mobile app, Claude Code, web, Claude for Excel, and Claude for Chrome — each with its own credential and its own expiry, so I hit this repeatedly rather than once.

Two changes would each help independently. The first is fixing the delivery delay, which is what this issue tracks. The second is extending the link and code expiry while delivery is slow: a 10-minute expiry assumes near-instant delivery, and that assumption currently doesn't hold.

I've also opened #84862 asking for passkey sign-in, which would let those of us who want it skip the email round-trip entirely.

same here, i have 2 claude accounts, switching between them is a nightmare.

I can confirm this as well.
Absolutely horrible sign-in process - I also frequently receive the email well after the 10 minute expiration time.
Any improvement to this would be appreciated.

@leojianliu-dot - you should probably ensure that this has [BUG] prefix and tag if possible - otherwise it would probably be overlooked.

Another confirmation: same circumstances. O365 Business account, half the validity window gone by the time the email arrives. I put the headers through Claude asking where the delay was, and it said it was all on the Microsoft side. Suggested turning off security scanning features to try to troubleshoot but I'm not prepared to do that.

We really need passkey logins, don't we? Or at least an alternative auth method, or failing that, a way to link a Google SSO login to our existing accounts.

Also using 365, also waiting ~4-5 minutes each time to login. Yes, the delay is within O365 e-mail security system. No, I'm not going to reduce security. I have been using Claude for about 5 weeks and the lack of an authentication system is starting to grate on me. I have just paid for Codex to trial, solely due to this issue.

Same setup... I use three accounts (two personal, two corporate) and it's a nightmare switching... I don't know who would even use a magiclink as the first line auth method in 2026.. it's slow, inconvenient and less secure than a passkey. To make things worse, working in vscode, I'm going from switchacount -> web browser -> email -> web -> vscode...

Just did this and after 5 mins with no email, hit send again. they both arrived exactly in the hour, which makes me think someone has a polling setup that only runs occasionally, not on demand, so you should probably try to switch accounts at the top of a 15 minute interval or something :)

I see it too since some time. Worst is that it's probably the easiest thing in the world to scale up.

I see it too since some time. Worst is that it's probably the easiest thing in the world to scale up.

maybe somebody could put Claude on it??

+1 on this, and I can add hard numbers on the delay half of it.

I'm on a corporate Microsoft 365 tenant (Switzerland). Sign-in emails arrive consistently ~5 minutes late. I pulled the full headers on one to find out where the time goes — and it isn't in transit.

Timeline from the Received chain (UTC, 2026-08-17):

| Time | Hop |
|---|---|
| 07:01:10.205 | Handed to SendGrid (geopod-ismtpd-60); matches the Date header |
| 07:01:11 | Microsoft edge (*.mail.protection.outlook.com) |
| 07:01:11 | Into mailbox server (*.PROD.OUTLOOK.COM) |
| 07:06:14 | Final hop to the delivery mailbox server, "with HTTPS" |

Anthropic → my tenant's front door took about one second. Then it sat inside Exchange Online for five minutes. Microsoft states this outright:

X-MS-Exchange-Transport-EndToEndLatency: 00:05:03.6797956
X-MS-Exchange-AtpMessageProperties: SA|SL

SA|SL = Safe Attachments and Safe Links, i.e. Defender for Office 365 held the message for full inspection rather than releasing it on the fast path.

To be clear about what this is not: authentication is clean. spf=pass, dkim=pass, dmarc=pass, compauth=pass reason=100, SCL:1, SFV:NSPM. This is not a reputation or spoofing problem, and it's not a misconfigured tenant — everything else in my mailbox arrives promptly. I'm not going to loosen a tenant-wide security policy that works correctly for every other sender.

What I suspect is happening is that several properties of the message itself stack into enough signal to trigger deep inspection:

1. HTML-only, no plain-text part. Top-level Content-Type: text/html with no multipart/alternative.
2. charset=iso-8859-1 on a 2026 transactional email.
3. Randomized per-message sender localpart — no-reply-<random>@mail.anthropic.com, repeated in Reply-To. High-entropy varying localparts are a snowshoe pattern. A stable no-reply@ with the correlation ID in a header would look far more conventional.
4. ESP click tracking on the auth link. X-SG-EID shows SendGrid is in the path. If the sign-in link is rewritten to a tracking redirector, that is precisely what Safe Links detonates — an authentication link resolving somewhere other than claude.ai. Disabling click tracking on authentication mail is standard practice.
5. Timestamp in the subject line (... | 2026-08-17 09:01:10), which defeats fingerprint-based reputation caching across otherwise identical messages.

None of these is individually damning; together they plausibly cost the message its fast path. And this would affect every Defender-enabled M365 tenant, which is most of corporate Europe - so I doubt I'm an outlier here.

Why it matters for this issue: the link expires after 10 minutes, so five of those ten are gone before the mail lands. Nobody watches an inbox for five minutes, so in practice the window is much shorter than advertised. Multiply by the number of surfaces and it becomes a recurring interruption rather than a one-off.

So, two asks of different sizes:

• Structural: passkeys / WebAuthn, as requested in #84862. Removes the email round-trip entirely and is phishing-resistant by construction.
• Immediate: the mail hygiene items above. Adding a plain-text part, UTF-8, a stable sender localpart, and no click tracking on auth links are all small changes that could ship quickly and would likely cut the delay for a lot of enterprise users well before passkeys land.

<html>
<body>
<!--StartFragment--><html><head></head><body><p>Same problem, different tenant. Microsoft 365 mailbox on a custom domain, MX direct to Exchange Online, no third-party filter. I pulled timings for all 42 Anthropic sign-in emails since April.</p>

Sign-in emails | n | min | median | max
-- | -- | -- | -- | --
9 Apr to 18 Jul | 24 | 5 s | 8 s | 103 s
21 Jul to 17 Aug | 18 | 126 s | 214 s | 452 s

<p>No overlap between the two groups. Nothing before 21 July took over 103 s, nothing after took under 126 s, and there is no value in between across 42 messages.</p>
<p>Worst offenders, all with the 10 minute link expiry running:</p>
<ul>
<li>17 Aug 09:06:50 UTC, delivered 09:14:22, <strong>452 s</strong>. <code>&lt;uqVLc6cWRC-J9UtBWbGg2A@geopod-ismtpd-105&gt;</code></li>
<li>9 Aug 13:45:30, delivered 13:50:49, <strong>319 s</strong></li>
<li>17 Aug 08:41:32, delivered 08:46:21, <strong>289 s</strong></li>
<li>9 Aug 13:43:45, delivered 13:48:32, <strong>287 s</strong></li>
</ul>
<p><strong>The break lines up with a change to the email itself.</strong> Last old-template message 18 Jul 14:06:52 UTC, subject <code>Secure link to log in to Claude.ai | &lt;ts&gt;</code>. First new-template message 21 Jul 17:41:12 UTC, subject <code>Your secure link to Claude.ai is here | &lt;ts&gt;</code>, with the "expires in 10 minutes" line added to the body. Every old-template message is fast, every new one is slow. Can't tell from outside whether the template is the cause or just a marker for that deploy, but it's a three day window to diff.</p>
<p>That may also reconcile your onset with mine. You saw a gradual ramp from early July, mine flips overnight on 21 July, but the steady state matches (your mean around 207 s, my median 214 s). Consistent with a staged rollout.</p>
<p><strong>If you have this problem, check your old emails.</strong> Slow ones saying "Your secure link to Claude.ai is here" and fast ones saying "Secure link to log in to Claude.ai" is another data point. A slow message with the old subject would kill the idea.</p>
<p><strong>On resends.</strong> I requested 7 links on 30 July, 3 on 9 Aug, 7 on 17 Aug. They don't arrive simultaneously, the lag just shifts the whole batch, so a burst of requests lands as a burst of emails several minutes later. Two oddities: on 17 Aug the delay grew with each retry (177, 289, 276, then 174, 247, 452), though on 30 July it stayed flat across all seven; and delivery is not ordered, with the message sent 08:43:25 arriving a minute after the one sent 08:43:30. Nothing tells you which link is still live.</p>
<p><strong>Measurement caveat.</strong> This is <code>Date</code> header to Exchange receipt. The timestamp in the subject line is not independent evidence of request time, it matches the <code>Date</code> header to within a second on all 42 messages, so it's the same event. If anything queues before the message is stamped, these numbers are a floor. Nobody has posted a <code>Received</code> chain on this thread, which would at least split SendGrid from Microsoft.</p>
<p><strong>One aside on the sender.</strong> All 51 messages I have came from a different random local part (<code>no-reply-&lt;random&gt;@mail.anthropic.com</code>), so Exchange shows a first-contact warning every time and you can only allow-list at domain level. When the login page has shown a delivery-issues notice it told people to allow-list <code>support@mail.anthropic.com</code> (<a href="https://news.ycombinator.com/item?id=47231206">HN, Mar 2026</a>), an address none of these emails come from. In <a href="https://github.com/anthropics/claude-code/issues/87362">#87362</a> the reporter's IT allow-listed the whole domain and still received nothing.</p>
<p>Related: <a href="https://github.com/anthropics/claude-code/issues/84806">#84806</a> (email arrives after the token expires), <a href="https://github.com/anthropics/claude-code/issues/84412">#84412</a> (code "not received" until you hit resend, probably this bug seen from the user side), <a href="https://github.com/anthropics/claude-code/issues/84862">#84862</a> (passkeys), <a href="https://github.com/anthropics/claude-code/issues/79808">#79808</a> and <a href="https://github.com/anthropics/claude-code/issues/87362">#87362</a> (non-delivery), <a href="https://github.com/anthropics/claude-code/issues/76624">#76624</a> (no way to change your account email, which makes a bad address terminal). Outside the repo: <a href="https://developer.apple.com/forums/thread/816212">Apple Developer Forums 816212</a>, <a href="https://discussions.apple.com/thread/256298894">Apple Community 256298894</a>.</p>
<p>Asks: say what changed between 18 and 21 July; stop tying expiry to a wall clock when delivery is minutes; say which request an email belongs to and invalidate superseded links; use a stable <code>From</code> and put per-message tokens in <code>Return-Path</code>.</p></body></html><!--EndFragment-->
</body>
</html>Same problem, different tenant. Microsoft 365 mailbox on a custom domain, MX direct to Exchange Online, no third-party filter. I pulled timings for all 42 Anthropic sign-in emails since April.

| Sign-in emails | n | min | median | max |
|---|---|---|---|---|
| 9 Apr to 18 Jul | 24 | 5 s | 8 s | 103 s |
| 21 Jul to 17 Aug | 18 | 126 s | 214 s | 452 s |

No overlap between the two groups. Nothing before 21 July took over 103 s, nothing after took under 126 s, and there is no value in between across 42 messages.

Worst offenders, all with the 10 minute link expiry running:

• 17 Aug 09:06:50 UTC, delivered 09:14:22, 452 s. <uqVLc6cWRC-J9UtBWbGg2A@geopod-ismtpd-105>
• 9 Aug 13:45:30, delivered 13:50:49, 319 s
• 17 Aug 08:41:32, delivered 08:46:21, 289 s
• 9 Aug 13:43:45, delivered 13:48:32, 287 s

The break lines up with a change to the email itself. Last old-template message 18 Jul 14:06:52 UTC, subject Secure link to log in to Claude.ai | <ts>. First new-template message 21 Jul 17:41:12 UTC, subject Your secure link to Claude.ai is here | <ts>, with the "expires in 10 minutes" line added to the body. Every old-template message is fast, every new one is slow. Can't tell from outside whether the template is the cause or just a marker for that deploy, but it's a three day window to diff.

That may also reconcile your onset with mine. You saw a gradual ramp from early July, mine flips overnight on 21 July, but the steady state matches (your mean around 207 s, my median 214 s). Consistent with a staged rollout.

If you have this problem, check your old emails. Slow ones saying "Your secure link to Claude.ai is here" and fast ones saying "Secure link to log in to Claude.ai" is another data point. A slow message with the old subject would kill the idea.

On resends. I requested 7 links on 30 July, 3 on 9 Aug, 7 on 17 Aug. They don't arrive simultaneously, the lag just shifts the whole batch, so a burst of requests lands as a burst of emails several minutes later. Two oddities: on 17 Aug the delay grew with each retry (177, 289, 276, then 174, 247, 452), though on 30 July it stayed flat across all seven; and delivery is not ordered, with the message sent 08:43:25 arriving a minute after the one sent 08:43:30. Nothing tells you which link is still live.

Measurement caveat. This is Date header to Exchange receipt. The timestamp in the subject line is not independent evidence of request time, it matches the Date header to within a second on all 42 messages, so it's the same event. If anything queues before the message is stamped, these numbers are a floor. Nobody has posted a Received chain on this thread, which would at least split SendGrid from Microsoft.

One aside on the sender. All 51 messages I have came from a different random local part (no-reply-<random>@mail.anthropic.com), so Exchange shows a first-contact warning every time and you can only allow-list at domain level. When the login page has shown a delivery-issues notice it told people to allow-list support@mail.anthropic.com ([HN, Mar 2026](https://news.ycombinator.com/item?id=47231206)), an address none of these emails come from. In [#87362](https://github.com/anthropics/claude-code/issues/87362) the reporter's IT allow-listed the whole domain and still received nothing.

Related: [#84806](https://github.com/anthropics/claude-code/issues/84806) (email arrives after the token expires), [#84412](https://github.com/anthropics/claude-code/issues/84412) (code "not received" until you hit resend, probably this bug seen from the user side), [#84862](https://github.com/anthropics/claude-code/issues/84862) (passkeys), [#79808](https://github.com/anthropics/claude-code/issues/79808) and [#87362](https://github.com/anthropics/claude-code/issues/87362) (non-delivery), [#76624](https://github.com/anthropics/claude-code/issues/76624) (no way to change your account email, which makes a bad address terminal). Outside the repo: [Apple Developer Forums 816212](https://developer.apple.com/forums/thread/816212), [Apple Community 256298894](https://discussions.apple.com/thread/256298894).

Asks: say what changed between 18 and 21 July; stop tying expiry to a wall clock when delivery is minutes; say which request an email belongs to and invalidate superseded links; use a stable From and put per-message tokens in Return-Path.

Same problem here, different tenant. I went back through my mailbox and pulled timings for every Anthropic sign-in email since April, 42 of them. The numbers back up what you're seeing, and there's a detail in the data that might be worth chasing.

Setup is similar to yours: Microsoft 365 mailbox on a custom domain, MX straight to *.mail.protection.outlook.com, no third-party filter in front. Defender Safe Links has been rewriting links in these messages the whole time, before and after, so it isn't that. Delay measured the same way you did it, Date header against Graph receivedDateTime.

| Group | n | min | median | max |
|---|---|---|---|---|
| Sign-in emails, 9 Apr to 18 Jul | 24 | 5 s | 8 s | 103 s |
| Sign-in emails, 21 Jul to 17 Aug | 18 | 126 s | 214 s | 452 s |
| Other Anthropic mail, same domain, whole period | 9 | 4 s | 21 s | 249 s |

The two sign-in groups don't overlap. Nothing before 21 July took longer than 103 s and nothing after took less than 126 s. Across 42 messages there is no value in between, which is a sharper break than I expected to find.

The break lines up with a template change

I didn't pick 21 July. It's where the email itself changes.

Old one, last seen 18 Jul 14:06:52 UTC. Subject Secure link to log in to Claude.ai | <timestamp>, note the double space after the pipe. Body heading "Let's get you signed in", copy underneath about signing in with the secure link below, no expiry mentioned anywhere in the message.

New one, first seen 21 Jul 17:41:12 UTC. Subject Your secure link to Claude.ai is here | <timestamp>, single space. Body heading "Sign in to Claude.ai", copy telling you to click the button and that the link expires in 10 minutes.

Every old-template message is fast. Every new-template one is slow. I can't tell from outside whether the template is causing it or whether it's just a marker for whatever else went out that week, but the window is narrow enough that someone at Anthropic can diff it in an afternoon.

I opened one new-template message in full and it pulls a remote animated GIF from claude.ai/images/email/hand_wave.gif as a CSS background. I have not checked whether the old template did the same, so don't read that as a difference until someone confirms it.

This might also explain why your onset and mine disagree. You saw it creeping up from early July, mine flips overnight on 21 July, but the steady state matches almost exactly (your mean around 207 s, my median 214 s). A staged rollout across accounts would give you that.

If you're reading this and you have the same problem, check your old emails. If the slow ones all say "Your secure link to Claude.ai is here" and the fast ones say "Secure link to log in to Claude.ai", that's another data point. If anyone has a slow message with the old subject line, say so, because that kills the idea.

Full series

| Sent (UTC) | Received | Delay (s) | Template |
|---|---|---|---|
| 2026-04-09 08:37:02 | 08:38:42 | 100 | old |
| 2026-04-13 11:03:12 | 11:04:30 | 78 | old |
| 2026-04-13 12:54:34 | 12:55:43 | 69 | old |
| 2026-04-22 19:56:43 | 19:56:49 | 6 | old |
| 2026-04-24 12:47:20 | 12:47:54 | 34 | old |
| 2026-04-25 12:44:47 | 12:45:36 | 49 | old, Console |
| 2026-04-26 11:20:03 | 11:20:09 | 6 | old |
| 2026-05-04 09:14:27 | 09:14:32 | 5 | old |
| 2026-05-21 12:39:09 | 12:40:52 | 103 | old, Console |
| 2026-05-21 12:40:49 | 12:41:53 | 64 | old, Console |
| 2026-05-21 18:25:56 | 18:27:02 | 66 | old, Console |
| 2026-05-28 14:48:57 | 14:49:05 | 8 | old |
| 2026-06-08 06:58:29 | 06:59:18 | 49 | old |
| 2026-06-11 18:50:41 | 18:50:47 | 6 | old |
| 2026-07-01 08:55:48 | 08:56:38 | 50 | old |
| 2026-07-03 21:43:41 | 21:44:30 | 49 | old |
| 2026-07-10 13:04:07 | 13:04:14 | 7 | old |
| 2026-07-10 13:06:12 | 13:06:19 | 7 | old |
| 2026-07-10 13:07:20 | 13:07:25 | 5 | old |
| 2026-07-11 19:44:04 | 19:44:09 | 5 | old |
| 2026-07-13 07:52:45 | 07:52:52 | 7 | old |
| 2026-07-17 16:19:48 | 16:19:54 | 6 | old |
| 2026-07-17 19:09:30 | 19:09:36 | 6 | old |
| 2026-07-18 14:06:52 | 14:06:58 | 6 | old |
| 2026-07-21 17:41:12 | 17:43:18 | 126 | new |
| 2026-07-30 17:42:27 | 17:46:01 | 214 | new |
| 2026-07-30 17:44:16 | 17:47:49 | 213 | new |
| 2026-07-30 17:55:10 | 17:58:32 | 202 | new |
| 2026-07-30 17:58:26 | 18:01:38 | 192 | new |
| 2026-07-30 18:01:20 | 18:05:13 | 233 | new |
| 2026-07-30 18:50:04 | 18:53:23 | 199 | new |
| 2026-07-30 18:52:42 | 18:55:44 | 182 | new |
| 2026-08-09 13:43:45 | 13:48:32 | 287 | new |
| 2026-08-09 13:45:30 | 13:50:49 | 319 | new |
| 2026-08-09 13:48:26 | 13:52:37 | 251 | new |
| 2026-08-17 08:40:35 | 08:43:32 | 177 | new |
| 2026-08-17 08:41:32 | 08:46:21 | 289 | new |
| 2026-08-17 08:43:25 | 08:48:01 | 276 | new |
| 2026-08-17 08:43:30 | 08:47:01 | 211 | new |
| 2026-08-17 09:03:52 | 09:06:46 | 174 | new |
| 2026-08-17 09:05:38 | 09:09:45 | 247 | new |
| 2026-08-17 09:06:50 | 09:14:22 | 452 | new |

Worst one: <uqVLc6cWRC-J9UtBWbGg2A@geopod-ismtpd-105>, sent 17 Aug 09:06:50 UTC, delivered 09:14:22, 452 s.

What happens when you hit resend

I requested 7 links on 30 July, 3 on 9 August, 7 on 17 August. From the inbox it looks like they all turn up at once, which is what made me look in the first place. That isn't quite what's going on. The lag shifts the whole batch, so four minutes of requests arrive as four minutes of emails, four minutes later, by which point you've stopped watching and the first one is nearly dead.

Two things did fall out that I wasn't expecting.

Within the second burst on 17 August the delay grew with each retry: 174 s, then 247 s, then 452 s. Looks like each request queuing behind the previous one. It isn't consistent though. On 30 July the delay stayed roughly flat across all seven, 182 s to 233 s, so whatever it is doesn't always behave that way.

Delivery is not in order. The messages sent at 08:43:25 and 08:43:30 arrived at 08:48:01 and 08:47:01, so the later request landed a minute before the earlier one. Nothing in the email tells you which request it came from, and the login page doesn't tell you which link is still live, so you end up clicking a dead one and starting again.

Two things that argue against the pipeline being magic-link specific

You concluded it's isolated to the magic-link stream. My mailbox doesn't quite support that and I'd rather flag it than leave it out.

Two "Your Claude usage limit has been increased" emails from the same domain took 181 s (5 June) and 249 s (10 June), while sign-in emails at the time were arriving in 5 to 7 s. So multi-minute delays already existed somewhere in Anthropic's sending setup well before sign-in went bad. Meanwhile trusted-device and passkey alerts on 13 July arrived in 4 to 6 s alongside fast sign-in mail.

That reads more like shared infrastructure with a slow path, and the sign-in stream getting moved onto it around 21 July, than like a queue that appeared from nowhere.

The From address is randomised, and it defeats the official advice

Every message comes from a different random local part. no-reply-NeQjsyjlbowhr-OgMV1Xpg@, no-reply-T-iu9zqWDFW3CthfuZaDGQ@, and so on, 51 distinct senders across 51 messages, sign-in emails and security alerts alike.

Three consequences, separate from the delay:

Exchange Online throws its first-contact safety tip on every single one, because as far as it's concerned it's never seen the sender before. Recipients can only allow-list at domain level, never by address. And no per-address reputation ever accumulates.

Worth pointing out that Anthropic's own guidance assumes the opposite. When the login page has shown a delivery-problems notice, it has told users to allow-list support@mail.anthropic.com (HN, March 2026). No sign-in email I have ever received came from that address. Someone following that advice literally would allow-list an address that never sends them anything. In #87362 the reporter's IT allow-listed the whole domain and still got nothing.

I'm not claiming the randomisation causes the delay. Microsoft's throttling is mostly driven by IP and authenticated-domain reputation, so it may cost very little. But per-message tokens belong in Return-Path, not in a visible From, and right now there is no recipient-side mitigation available at all.

Impact

10 minute link, 214 s median delay, so about 386 s of usable window on a typical day and 148 s on the worst one I recorded. That's assuming you sit and wait. #84806 reports the email arriving after 11 minutes, which makes login flatly impossible.

Related issues

Same underlying problem:

• #84806, token expires before the email arrives
• #84412, verification code "not received on the first request", only arrives after hitting resend. I suspect the first one wasn't lost, just slow, and this is the same bug seen from the user side
• #84862, passkey sign-in request, already cites this issue

Non-delivery rather than delay, probably a different mechanism but the same blast radius:

• #79808, suspected suppression list, provider block ruled out by the reporter
• #87362, same signature via VS Code, domain allow-listed, nothing arrives

Separate bugs, but they all funnel through the same email round trip:

• #68861, link arrives then fails verification
• #69809, link only works in incognito
• #87731, code prompt doesn't echo and returns the same 400 for empty and wrong input
• #80987, desktop app freezes on the verification-code screen
• #76624, no way to change your account email, which is why a bad address is terminal

And the reason people hit the login flow so often in the first place:

• #1757, constant re-login, 78 comments and running since June 2025
• #85687, macOS desktop loses auth roughly daily
• #85262, OAuth refresh drops expiresAt and scopes, forcing /login

Reports outside this repo

• Hacker News, March 2026, on the "Elevated Errors in Claude.ai" thread. One user waiting over an hour for a code, another reporting that Anthropic mail has never reached their Outlook address since 2023, a third seeing it for two days running. The login page was showing an in-product delivery-issues notice at the time.
• Apple Developer Forums, thread 816212, Xcode 26.3 Claude sign-in. Magic link arrives, but the code entry field only appeared after roughly 10 minutes. Partly an Xcode UI bug, partly the same timing problem.
• Apple Community, thread 256298894, magic links not reaching users behind Apple's private relay. Different cause, same outcome: no email, no account.
• status.anthropic.com, Sept 2024, the last time magic links were acknowledged as an incident. Nothing on the status page for this one, and the August 2026 auth incidents were short hard outages, not this.

What I'd ask for

Say what changed in the sign-in email or its sending path between 18 and 21 July. That's a three day window.

Stop tying the expiry to delivery. Either widen it a lot, or kill a link when it's used or superseded rather than on a clock.

Tell people which request an email belongs to, and invalidate older links explicitly, given delivery isn't ordered.

Use a stable From. Put the per-message token in Return-Path where it belongs, and make the Help Center advice match whatever address actually sends.

Ship passkey sign-in so none of the above is load bearing.

Reproducing the measurement

Connect-MgGraph -Scopes Mail.Read
Get-MgUserMessage -UserId me -All `
  -Property subject,sentDateTime,receivedDateTime,internetMessageId,from |
  Where-Object { $_.From.EmailAddress.Address -like "*mail.anthropic.com" } |
  Select-Object subject,
    @{n='sent';e={$_.SentDateTime}},
    @{n='recv';e={$_.ReceivedDateTime}},
    @{n='delay_s';e={[int]($_.ReceivedDateTime - $_.SentDateTime).TotalSeconds}} |
  Sort-Object sent

One caveat on that. It measures Date header to Exchange receipt, so it lumps together anything Anthropic's own queue does after stamping, time at SendGrid, and Microsoft's inbound processing. Splitting those needs the Received chain out of the raw headers (Outlook: File, Properties, Internet headers). Nobody has posted one on this thread yet. If someone does, it should settle where the time actually goes, and until then Anthropic can reasonably say they don't know.

We're having the same issue. It would be so nice to just be able to login with credentials and MFA instead of this magic link ***...

M365 tenant here, we were seeing similar delays. Bypassing SafeLinkProcessing in Exchange for this sender fixed the hang-up in EOP. Went down from 2m55s to 7s from hitting send to the magic link hitting my mailbox. We have a third-party inspector in front of *.mail.protection.outlook.com, so we'd assumed SafeLinks | SafeAttachments was being bypassed with the AcceptAll rule coming from the scanner, but that's not the case. SafeLinks/Attachments needs to be specifically bypassed.

Via Exchange Admin > Mail Flow > Rules: Add rule ### Skip Safe Links - Anthropic sign-in Apply this rule if: The sender → domain is: mail.anthropic.com AND The subject or body → Subject includes any of these words: Your secure link to Claude.ai Do the following: Modify the message properties → set a message header header name: X-MS-Exchange-Organization-SkipSafeLinksProcessing value: 1 Rule mode: Enforce Match sender address in message: Header Stop processing more rules unchecked Severity/auditing: off

For Anthropic the SendGrid click-tracking is likely the slowdown here, since MS is following and inspecting each of the 7-different click-tracked URLs before saying "it's good" and passing it along. The magic link itself is a known entity, the click-tracking/SafeLink inspection combo appears to be the culprit.

Retracting the main claim in my earlier comment. The template change is not the cause. I mislabelled one row: the 18 July message is the new template and it arrived in 5 seconds, so the new template was live three days before the slowdown began. Ignore my "diff the template between 18 and 21 July" ask. I also wrote that multi-minute delays already existed in Anthropic's sending path. That was wrong too.

@PowershellNinja's header dump prompted me to do this properly. I exported 27 messages as .eml from one M365 mailbox: 15 from Anthropic, 11 from other senders as a control, and one internal message I excluded because internal mail takes a different inbound path. I decomposed all six Received hops on each of the 15 Anthropic messages, 90 lines in total, rather than measuring Date against receivedDateTime as I did before. For the controls I measured the final hop and EndToEndLatency only.

Four cross-checks on the Anthropic set (DKIM t= against Date, CrossTenant-OriginalArrivalTime and ExpirationStartTime against the edge Received, and the app clock in the subject against Date) all agree to within 2 seconds. No clock is lying.

What I measured

Anthropic to Microsoft's edge takes about 1 second per message, worst case 2. On the 13 messages that carry an application timestamp in the subject, that clock is within 0 to 1 second of the SendGrid handoff, so I see no sign of multi-minute queueing before Microsoft accepted the message. The message I previously reported at 249 seconds measures, on the raw headers, as a 248-second total of which 247 were spent after Microsoft had already accepted it.

Of 3369 seconds of total delay across the 15 messages, 3332 (98.9%) fall in one single hop: between the transport server's Received stamp and the mailbox server's final with HTTPS stamp. Of the remaining 37 seconds, 22 are elsewhere inside Microsoft and 15 are on the SendGrid side.

I want to be careful about what that interval is. It is the gap between two stamps, not a named component, and the headers do not tell you which stage holds the message. I cannot establish from headers which pipeline stages fall on which side of that boundary.

All timings below are that final hop, not total delivery time, so they are comparable with each other:

• Anthropic sign-in emails since 21 July: n=12, median 258 s, range 124 to 449. (Totals run 126 to 451.)
• Other senders into the same mailbox, 24 to 26 August: n=11, median 6 s, range 3 to 70.

43x on the medians. The distributions do not overlap, but I would not oversell the margin: the fastest slow-period sign-in was 124 s and the slowest control, Backbone Communications, was 70. Nine of the eleven controls were under 11 seconds.

It is not consistent even for the same sender. Two Anthropic messages on 10 June, 89 seconds apart, with the same sender, same charset, same six link destinations to the same host, and no header name present in one and absent in the other: 247 s and 2 s.

Things that do not on their own explain it

X-MS-Exchange-AtpMessageProperties: SA|SL is stamped on all 26 messages that came through inbound filtering, controls included, so Safe Links being switched on cannot be the difference by itself. (The 27th is the internal message, which carries no such header, which is how I know internal mail takes a different path.)

@h-gf-sh suggested the click-tracking is the mechanism, with Safe Links following each of the 7 tracked URLs before releasing the message. The count matches exactly: 8 wrapped links per sign-in email, 7 of them SendGrid click-tracker URLs. But I struggle to fit it to my data. Opentrons carries 26 links across four hosts including a HubSpot redirector and arrives in 10 seconds; Datadog 22 links in 3 seconds; OpenAI via r.openai.com in 6. And both 10 June messages carry six tracked URLs to the same host and no magic link at all, yet split 247 against 2. So link count alone does not fit. One detail that may matter to someone who knows Safe Links internals: every tracked link carries a per-message token, so across my 15 messages all 103 tracker URLs are distinct even though the destinations and host repeat.

Every other property I measured, bar one, has a fast counterexample in this mailbox. OpenAI's transactional mail is HTML-only with no plain-text part, 132 KB, and click-tracked, and it lands in 6 seconds. Authentication is clean and constant on all 15 Anthropic messages (dkim=pass header.d=mail.anthropic.com, dmarc=pass, compauth=pass reason=100, SCL:1).

One exception I should name rather than bury: charset. Anthropic is the only sender here using iso-8859-1, and every control that declares one uses UTF-8, though only 3 of the 11 declare a charset at all. So it has no control counterexample. It is still ruled out as a mechanism by the 10 June pair, where both halves are iso-8859-1 and split 247 s against 2 s.

With one message per control sender I cannot rule out interactions or probabilistic effects. "Not sufficient on its own" is as far as any of these go. And none of the shared, measured properties explains the 10 June pair, so something time-varying is involved whatever content contributes.

Hypotheses, not conclusions

Defender delivery-time processing. @h-gf-sh's SkipSafeLinksProcessing rule preceded a large improvement. Against it: SA|SL is on the fast messages too.

How the tracking host answers scanners. url8792.mail.anthropic.com resolves to 160.79.104.10, inside 160.79.104.0/21, which ARIN registers to Anthropic, PBC, rather than to a SendGrid CNAME. It answers me in 120 ms so it is not intrinsically slow, but I have no visibility into how it treats Microsoft's scanning fleet.

One marker anyone can check in thirty seconds. The Safe Links data= blob in the rewritten URLs ends in a numeric field. In my set it is 0 on every fast message and 40000 or 60000 on every slow one, 15 for 15. To be clear about the shape of that: only two of my 15 are fast, so it is a 2-versus-13 split, not a balanced one. It does include both halves of the date-controlled 10 June pair, which is why I think it is worth a look rather than noise. I have found no documentation for it and I am not claiming to know what it encodes. But it is Microsoft's own machinery marking the two populations differently, so if you have a slow delivery it costs nothing to look at yours.

Workaround

@h-gf-sh's transport rule is the only thing in this thread with a reported result behind it: sender domain mail.anthropic.com plus a subject match, setting X-MS-Exchange-Organization-SkipSafeLinksProcessing to 1. Their comment has the exact steps.

Keep their subject condition, so only the auth message bypasses and Anthropic's other mail is still scanned. And be clear on the trade: this disables Safe Links for the whole message including the tracked links, so you lose time-of-click protection on those.

Two asides. Dynamic Delivery will get suggested because it is the standard answer to Defender scanning delays; it governs messages with attachments and these have none, so I would not expect it to do anything. And worth knowing regardless of the delay: Safe Links URL-encodes the # in the sign-in link, which lifts a live token out of the URL fragment and into a query parameter on a Microsoft-hosted URL.

What the thread could actually settle

I am not going to run more experiments on one mailbox. What this needs is a second and third tenant, which several of you can produce cheaply.

Measure it the same way

Get the full raw header block: Outlook on the web, open the message, More actions (the three dots), View, View message details, then copy the whole block. Classic Outlook: File, Properties, Internet headers. Record, in UTC and with the date:

1. Date:
2. the timestamp on the topmost Received: line, the one ending with HTTPS
3. the timestamp on the Received: line containing mail.protection.outlook.com
4. X-MS-Exchange-Transport-EndToEndLatency, verbatim
5. the trailing number in the Safe Links data= blob, if your links are rewritten

(2) minus (1) is the total. (2) minus (3) approximates Microsoft-side handling if your MX points straight at EOP; if you sit behind a gateway, hop 3 is your gateway handing off, so post both stamps but do not compare that delta with direct-MX tenants. That split is what this thread has been missing, because "it took five minutes" cannot distinguish a sender problem from a filtering problem.

Please also state: your region; whether MX points directly at *.mail.protection.outlook.com or through a gateway such as Mimecast or Proofpoint, since a gateway changes what hop 3 means (check with nslookup -type=mx yourdomain; if the top MX host ends in .mail.protection.outlook.com you are direct); whether Safe Links and Safe Attachments are enabled; and whether any bypass rule already applies.

Experiment 1: does it depend on which Anthropic email you get?

Anthropic sends several message types from the identical sender, ESP and IP pool, so comparing them holds all of that constant and varies content.

Working from a session where you are already logged in, so you are not blocked waiting on a magic link, trigger in a randomised order:

• a magic link, from the login page in a private window, which is what gets you a fresh link without logging out of the session you are working from
• a passkey alert, by adding a passkey in Settings
• a Console sign-in link, if you have Console access

Do one round with the triggers inside two minutes, and one round with them ten minutes apart. In my data, three requests a minute or two apart came back with holds that grew on each one, 170 s then 240 s then 449 s, and one reply arrived 58 seconds before an earlier request. So firing your triggers together is itself a burst, and a tight round alone cannot separate content from burst position. Randomise the order each round, or trigger position confounds the thing you are testing.

Report every round, including rounds where everything was fast. An all-fast round is real evidence about your tenant; it just does not prove the tenant is never slow. Do not discard it.

Roughly what the outcomes would mean, stated weakly on purpose:

• All types slow: points at the sender or stream rather than one message type. All three could still be tripping the same condition.
• Magic link slow, alerts fast: points at the sign-in message specifically, and makes a content experiment worth building.
• All types fast: your tenant was fine in that window, nothing more. Post it anyway.

Experiment 2: is your tenant slow at that moment, or just Anthropic?

In the same window as an Experiment 1 round, trigger a password reset or login link from two unrelated services and measure them identically. If those land in seconds while Anthropic takes minutes, that argues against a tenant-wide transient at that moment, though it does not rule out something path-specific. This is the control my own data is weakest on: mine are from adjacent days, not the same minute.

A sender-matched control would be better still. If you have other SendGrid-relayed mail arriving in the same mailbox, that is the closest comparison available, and none of my controls provides it.

For Anthropic

Every message property I tested except charset has a fast counterexample in the same mailbox, and the charset idea is killed by two of your own messages 89 seconds apart that split 247 s against 2 s. So I cannot point at anything in the message and say it causes this. I also do not want to overstate that into "the message is not involved": the medians differ by 43x, and the fastest slow-period sign-in, at 124 s, was still slower than every one of the eleven controls. Something about this sender or stream is being treated differently, even though the clock runs on Microsoft's side.

A Microsoft message trace would localise it quickly. To be straight, that is a recipient-tenant admin function rather than something you can pull for my mailbox, and I do not hold that role here. If an admin in this thread can trace one slow delivery and post which stage holds the message, that single result is worth more than everything above.

Independent of the cause: stop tying the expiry to a wall clock and invalidate on use or supersession instead, tell users which link is still live given delivery is not ordered, and ship passkeys (#84862).

Caveats: one mailbox, one tenant, one message per control sender, and I chose them. None of my controls sends via SendGrid. Only one control is same-day with a slow delivery, three hours earlier, and none is simultaneous. Happy to share the redacted Received chains.

You asked for a message trace and you shall receive :)

Subject: Your secure link to Claude.ai is here | 2026-08-27 10:57:11 Sender: no-reply-ogSKvWQVJIQy2g4n_izx2w@mail.anthropic.com Recipient: dxxxx.sxxxx@xxxxxx.com Received -> Processed -> Delivered Status: The message was delivered to the recipient's Inbox folder.<br/><br/><b>Delivery time:</b> ‎08/27/2026 10:02:29 (UTC)‎ More information: <div>If the recipient can't find the message in their Inbox folder, it might have been deleted or moved to another folder (such as Junk Email) either manually or automatically based on an Inbox rule or Sweep rule the recipient set up. Ask them to search for the message across all folders in their mailbox.<br/><br/><b>Tip:</b> If the recipient still can't find the message in Outlook, they might be having connectivity issues. Ask them to try restarting Outlook or use <a href='https://outlook.office365.com/owa' target='_blank'>Outlook on the web</a> to check for the message. To see detailed steps for fixing Outlook, see <a href='http://go.microsoft.com/fwlink/p/?LinkId=708526' target='_blank'>Fix Outlook connection problems in Office 365</a>.</div> Date (UTC+00:00) | Event | Detail | ------------------------------------ 8/27/2026, 10:57 AM | Receive | Message received by: DU4PR01MB12723.eurprd01.prod.exchangelabs.com 8/27/2026, 10:57 AM | Defer | Reason: [ATP][Scan in progress] Message waiting for detonation result 8/27/2026, 11:02 AM | Deliver | The message was successfully delivered. More information Message ID:<xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> MessageTrace ID:5b6a01e1-8054-43ac-6799-08df042191de Message size | From IP | To IP ‎196.23‎ KB | xxxxxxxxxxxx |

So, it does seem to be the ATP scanning, I've applied the transport rule as suggested earlier in the thread and will see how that goes

BTW you can ask you exchange admins to set this email header to emails from *@mail.anthropic.com:

if 'Authentication-Results' header contains ''dmarc=pass' or 'dmarc=bestguesspass''
and sender's address domain portion belongs to any of these domains: 'mail.anthropic.com'
Set the message header 'X-MS-Exchange-Organization-SkipSafeLinksProcessing' with the value '1'

I’m seeing a very similar issue, but in my case the failure has become more severe.

For several days, Claude magic-link emails were intermittent: the first request often failed, but the second or third would usually arrive.

Today, however, none of the magic-link emails have arrived at all, even after repeated attempts.

At the same time, other Anthropic authentication emails, including 6-digit verification codes, are still being delivered normally to the same mailbox.

I have reproduced the issue in both Claude Web and Cowork/Desktop.

This makes me wonder whether the delayed magic-link delivery described here may in some cases be progressing into complete non-delivery.

Anthropic support has documented my case but cannot inspect the sending backend or escalate it further.

Same issue with me always takes 5 min to arrive. Is Claude working on it or not?

Same issue with me always takes 5 min to arrive. Is Claude working on it or not?

I assume not, Claude sign-in emails aren't slow to send, Anthropic hands them to Microsoft in about a second, then Microsoft 365 holds them for roughly several minutes at the final delivery hop while Defender for Office 365 checks links or other security checks or perhaps just crashing or being inneficient.