Clerk’s servers remained healthy, yet authentication emails were disrupted. Email depends on DNS checks that a working application does not prove are available.
Clerk’s servers remained healthy during its DNS provider outage on 10 February 2026, but some authentication emails went missing or landed in spam.
DNS was unavailable for 2 hours and 32 minutes. Successful API request volume stayed above 95% of the expected level; that measured API traffic, not email delivery. Clerk’s postmortem
Why email needs DNS
When assessing a message, a receiving service can check the sender’s SPF record and retrieve the public key needed to verify its DKIM signature. Both checks depend on DNS, even if the application has already generated and sent the email. SPF standard, DKIM standard
A DNS timeout does not establish that the sender is unauthorised or that a signature is wrong. It means the receiver could not complete the relevant check. SPF and DKIM distinguish temporary lookup problems from definitive authentication failures. What happens to the message then depends on the receiving system’s handling of that error. SPF temporary errors, DKIM verification
The application can successfully send an email while the recipient’s service is unable to complete those checks.
A healthy app can still depend on unavailable DNS
Read the diagram as text
- The application can be healthy and generate a sign-in message.
- A receiver needs DNS to read the SPF record and retrieve the DKIM public key.
- Unavailable DNS can prevent those authentication checks from completing.
- A working application therefore does not prove that the sign-in email reached the user.
Why the outage was difficult to spot
Clerk reported that cached DNS answers appeared to mask the failure from its uptime checks. Using the same supplier for DNS and domain registration also prevented an emergency nameserver change for a critical domain.
Its postmortem proposed independent DNS failover, separating the registrar from the DNS provider, and directly monitoring authoritative nameservers. Those were planned changes in the report. Clerk’s planned remediations
For an application that relies on email to let someone sign in, a successful request is only part of the outcome. The person still needs the message to arrive.
Monitor the checks a sign-in email depends on
For an application that sends sign-in links, three observations answer different questions:
| Observation | What it helps establish |
|---|---|
| An authoritative DNS query returns the expected SPF or DKIM answer | The source DNS service can currently serve that authentication record. |
| The sending service records acceptance or a rejection response | How far the message got through that service's delivery attempt. |
| A controlled test mailbox receives the sign-in email | That this sending path reached this mailbox at that time. |
A cached recursive DNS answer can remain healthy while the authoritative service is unavailable. A working API can generate a message that later fails authentication checks. Even a successful mailbox test covers one path, so it should complement the other observations.
For an investigation, retain the failed DNS name, response, time and affected message identifier. The DNS propagation checker can compare visible DNS answers, while delivery-status evidence helps establish the message's last confirmed handover. These are practical lessons from the incident, not a claim that SPF flattening would have prevented it.
Sources and further reading
Sources reviewed 12 September 2026.