What Clerk's DNS Outage Shows About Authentication Email

Clerk reported authentication-email failures despite largely healthy API traffic. Its postmortem explains the DNS failover and monitoring gaps behind that incident.

Clerk's postmortem describes a DNS outage on 10 February 2026.

What the incident actually showed

Clerk reported two hours and 32 minutes of authoritative DNS unavailability, while successful API request volume stayed above 95% of expected volume. Some authentication emails were undelivered or put in spam when receivers could not resolve SPF and DKIM records. There was no password-reset-specific failure rate.

The postmortem identified three gaps:

• No prepared failover for a complete DNS-provider outage.
• A critical domain registered with the same supplier, blocking emergency nameserver changes.
• Monitoring that did not directly check authoritative nameservers and apparently benefited from cached answers.

Clerk described plans to address those gaps. The postmortem does not establish their subsequent completion.

Authentication adds DNS dependencies

SPF retrieves policy from DNS. A temporary lookup failure can produce temperror, which is different from an SPF fail. DKIM also relies on DNS to retrieve the public key used to verify the signature.

DMARC can pass through qualifying aligned SPF or DKIM. That gives two authentication paths, but it does not make their DNS infrastructure independent. A shared outage can affect both.

A receiving system's handling of lookup errors can vary. Authentication trouble does not imply every message immediately bounces.

A cached success can hide a failing dependency

DNS caches let a resolver reuse answers it already has. Some resolvers can also serve stale data when fresh answers are unavailable. That can preserve service for some users while a different resolver has no usable answer.

For operators of critical authentication systems, our conclusion is to test the authoritative DNS dependency as well as the application endpoint. A working check from one network does not establish that every recipient can retrieve the required records.

The same distinction applies to the email journey. An accepted API request, an accepted message and a completed sign-in are different outcomes. A delayed password-reset message can arrive too late to be useful if its token has expired; that is an application-design consideration, not a reported Clerk measurement.

This was a DNS resilience incident. SPF maintenance alone is not a continuity system for login email, and there is no basis for claiming Emailmetry would have prevented it.