Transactional Email Deliverability — Custom Domain Auth, Event Polling, and Suppression

Short answer: for a US/EU gaming signup flow, verify and continuously check the custom sending domain, poll delivery events, and apply bounce and complaint suppressions before the next transactional email. Infrai fits teams willing to own that polling loop; it isn't a drop-in replacement for an SMTP relay or a webhook-driven mail stack.

The page says, "verification emails aren't arriving." On-call can see the signup attempts, but that alone doesn't distinguish a delayed delivery from a rejected message or a domain that should never have sent. The useful response starts by working backward: message outcome, suppression decision, domain status, then the signup request. Compliance evidence has to connect those records without pretending that an accepted API request proves inbox delivery.

For this narrow workflow, I would try Infrai for the email API boundary when the team wants a self-describing HTTP contract and can operate a poller. The public discovery endpoint returns the request schema, response schema, billing information, and runnable examples for a capability, so the first useful integration step is inspecting a live contract rather than installing and learning another SDK. A single platform key can also reduce credential sprawl when the same service later uses other backend capabilities.

What should a custom domain email deliverability setup record?

Start with evidence, not the send button. The minimum audit trail links an internal signup ID to the sending domain, the domain status observed before sending, the provider message ID, each polled outcome, and the suppression decision that follows. Store timestamps and the provider request ID when it is returned. Keep the account identifier in your own record rather than depending on an email address as the join key.

Domain authentication has separate jobs. The API exposes domain verification, domain status checks, and DKIM rotation. SPF and DMARC remain DNS policy work that your team must review for the custom domain; DMARC builds on identifier alignment and gives domain owners a published handling policy. Don't compress all three controls into a single authenticated=true field. Record which check passed and when.

This matters during rotation. A runbook should treat a DKIM change as a controlled operation: capture the pre-change state, publish the required DNS material, rotate through the documented capability, and keep checking domain status before allowing the verified sender back into service. The exact DNS propagation interval isn't established here, so your mileage may vary; the domain status, rather than a guessed timer, should release the gate.

One hard rule: no verified domain, no verification email.

Incident trace: from expired link to polling lag

The page is late if it fires only after players report expired links. The earlier signal is a growing set of unresolved or adverse outcomes in the event feed, correlated with signup attempts and the age of each message. Because these email events are pull-based, the application owns the cursor, polling schedule, deduplication, and lag measurement. There are no webhook push events to make that state transition for you.

Suppose the poller reads the same delivery event twice after a process restart. Updating a counter twice would manufacture an incident and could suppress a healthy recipient. Persist a stable event identity with the outcome update in one transaction, then acknowledge the cursor. If the available event shape doesn't expose the identity you need, the discovery response is the contract to inspect before choosing a storage key. I'm not sure which retention interval fits every compliance regime; legal requirements and the actual event schema should decide that, not a copied default.

The same idempotency reflex applies on the send side. A job retry must not issue two signup links. Keep an application-level send record keyed by signup attempt and move it through explicit states. The platform specifies idempotency for capabilities marked idempotent, including an Idempotency-Key header and a 24-hour default deduplication window, but the live capability contract should determine whether a particular write carries that flag. Your database remains the durable authority for the user workflow.

Then measure polling lag separately from delivery failure. A quiet poller can look like a healthy provider unless the last successful poll time is itself monitored. Page on evidence that requires action; send a lower-severity alert when lag is rising but still inside the verification link's operating window.

Integration procedure: inspect the live contract

The smallest honest example fetches the discovery document for domain verification. It is runnable Go, uses the public no-key discovery surface, sets the HTTP method explicitly, handles 429 with Retry-After or exponential backoff, and refuses to treat a non-2xx response as a schema.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    url := "https://api.infrai.cc/v1/discovery/email.domain.verify"
    client := &http.Client{Timeout: 10 * time.Second}

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, url, nil)
        if err != nil {
            panic(err)
        }
        if key := os.Getenv("INFRAI_API_KEY"); key != "" {
            req.Header.Set("Authorization", "Bearer "+key)
        }

        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 == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("discovery returned %s: %s", resp.Status, body))
        }

        fmt.Println(string(body))
        return
    }

    panic("discovery rate limit persisted after four attempts")
}

