Skip to main content
Live. This area is documented as current, user-reliable behavior.

Goal

Move a domain from pending to verified before using it as a production sender.

Prerequisites

  • DNS control for the sender domain
  • A StackShift API key

Workflow

1
Create the sender domain with /mail/domains or the SDK.
2
Publish every required DNS record returned by StackShift.
3
Run verify after DNS propagation.
4
Use the domain only after the aggregate status is verified.

Domain API

Status fields

  • domain.status is pending, verified, failed, or disabled.
  • spfStatus, dkimStatus, dmarcStatus, and returnPathStatus are missing, pending, verified, or failed.
  • records contains DNS records with type, name, value, status, required, and optional explanation.
  • Deleting a domain removes it from the StackShift sender-domain registry. It does not delete DNS records at your DNS provider.

Record types currently surfaced

  • TXT records are used for SPF or DMARC-style policy data.
  • CNAME records are used for delegated verification or return-path style routing.
  • MX records are used where mail routing requires them, especially inbound domain workflows.

Expected result

The sender domain has status verified and individual SPF, DKIM, DMARC, and return-path checks are not missing or failed.

Common failures

  • TXT or CNAME records were copied with the wrong host/name value.
  • DNS propagation has not completed when verify is run.
  • The domain remains failed or pending because one required record is missing.

Send email

Send a single outbound email with the official SDK or REST API, then inspect the message, attempts, logs, and timeline.

Bounces, suppressions, and reputation

Handle hard and soft bounces, workspace-scoped suppressions, sending limits, warmup stage, domain reputation, and reputation events.

Scheduling, batches, and attachments

Use first-class Mail APIs for delayed delivery, direct or template fan-out, batch inspection, and scanned asset-backed attachments.