GDPR-compliant email sending for developers

If you send email to users in the European Union, GDPR applies to you regardless of where your company is based. For developers building transactional email flows, this means making specific technical decisions about how you collect, process, store, and transmit personal data.

This guide covers the practical requirements you need to address and how to implement them in your email sending infrastructure.

What GDPR requires for email sending

GDPR defines personal data broadly. Email addresses, names, IP addresses, and any identifiable metadata in your emails all fall under its scope. When you send an email, you are processing personal data. The regulation requires a lawful basis for that processing, data minimization, storage limitations, and security safeguards.

For transactional emails specifically (password resets, order confirmations, account notifications), the lawful basis is typically "legitimate interest" or "performance of a contract." You do not need explicit opt-in consent for emails that are necessary to fulfill a service the user requested. However, you must still handle the data properly.

Lawful basis and consent

Transactional vs. marketing email

Transactional emails have a clear lawful basis: the user initiated an action (purchased a product, requested a password reset, created an account) and the email is necessary to fulfill that action. You do not need separate consent for these.

Marketing emails require explicit opt-in consent under GDPR. If you are sending promotional content, the user must actively agree to receive it, and you must record when and how they consented.

What to store

For every email you send, record:

• The lawful basis for processing (contract performance, legitimate interest, or consent)
• For consent-based emails: the timestamp, method, and scope of consent
• The data processing purpose

// Example: recording consent at signup
const consentRecord = {
  userId: user.id,
  email: user.email,
  consentGiven: true,
  consentTimestamp: new Date().toISOString(),
  consentMethod: 'signup-form-checkbox',
  purpose: 'account-notifications',
};

await db.insert(consentRecords).values(consentRecord);

Data residency and location

GDPR restricts the transfer of personal data outside the European Economic Area (EEA) unless adequate safeguards are in place. For email sending, this means you should know where your email provider processes and stores data.

If your users are in the EU, choose an email provider that offers EU data hosting. This simplifies compliance because the data never leaves a jurisdiction with adequate protection.

Providers differ a lot here: some keep everything in the EU by default, others only route your emails through EU servers while storing logs and account data in the US. The EU data residency comparison breaks down what SendGrid, Mailgun, Postmark, Resend, and Nuntly store where, verified against each vendor's own documentation.

Nuntly provides EU data location by default on every plan, so email processing and storage stay within the EU without a regional add-on to configure.

Key considerations for data residency

• Processing location: Where does the email provider's infrastructure process your emails? Ensure it stays within the EEA or a country with an adequacy decision.
• Storage location: Where are email logs, event data, and metadata stored? These contain personal data and must comply with the same rules.
• Backup and redundancy: Confirm that backups and redundant storage also remain in compliant locations.

Encryption and security

GDPR Article 32 requires "appropriate technical and organizational measures" to protect personal data. For email sending, this translates to specific security requirements.

In transit

All communication between your application and your email provider must use TLS encryption. Verify that your SDK or API client enforces HTTPS connections.

import { Nuntly } from '@nuntly/sdk';

// The Nuntly SDK enforces HTTPS by default
const nuntly = new Nuntly();

// All API calls use TLS encryption automatically
const { data } = await nuntly.emails
  .send({
    from: 'notifications@yourdomain.com',
    to: 'user@example.com',
    subject: 'Your invoice is ready',
    html: '<p>Download your invoice from your account dashboard.</p>',
  })
  .safeAwait();

At rest

Email content, metadata, and event logs stored by your provider should be encrypted at rest. Check that your provider uses encryption for all stored data, including databases, file storage, and backups.

For more information on the security measures Nuntly implements, see the security features page.

Authentication

Use strong authentication for your email API access. API keys should have the minimum scope required, and you should rotate them regularly.

// Use environment variables for API keys
const nuntly = new Nuntly(); // reads NUNTLY_API_KEY from environment

// Create scoped API keys for different services
// Each service gets only the permissions it needs

Data minimization

Only include the personal data that is necessary for the email's purpose. Avoid embedding unnecessary personal information in email content, headers, or metadata.

Practical steps:

• Do not include full user profiles in email metadata or tags. Use anonymized identifiers where possible.
• Strip unnecessary personal data from webhook payloads before logging them.
• Avoid storing email content longer than necessary for your debugging or compliance needs.

Data retention and deletion

GDPR requires that you do not keep personal data longer than necessary. Define retention periods for:

• Email logs: How long do you keep records of sent emails? Set a retention policy and automate deletion.
• Event data: Delivery, open, and click events contain personal data (email addresses, IP addresses, user agents). Define how long you retain this data.
• Webhook logs: If you log incoming webhook payloads, set a retention period for those logs as well.

Handling deletion requests

Under GDPR, users can request deletion of their personal data. Your system must be able to:

1. Identify all email-related data for a given user.
2. Delete or anonymize that data within the required timeframe (typically 30 days).
3. Confirm deletion to the user.

DKIM, SPF, and DMARC

Email authentication protocols protect both your sender reputation and your recipients. GDPR does not mandate specific protocols, but proper email authentication demonstrates technical security measures.

• DKIM signs your emails cryptographically, proving they were sent from an authorized server.
• SPF specifies which servers are allowed to send email on behalf of your domain.
• DMARC ties DKIM and SPF together with a policy that tells receiving servers how to handle authentication failures.

Configure all three for every sending domain. Nuntly generates the required DNS records automatically when you add a domain.

Checklist for developers

Use this checklist when building or auditing your email sending flow:

• Identify the lawful basis for each type of email you send
• Record consent with timestamp and method for consent-based emails
• Confirm your email provider stores and processes data in a GDPR-compliant location
• Verify TLS encryption for all API communication
• Confirm encryption at rest for stored email data
• Implement data minimization in email content and metadata
• Define and enforce retention periods for email logs and event data
• Build a process for handling data deletion requests
• Configure DKIM, SPF, and DMARC for all sending domains
• Document your data processing activities for accountability

Moving forward

GDPR compliance is not a one-time task. As your application evolves and you add new email types, review each new flow against these requirements. Automated testing can help catch regressions, such as accidentally including extra personal data in email metadata.

For a platform that simplifies many of these requirements with built-in EU data hosting and security features, explore what Nuntly offers for compliance-conscious teams.