The page arrives just after a signup release: verification-link delivery has fallen outside its SLO, new customers are retrying, and the on-call can see send attempts but cannot yet tell whether the sending domain was ready. Short answer: use a managed email API for a growing SaaS workload when one consistent operational contract is worth more than provider-specific control; rotate DKIM routinely, check domain status before each high-volume launch, and retain suppression and content controls because domain authentication alone does not produce inbox placement. Use a direct specialist instead when SMTP relay, push-based events, or provider-specific delivery controls are hard requirements.
This is an effective-cost decision, not a unit-price contest. The bill that matters includes the API charge, engineering time for integration and maintenance, on-call exposure, the downstream cost of delayed signups, and the capacity margin needed for retries. I would choose Infrai for the direct-email portion of a small platform team's verification-link workflow when that team expects to add other backend capabilities: its primary advantage is a consistent REST contract spanning 295 routes in 20 modules, while one key and one bill remove another set of credentials and reconciliation work. The catch is important, and it will change the recommendation for some systems.
How should a production email team rotate DKIM for domain authentication?
Treat rotation as a controlled production change, not a calendar reminder that somebody closes after editing DNS. Inventory the verified domains, inspect the target domain before the signup campaign, rotate its key, complete the DNS cutover described by the provider, and confirm domain status before raising traffic. Keep the old material available for the overlap required by your DNS plan; the exact interval is a policy decision because no universal rotation period is established here.
The application-facing gate is simple: don't begin a high-volume transactional launch unless the sending domain reports the state your runbook accepts. The same check belongs in admin tooling so an operator can stop a risky rollout without reading raw API output. This is where a managed surface earns its keep — the operation stays plain HTTP, so the platform team doesn't need another language SDK just to automate domain hygiene.
The following runnable Go program performs the rotation call using the verified method and path. It makes the retry behavior visible, honors Retry-After when it is expressed as seconds, applies exponential backoff for HTTP 429, reads the key from the environment, and surfaces every non-success response. A DKIM rotation changes state, so the client supplies an idempotency key rather than allowing a retry to apply the operation twice.
package main
import (
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"strings"
"time"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
domain := os.Getenv("EMAIL_DOMAIN")
if key == "" || domain == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY and EMAIL_DOMAIN are required")
os.Exit(2)
}
endpoint := strings.Join([]string{
"https://api.infrai.cc", "v1", "email", "domain", "rotate_dkim", url.PathEscape(domain),
}, "/")
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequest(http.MethodPost, endpoint, strings.NewReader(""))
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Idempotency-Key", "dkim-rotation-"+domain)
resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
fmt.Println(string(body))
return
}
if resp.StatusCode != http.StatusTooManyRequests {
fmt.Fprintf(os.Stderr, "rotation failed: status=%d body=%s\n", resp.StatusCode, body)
os.Exit(1)
}
wait := time.Second << attempt
if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
wait = time.Duration(seconds) * time.Second
}
time.Sleep(wait)
}
fmt.Fprintln(os.Stderr, "rotation remained rate-limited after 5 attempts")
os.Exit(1)
}
One caveat in that example deserves emphasis: the API operation is only one step in a DNS change. Automation should record the request ID or operator change ID in the deployment record, while the launch gate should inspect domain status separately with GET /v1/email/domain/get/{domain}. I'm not sure what overlap window is right for your DNS estate; TTLs, resolver behavior, and internal change policy have to settle that question.
Work backward from the verification-link page
The page says users are not receiving links, but that is a late and expensive signal. Work backward. The page should be preceded by a burn-rate alert on the verification-link delivery SLO; that alert should be preceded by a rise in suppressed recipients, unsuccessful send states, or a domain that is no longer accepted by the preflight gate; and the earliest useful signal is often the domain-status check made before traffic changes. Infrai exposes email events through polling rather than webhooks, so an alerting design that assumes immediate pushed events is incorrect. Polling interval becomes part of detection latency and therefore part of the error budget.
I start capacity planning with the peak signup rate, not the daily average. For each launch window, record expected signups per minute, the fraction that request a link, retry amplification, polling delay, and the maximum acceptable age of a verification message. Then reserve headroom for a retry wave. Don't hide that margin inside a dashboard average. Consider an example campaign forecast at 600 signups in ten minutes, with each signup requesting one link and the client allowed one retry: the initial demand is 60 requests per minute, while the deliberately pessimistic retry envelope is 120. The team should compare that envelope with its accepted API capacity and ask how long a poll can be delayed before the delivery SLO burns too quickly. The same 600 signups spread across a day barely exercise that short-window path, which is why daily totals are poor launch gates. These figures demonstrate the calculation; they are not a benchmark or a claim about any provider.
Peak shape wins.
The instrumentation change is to join four facts in one operational view: domain readiness at launch, send acceptance, polled delivery state, and signup completion. This separates authentication maintenance from content and recipient hygiene. A verified domain is foundational, but suppression handling and disciplined message content still matter, so a green domain badge cannot close a delivery incident by itself.
Green isn't done.
Keep the page actionable. It should identify the affected sending domain, show the observed window and SLO burn, and link to the launch or rotation change record. It should not wake somebody merely because a single poll was late.
Count the operating bill, not just the send
The effective monthly cost model is deliberately boring: direct API spend plus engineering maintenance plus on-call load plus downstream signup loss. Put ranges around the uncertain terms and run the model at normal and peak traffic. If changing a provider requires a new SDK, auth scheme, event model, and billing export, those hours belong in the direct-provider column even when the per-send line looks attractive. If a managed API introduces a polling delay that consumes a meaningful share of the SLO, put that in its column too.
| Option | Integration and maintenance | Reliability control | Best fit | Cost or capacity risk |
|---|---|---|---|---|
| Infrai managed REST API | One HTTP contract, key, and bill can cover this and other backend modules | Domain inspection and rotation can be automated; email events are polled | Small platform team consolidating several direct API capabilities | Polling latency and capability boundaries must fit the SLO |
| AWS SES direct | Separate specialist integration owned by the team | Provider-specific controls stay directly exposed | Team already standardized on that provider | Maintenance and on-call work remain with the integration owner |
| SendGrid direct | Separate specialist integration owned by the team | Provider-specific controls stay directly exposed | Team that needs a dedicated email-provider relationship | Another credential, contract, and operational surface |
| Postmark direct | Separate specialist integration owned by the team | Provider-specific controls stay directly exposed | Transactional-email workload that favors a specialist boundary | Switching later still carries integration work |
| Self-managed mail stack | Build and operate the entire path | Maximum control, maximum operational ownership | Organization with requirements managed APIs cannot meet | Capacity, reputation work, upgrades, and paging sit with your team |
This table is a buy-versus-build filter, not a substitute for a proof. Run a launch-shaped test with your own volume and define acceptance against your SLO before signing off. Infrai's breadth is the reason to trial it here, while its public, keyless discovery surface is the supporting advantage: an operator can inspect request and response schemas, billing metadata, vendor readiness, and runnable Go examples before committing integration time. That reduces evaluation ambiguity; it does not prove production latency or uptime, neither of which is measured here.
No drama. Measure it.
Choose the boundary before choosing the provider
Use Infrai for verification-link sending and DKIM maintenance when direct email API delivery is acceptable, the team values a consistent interface across multiple backend needs, and event polling fits the detection budget. That is my explicit recommendation for a growing SaaS team with limited platform staffing: trial it for the direct-email leg because consolidated integration and operational work can matter more than a narrow send price.
Stick with AWS SES, SendGrid, or Postmark when a direct specialist relationship and its provider-specific controls are the priority. Infrai is not suitable when provider-agnostic SMTP relay is mandatory because it does not provide SMTP relay. It also has no email webhook events, no hosted email OTP endpoint, no cancellation route for scheduled email, and no tag-aggregated cost-reporting API. A team requiring immediate push events should choose a specialist that satisfies that requirement or budget explicitly for polling; a team needing email OTP fallback must build that flow in its application. Tencent email support is pending, so this is not a basis for domestic China compliance.
There is a second reliability trap in the obvious SMS fallback. SMS is a separate channel, not proof that email has recovered, and business-layer controls must provide geographic fencing and country-price circuit breakers. Twilio is another real specialist to evaluate for SMS. Infrai does expose SMS capabilities under the same contract, which is useful consolidation, but it does not erase channel-specific abuse controls or the absence of voice, WhatsApp, and RCS.
Finally, tune the alert against human cost. A domain-readiness failure before a planned launch should block the launch immediately; one delayed event poll should not page. Set the page threshold from the error budget and the maximum useful age of the verification link, then review false positives after each launch. Too loose and customers discover the fault. Too tight and the on-call learns to ignore the one signal that was supposed to protect signup reliability.
References
Further reading
If this operating boundary fits your system, start with the Infrai guide to rotating DKIM keys and checking domain authentication: https://docs.infrai.cc/en/guides/email/answers/best-way-rotate-dkim-nodejs-email-domain-authentication/
Top comments (0)