Sooner or later a security review lands on the email provider. Email carries personal data, password reset links, invoices and sometimes health or financial details, and the provider that sends it is a processor of that data. Security teams and procurement ask for a questionnaire, and engineering is asked to fill the gaps. Searches for a "secure email delivery service" or a "GDPR compliant email sending service" come from exactly this moment. This guide gives CTOs and technical leads a practical way to run that review. It lists the questions that matter in eight areas (data handling, access control, credentials and API security, transport and message security, infrastructure and operations, incident response, compliance documents and exit), says what a good answer looks like, explains how to treat badges and certifications and describes the controls you must implement on your own side, which a vendor cannot do for you. It does not claim that any particular provider holds any particular certification. Ask each vendor for documents, verify scope, and keep what they give you in your vendor file. We answer these questions for our own service on request through our contact page. This is general information, not legal advice; involve your security, privacy and legal teams.
Start by mapping the data
Before sending a questionnaire, write down what data goes through the provider. Typical categories are recipient email addresses, names, message content, attachments, links and tracking data, and metadata such as IP addresses and timestamps. Note which messages contain sensitive data (for example, account recovery links, invoices, medical or financial details) and which could be moved out of the email body to reduce exposure. Sending a link to a secure page is safer than sending the sensitive content itself. The shorter the list of sensitive data in email, the shorter and easier the review.
The questionnaire
1. Data handling and privacy
- Which role does the provider take under data protection law, and is a data processing agreement available?
- Where is data stored and processed, and can you choose a region?
- Which sub-processors are used, and how are changes notified?
- What data is stored (message content, recipient addresses, logs), for how long and in what form?
- Can message bodies be excluded from storage or shortened in retention?
- How are deletion requests handled, and what happens to your data when the contract ends?
- Is customer data used for any purpose other than providing the service?
A good answer is specific: named regions, stated retention periods, a sub-processor list and a process for deletion.
2. Access control
- Does the dashboard support multi-factor authentication, single sign-on and role-based permissions?
- Can you create separate users with limited roles, for example billing-only or read-only?
- Who at the provider can access your data, under what conditions and with what logging?
- Is there an audit log of configuration changes and logins that you can export?
3. Credentials and API security
- Can you create multiple API keys and SMTP credentials, each scoped and individually revocable?
- Are keys shown only once and stored hashed?
- Can keys be restricted by permission, and by source address where sensible?
- Are webhooks signed so that you can verify authenticity?
- Are there rate limits and anomaly alerts for unusual sending?
4. Transport and message security
- What TLS versions and ports are supported for submission? Our relay is
smtp.migosmtp.comon port 587 with STARTTLS. - How does the provider handle TLS when delivering to recipients' servers, including when TLS is unavailable?
- Does the provider sign with DKIM using keys you can rotate, and support DMARC alignment? See authenticating your sending domain.
- Does the service support secure link tracking domains on your own domain?
5. Infrastructure and operations
- How is the infrastructure hosted and segmented, and how are customers isolated from each other?
- How are changes deployed and vulnerabilities managed?
- Are backups taken and tested, and how is availability designed?
- How does the provider prevent abuse from other customers affecting your reputation? See dedicated vs shared IPs.
6. Incident response
- How and how quickly are customers notified of a security incident affecting their data?
- Is there a documented incident response process, and have they exercised it?
- How are service incidents communicated, and is a status history public?
7. Compliance documents
- Which independent attestations or certifications exist, and what is their scope (which products, locations and period)?
- Can the provider share the actual reports or summaries under confidentiality?
- Is there a security whitepaper or a completed standard questionnaire?
- Are sector-specific agreements available for your use, for example for health data? If you handle regulated data, confirm in writing before sending any.
8. Exit
- Can you export logs, suppression lists and templates?
- How long after termination is data retained, and how is deletion confirmed?
How to read the answers
| Answer type | How to treat it |
|---|---|
| Specific, documented, with a document to attach | Good. File it |
| "We take security very seriously" | Not an answer. Ask the question again, more specifically |
| A certification badge | Ask for the report and check the scope covers the service and region you will use |
| "Compliant with GDPR" | Compliance is a shared responsibility. Ask for the processing agreement, sub-processor list and data location |
| No answer, or "not applicable" | Record as a gap and decide whether to mitigate or reject |
Controls you must implement on your side
Many incidents involving email providers come from the customer's side, not the vendor's.
- Separate credentials per service and environment, stored in a secret manager and rotated on a schedule.
- Least privilege. A service that only sends should not hold keys that read logs or manage domains.
- Monitor sending volume per credential and alert on spikes, since a leaked key is often used for spam.
- Dashboard access: single sign-on or multi-factor authentication, named users and prompt removal of leavers.
- Minimise sensitive content in message bodies; use links to authenticated pages.
- Verify webhook signatures, and restrict who can read event data.
- Protect DNS. Anyone who can change your SPF, DKIM or DMARC records can change who can send as you. Limit and log DNS access.
- Enforce DMARC at an appropriate policy once monitoring shows legitimate sources are aligned. See DMARC records.
- Prevent header injection and validate user input used in messages.
Record and revisit
Keep the completed questionnaire, the documents received and the contract in a vendor file with a review date. Review annually, and when your data, volume, regions or provider terms change. Link your review to your vendor scorecard so security is weighed with reliability and cost. When you plan to change providers, remember that exit also has a security dimension: revoke old credentials and remove old DNS entries. See the migration checklist.
Common mistakes
- Accepting a certification logo without checking scope.
- Putting sensitive content in the email body when a link would do.
- Sharing one API key across services and environments.
- Leaving former staff with dashboard access.
- Forgetting that DNS access controls who can send as your domain.
- Running the review once and never again.
Ask us your security questions Send your questionnaire and we will answer it in writing for our SMTP relay and email API.
References and further reading
Frequently asked questions
What should a security review of an email provider cover?
Data handling and privacy, access control, credentials and API security, transport and message security, infrastructure, incident response, compliance documents and exit.
Is a certification badge enough evidence?
No. Ask for the report or summary and check that its scope covers the product, region and period you will use.
Is a GDPR compliant email provider enough to make me compliant?
No. Compliance is shared. You still need a lawful basis, a processing agreement, an accurate understanding of data location and sub-processors, and your own controls.
What can a provider not do for me?
Control your credentials, dashboard access, DNS changes, the sensitivity of message content and monitoring for unusual sending. These are your controls.
How often should I repeat the review?
At least yearly, and whenever your data types, volume, regions or the provider's terms change.