SendHog features
Domain-first application email: guided authentication, scoped keys, retained message history and provider-shaped SDKs on SendHog’s independent API.
Start without operating an AWS email account
SendHog manages the provider layer so your team does not configure an AWS sending account, IAM policies or its own SES production-access request.
Connect through SendHog’s API and schema-generated SDKs. Sending is automatically approved when your domain is verified. Recipient consent, account limits and abuse protections still apply.
Install the SDKManaged sending, provider feedback processing and saved delivery outcomes.
Authentication setup in one flow
Follow domain-specific SPF, DKIM and DMARC guidance rather than gathering configuration from separate provider screens. Publish the records in your DNS and confirm the verification checks.
A monitoring DMARC policy is not enforced rejection, and authentication does not guarantee inbox placement. Use the policy appropriate to your domain and all of its legitimate senders.
SPF and DKIM checks
Establish domain ownership and authenticated custom-domain sending.
DMARC guidance
Understand the domain policy instead of assuming a generated record guarantees enforcement.
Managed provider configuration
Your team owns DNS and content; the service owns the underlying sending configuration.
Message history in one place
Inspect retained sent and received messages in the domain’s email log. Read metadata and plain text through a backend key with explicit read permission.
Feedback ingestion, suppression enforcement and production dispatch remain readiness gates. Open/click tracking and provider webhook compatibility are not part of the current SDK subset.
Read the message retrieval guideSearchable message history
Find retained messages by sender, recipient or subject.
Sent and received views
Keep both directions scoped to the selected domain.
Explicit read permissions
Existing sending keys cannot read mail without a new read-scoped credential.
Keep readiness visible
See domain verification, receiving readiness and sending status alongside your retained message history. Verified domains receive automatic sending approval; operators can disable sending when necessary.
These states are not an independent reputation score or a promise of inbox placement.
Infrastructure is managed; reputation is shared work
New customer domains still need legitimate sending history, recipient consent, list hygiene and responsible volume changes.
Abuse protections apply to sending. Do not assume a new domain inherits an established reputation or receives an unrestricted starting rate.
Familiar application calls
Choose the supported SES, Postmark, Resend or SendGrid SDK style. Change imports, client setup and credentials; keep supported simple-send calls and result access.
The same schema generates JavaScript/TypeScript and Python clients, validated models and documentation examples. Templates, scheduling, attachments and campaigns are outside this version.
One API contract
Download JSON Schema and OpenAPI from the API reference.
Provider and language selection
Read the example in the SDK style your application already uses.
Scoped integration credentials
Limit application access to its domain and selected mail actions.
Usage and service scope
SendHog plans focus on outbound sending. Retained-message reads and receiving activation have separate permission and readiness requirements.
Read the pricing detailsUnderstand the boundaries
A SendHog domain does not establish isolated sending reputation. Dedicated IPs, certifications, enterprise SLAs and guaranteed inbox placement are not included claims.
SDK compatibility is limited to the documented application-method subset. Original provider authentication, endpoint-only migration and complete webhook compatibility are not supported.