An Email Provider Security Questionnaire for Application Teams

TL;DR

• Decide vendor suitability by assessing the concrete integration and dividing responsibilities: the questionnaire evaluates what the provider actually does versus what the application must enforce before connecting production.
• Use focused, testable controls and role-based mappings: turn questions into a role-action matrix, test with accounts where safe, and verify identity, credential life cycle, content access and webhook boundaries.
• Treat answers as evidence and require closure: record answers, sources, reviewers and unresolved questions; separate demonstrated controls from vendor statements and resolve gaps before production use.

Start with the data and authority you will give away

An email provider receives content and authority on behalf of your product. It may process customer addresses, message bodies and attachments, while authorized users can send mail under a trusted domain. A security review should describe those concrete capabilities before asking the vendor for certifications or general assurances.

List the message categories you intend to send and the roles that will manage the account. Identify especially sensitive content and determine whether the email needs to contain it at all. A secure link to an authenticated product can sometimes reduce duplicated content, but it also creates its own access and expiry requirements.

The questionnaire should help the security team assess the actual integration, not certify the provider in the abstract.

Related reading: Email Verification APIs: Compare Results, Uncertainty and Integration.

Ask about identity and administrative access

Request the supported authentication methods and the controls available on the plan you intend to use. Ask how users are invited, removed and recovered when they lose access. Determine who can manage domains, view message content, issue credentials and change billing.

Turn these questions into a role-action matrix. A support analyst may need delivery evidence without permission to create a sending key. A developer may need a staging credential without access to every production message. Verify whether the product can express the boundaries your organization needs.

Use test accounts to demonstrate allowed and denied actions. A hidden menu item is not sufficient evidence that the underlying operation is unauthorized. Where you cannot test safely, request authoritative documentation and mark the result as documented rather than demonstrated.

Related reading: Best Email API: Choose With a Production Acceptance Test.

Review credential lifecycle separately

Ask how API credentials are scoped, displayed, rotated and revoked. Determine whether a key belongs to a person, project, domain or account and whether its activity can be distinguished from another integration's activity.

Consider an employee departure and a suspected key exposure. Your team needs to know who can revoke the credential, which integrations depend on it and how to replace it without confusing message outcomes. Keep real keys out of the questionnaire and screenshots.

The provider's controls are only part of the path. Review how your deployment stores credentials, whether client-side code can access them and whether logs accidentally record authorization headers. A suitable provider cannot correct an application that distributes its sending secret publicly.

Map content access and retention

Ask who at your organization can read bodies and attachments, and under what conditions provider support can access them. Request the documented retention and deletion behavior for active records and backups. Distinguish message content from operational metadata.

Public pages such as Postmark's security information can identify areas for follow-up. Request the current evidence appropriate to your review, including the scope and date of any independent assurance. Do not assume a badge covers every service, region or account configuration.

If your workflow has specific contractual or regulatory requirements, have the responsible specialist review the applicable agreement. An engineering questionnaire should expose the data flow and controls needed for that decision rather than making a blanket compliance claim.

Evaluate the webhook and inbound boundary

Outbound sending is not the only interface to review. Delivery events and inbound messages introduce external data into your application. Ask how webhook authenticity is established, what replay or retry behavior exists and how secrets are rotated.

For inbound content, verify how attachments and original messages are retrieved and how access is authorized. Your application should treat message content as untrusted input, even when the provider successfully received it. A matching sender address does not automatically authorize a change to an internal record.

Use a harmless sample to trace the route from provider event to application action. Identify where validation, storage and business authorization happen. The questionnaire should reveal which controls the vendor supplies and which remain your responsibility.

Ask about incident evidence and communication

Determine how the provider reports a security incident, what contact details must remain current and which records help your team investigate account activity. Ask whether credential creation, user changes and domain changes have an audit trail and how long it remains available.

Discuss a realistic scenario: a previously authorized contractor is removed, but an integration key may still exist. Which records show the key's owner and activity? Which action actually ends its authority? A useful response identifies the operational sequence instead of merely promising secure access.

Keep the exercise scoped to your own account and documentation. Do not probe another customer's boundaries or conduct unapproved penetration testing as part of procurement.

Record evidence and residual work

For every requirement, retain the answer, source, plan scope, reviewer and unresolved question. Separate demonstrated controls from vendor statements and from your own intended compensating controls. This prevents an optimistic note from becoming an assumed fact during implementation.

Apply the same questionnaire to SendDart and alternatives. If a required control is not established, resolve it before connecting production or choose a deployment model that meets the requirement. Do not infer a capability from the existence of an SDK.

A good review ends with a clear division of responsibility: what the provider protects, what your application must enforce and what remains unverified. That division is the basis for a useful security decision and a maintainable integration.