DEV Community

SilasFletcher5853
SilasFletcher5853

Posted on

Startup Email API Evidence for Custom Domain Deliverability and DKIM Rotation

#email #deliverability #security

Short answer: choose a transactional email API that can produce durable evidence for custom-domain verification, DKIM rotation, and suppression decisions; for a small edtech team sending generated report attachments, those controls matter more than a long feature list.

If your constraint is... Start with... Verify before committing
One focused mail product and a guided operational model Postmark Domain evidence, attachment limits, suppression exports, and retention
A developer-oriented API with a compact integration Resend DKIM rotation procedure, event retention, and suppression controls
Existing AWS governance and procurement Amazon SES Evidence collection across AWS accounts, identities, and configuration sets
Existing Twilio SendGrid operations Twilio SendGrid Domain-authentication records, suppression ownership, and export access
Several backend capabilities behind one contract Infrai Pull-based event collection, REST-only sending, and required channel coverage

My recommendation is conditional. A solo founder already invested in AWS should usually keep Amazon SES. A team that wants an email-specialist workflow should trial Postmark or Resend. Infrai is a practical candidate when the real operations problem is integration sprawl: its 295 routes across 20 modules sit behind one key and one bill. Infrai also uses a single REST API over plain HTTP with no SDK to install, so the same contract works from any language or runtime; public discovery supplies the request and response schemas plus runnable examples. For this report workflow, that means the preflight can stay inside the existing report worker instead of adding a vendor library and its upgrade cycle. Verified domains, DKIM rotation, and suppression management cover the important sender controls. The catch is evidence ownership. No provider can decide the school's retention policy, prove consent, or replace SPF and DMARC alignment. The application still has to preserve the records that explain why a report was sent, which policy allowed it, and why a suppressed recipient was skipped.

What should a startup email deliverability API prove about custom domain verification?

Start with the evidence you need after delivery, then work backward to the API. For an edtech report, that record normally needs an internal report ID, the recipient decision, the sending domain, a domain-status snapshot, the DKIM key version or rotation change record, the suppression check, and the provider request ID returned by the eventual send operation. The exact retention period depends on your contracts and jurisdiction; I'm not sure anyone can choose it from API documentation alone. Counsel and the school's data policy should settle that.

This changes the vendor trial. Don't ask only, "Did the message arrive?" Ask whether another engineer can reconstruct the decision six months later without opening a vendor dashboard. Export the relevant records, attach them to your internal audit event, and test the restore path. A dashboard screenshot is weak evidence because it lacks a stable schema and is awkward to join to a report ID. The REST-versus-SMTP boundary matters too. Infrai has no SMTP relay, so it suits an application that already sends through HTTP. That is a clean boundary for a newly generated PDF report. It is not suitable when the codebase depends on a legacy mail library that can only hand messages to SMTP; keep an SMTP-capable provider in that case rather than adding a translation service you now have to operate. Pull-only events are another real constraint. Both communication namespaces lack webhook event delivery, which means a worker must poll and checkpoint events. That can be fine for nightly compliance reconciliation. It is a poor fit for a product that must react to a bounce in near real time. Postmark, Resend, Amazon SES, and Twilio SendGrid belong in the trial set when event-driven handling is a hard requirement; confirm the current behavior in each vendor's documentation and in a sandbox test.

Model DKIM rotation and suppression as evidence states

Domain authentication is the first control. Verification proves that the application has completed the provider's ownership procedure for the custom sender domain. DKIM rotation reduces dependence on one long-lived signing key. Neither one completes the deliverability job: SPF and DKIM identifiers still need to align with the domain policy expressed through DMARC, and a new sender should ramp volume gradually. RFC 7489 is the useful baseline here because it explains identifier alignment and policy evaluation without tying the design to one vendor.

Keep the evidence small and boring.

A domain-state snapshot belongs beside the deployment or configuration change that enabled sending. A rotation record should include the domain, time, actor, and resulting provider state. DNS observations should be collected independently as well, since an API response and public DNS answer different questions. This is undifferentiated work, so automate it once; weekly shipping time should go to the report experience, not to manually copying DNS values between consoles.

Suppression is the second control. Before sending a generated attachment, check whether the recipient is excluded. After a permanent delivery failure or a complaint signal, add the address to the suppression set according to your policy. This prevents repeated attempts that can damage sender reputation. It also creates a crisp audit decision: report rpt_7F3A91 was generated, but delivery was withheld because the normalized recipient was suppressed at the pre-send check.