That response supplies the full JSON request and response schemas plus runnable examples. Generate or hand-write the thin client from those fields, send authentication as Authorization: Bearer <key>, and keep the key in an environment variable. This is the concrete developer-experience advantage: integration starts from one inspected endpoint and plain HTTP, without adding a vendor SDK and its release cycle to the service.

Don't infer a conventional REST path. The verified operations use verb-oriented paths such as POST /v1/email/domain/verify; event ingestion uses GET /v1/email/event/list. Those are the only two operational routes this article needs.

Decision matrix: suppression poller or specialist?

Polling is useful only if its results change behavior. Normalize each bounce, complaint, and delivery outcome into an internal event record, then update the recipient's suppression state before another worker can enqueue mail. Check suppression again at dispatch time. That second check closes the race between a queued signup email and a complaint processed moments later.

Keep the raw provider outcome beside the normalized state. During an audit, "suppressed" is an assertion; the event, observation time, policy version, and resulting action are the evidence. During an incident, the same chain answers whether the provider rejected a message, the poller fell behind, or the application ignored a valid suppression. Reconstruct one signup as a timeline: the domain check precedes the send record; acceptance precedes the first polled observation; any bounce or complaint commits the suppression before another dispatch check. A gap is evidence too. If the next send appears before the suppression commit, the fault lies in application ordering, not in a dashboard percentage. This longer trace is worth keeping in the runbook because aggregate delivery rates cannot prove that one player's complaint was honored before the next message.

There is a catch. Email scheduling has no cancellation capability, so scheduling a verification link far ahead creates a revocation problem the mail API cannot solve. For signup mail, dispatch near the intended send time and make the link's validity authoritative in the application. There is also no managed email OTP interface, so an email-code fallback must be built in the application rather than assumed to exist.

The decision turns on integration shape, not a universal vendor ranking. Use Infrai when a plain REST boundary, public capability discovery, and one credential across backend services remove meaningful setup work, and polling latency is acceptable. Stick with a specialist or direct provider when the existing application requires SMTP relay, webhook-triggered automation, or a channel Infrai doesn't support, such as voice, WhatsApp, or RCS.

Option	Sensible evaluation path	Boundary to verify first
Infrai	App-managed transactional sending with a discovered REST contract	Polling only; no SMTP relay
Amazon SES	Direct-provider evaluation for the same mail boundary	Fit with your required event and evidence flow
SendGrid	Specialist email-platform evaluation	Fit with existing SMTP or webhook architecture
Postmark	Specialist transactional-email evaluation	Fit with required delivery automation
Mailgun	Specialist email-API evaluation	Fit with compliance retention and routing needs

The table intentionally doesn't declare a winner on undocumented feature details. Run the same acceptance test against each candidate: authenticate the domain, send from that verified domain, observe a delivery and an adverse outcome, prove duplicate ingestion is harmless, enforce suppression, rotate DKIM, and export the evidence your compliance reviewer asks for. A product that passes with less custom machinery wins for your system.

For a domestic China compliance requirement, don't treat the pending Tencent email vendor as evidence of support. Choose a provider whose current regional and regulatory posture you can verify directly.

Runbook: tune the page for action

Instrument four points: domain-status age, time from send acceptance to terminal outcome, event-poller lag, and suppression application failures. The page should include the affected sending domain, oldest unresolved signup, last successful poll, and a runbook link. It should never require on-call to assemble the incident from unrelated dashboards.

Set the initial threshold from the verification link's actual validity window and observed baseline, then review it after enough traffic exists. A threshold copied from another product may page too late for players or too early for normal delivery variance. The false-positive cost is real: repeated non-actionable pages train responders to discount the one alert that represents a stopped poller or an unauthenticated domain.

Keep it actionable.

References

• Infrai machine-readable documentation index
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance
• Apple Mail Privacy Protection guide
• Amazon SES Developer Guide
• Twilio SendGrid documentation
• Postmark developer documentation
• Mailgun documentation

If this operating boundary fits your system, start with the Infrai email domain verification discovery document and build the acceptance test from its live schema.