Microsoft Azure Communication Services
Production email delivery runs through Azure Communication Services. Provider outcomes return to NoticeAPI logs, suppressions, webhooks, and health controls.
Security and data practicesSecurity you can
Security you can
verify for yourself.
Review the concrete controls protecting production email: scoped grants, signed callbacks, verified senders, limited operator access, and scheduled event retention.
This page describes shipped controls; it does not substitute subprocessor certifications for a NoticeAPI certification.
Evidence mapSecurity reviewInspectable
01AuthorizationCapability, project, and domain grants
grant02IntegrityHMAC-SHA256 webhook signature
header03SenderDNS ownership, SPF, and DKIM state
records04LifecyclePlan-level event retention window
policyStart with the evidence
What a security review checks first.
Each boundary has a concrete representation in the product or API instead of relying on a broad security promise.
API access
Keys carry an explicit grant
A key can select capabilities, projects, and domains. A key with management access can mint only an equal or narrower grant.
CallbacksWebhook payloads are signed
NoticeAPI signs the raw payload with HMAC-SHA256 and sends the result in x-noticeapi-signature.
SenderProduction domains are verified
Production sending requires DNS ownership, SPF, and DKIM checks. DMARC guidance is published with the generated records.
RetentionEvent history has a fixed window
The retention task purges send and recipient-event records after 30 days on Free and Pro or 90 days on Custom.
Service path
The infrastructure in the email path.
These are the named service roles behind delivery and application storage, plus the controls NoticeAPI applies before a request reaches them.
Private PostgreSQL
Application and operator data use the configured production PostgreSQL store. Database access stays on the private application infrastructure path.
Edge and application controls
Production traffic reaches the application through an edge route. Request limits, tenant authorization, and plan checks run in NoticeAPI.
Boundaries, not badges
Transport, sender, and operator controls.
The implementation details below are deliberately narrower than a compliance claim.
Encrypted transport
The public API and portal use HTTPS. The SMTP relay listens on smtp.noticeapi.com:465 with implicit TLS.
Sender integrity
The From domain must resolve to a verified sending domain before API or SMTP production traffic can use it.
Verified operator identity
Admin routes require a signed-in, email-verified account on the configured operator allowlist. Sensitive operator changes create account events.
Published certification boundary
NoticeAPI does not claim its own SOC 2, HIPAA, or equivalent certification. Subprocessor audits are not represented as NoticeAPI audits.
Read the source
Policies and implementation docs.
Use these pages to evaluate the exact retention, sender, callback, recipient-state, and error behavior your application depends on.
Privacy policyWhat NoticeAPI collects, how it is used, and the published retention terms.TermsService rules, billing, customer data, and limits of liability.Domain docsVerify ownership, SPF, and DKIM records for a production sender.Suppression docsHow bounce, complaint, provider, opt-out, and manual recipient blocks behave.Webhook docsVerify x-noticeapi-signature over the raw request body.Errors and limitsStable status and error codes applications can handle explicitly.
Verify the callback path
Start with a signed test event.
Use the simulator, inspect the webhook request, and verify its signature before moving the same handler to production events.