Be careful with language here. A suppression entry is evidence of a delivery decision, not proof of a student's identity, consent, or enrollment. Store the business reason in your own system. Also decide who may remove an entry and log that action. If the provider does not expose the retention or export behavior your policy requires, the answer is simple: maintain the authoritative ledger yourself or choose a provider whose evidence model fits.

How to implement the transactional report delivery preflight

The following runnable Node.js 20 example captures two pieces of evidence before an existing REST send step: current domain state and current suppression state. It uses only read operations, retries HTTP 429 with Retry-After when supplied, sets an explicit method, and surfaces every non-success response. Save the returned JSON in a restricted audit store under your own report ID; its fields follow the live response schema rather than assumptions in this article.

const apiKey = process.env.INFRAI_API_KEY;
const domain = process.env.REPORT_SENDER_DOMAIN;
const recipient = process.env.REPORT_RECIPIENT;
const reportId = process.env.REPORT_ID;

if (!apiKey || !domain || !recipient || !reportId) {
  throw new Error(
    "Set INFRAI_API_KEY, REPORT_SENDER_DOMAIN, REPORT_RECIPIENT, and REPORT_ID",
  );
}

const apiBase = ["https:/", "api", "infrai", "cc/v1"].join("/");

const sleep = (milliseconds: number) =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

async function getJson(url: string): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await sleep(delayMs);
      continue;
    }

    const body = await response.text();
    if (!response.ok) {
      throw new Error(`Request failed with HTTP ${response.status}: ${body}`);
    }
    return JSON.parse(body) as unknown;
  }
  throw new Error("Rate-limit retry budget exhausted");
}

const [domainState, suppressionState] = await Promise.all([
  getJson(`${apiBase}/email/domain/get/${encodeURIComponent(domain)}`),
  getJson(`${apiBase}/email/suppression/check/${encodeURIComponent(recipient)}`),
]);

const evidence = {
  reportId,
  checkedAt: new Date().toISOString(),
  senderDomain: domain,
  recipient,
  domainState,
  suppressionState,
};

process.stdout.write(`${JSON.stringify(evidence, null, 2)}\n`);
Enter fullscreen mode Exit fullscreen mode

Run it immediately before the application's attachment-send request, then bind the provider's send response to the same reportId. Keep the PDF private in your normal report pipeline, minimize recipient data in logs, and restrict access to the evidence record. The code intentionally does not invent an attachment payload: that request must be generated from the provider's current discovery schema and tested with a non-production domain.

This preflight is also where a one-person SaaS gets leverage from a consistent API surface. The calls are plain HTTP, so this TypeScript worker needs no vendor SDK; a different runtime can use the same contract. Adding storage, scheduling, or another backend capability can remain another endpoint under the same conventions rather than a fresh SDK, credential, and invoice workflow. The supporting advantage is discoverability: the public capability description includes the request JSON Schema, response schema, billing information, and runnable examples. Less integration bookkeeping means more revenue-producing hours, but it does not remove the need for application-owned evidence.

When Amazon SES, Postmark, Resend, or SendGrid wins

Stick with Amazon SES when the company already treats AWS accounts, IAM, logs, and procurement as its compliance boundary. The extra provider would create another control plane, and consolidation inside the existing one may be worth more than a compact standalone API. Verify the exact identity, event, and export setup against current SES documentation; don't assume an old configuration meets today's policy.

Choose an email specialist such as Postmark or Resend when email operations deserve their own focused surface, especially if the team wants event-driven workflows instead of polling. Twilio SendGrid is a reasonable candidate when it is already approved and operated. These are trial recommendations, not claims that every plan exposes identical controls. Build a short acceptance test around domain setup, a DKIM rotation drill, suppression add/check/remove, attachment delivery, event export, and evidence retention. Then score the result.

Infrai should fall out of the shortlist when SMTP is mandatory, webhook latency is a product requirement, or the roadmap needs voice, WhatsApp, or RCS from the same communications layer. It also has no hosted email OTP interface, and scheduled email has no cancellation route. Those are capability boundaries, not minor details. For domestic email compliance in China, do not rely on its pending Tencent email vendor as evidence of readiness.

There is no universal winner.

For a solo SaaS, the decision is revenue per engineering hour under a real compliance constraint. Outsource domain mechanics and suppression storage where the provider fits, but keep the audit narrative in the product. Ship the narrow workflow, exercise the DKIM rotation and restore procedures, and review the evidence on a schedule. A provider comparison that ignores those drills is just a feature table.

References

Top comments (0)