How to Ensure Sensitive Data Isn’t Stored on Resend

If you need to ensure sensitive data isn’t stored on Resend, start with a more important premise: email is a delivery channel, not a secure data vault. A provider setting that reduces message-content retention is useful, but it cannot make a secret safe once it has been put in an email, copied to logs, forwarded, delivered to a mailbox, or included in a tracking URL.

This guide is written for developers using Resend or another transactional email service through a REST API or SMTP relay. The practical goal is to minimize the amount of personal, regulated, authentication, and business-sensitive information that reaches your email provider in the first place—then verify what is retained by the provider, your application, and every connected system.

Start with a realistic definition of “not stored”

“Not stored” can mean several different things, and treating it as one simple checkbox creates gaps. Email providers may separately handle message bodies, HTML, attachments, API request logs, delivery events, suppression lists, inbound mail, backups, abuse systems, and support records. Your own systems can create additional copies in application logs, job queues, observability platforms, data warehouses, error trackers, and webhook consumers.

A safer design asks four questions for each data element:

1. Must this value be in the email at all?
2. If it must be sent, can it be replaced with a short-lived reference or action link?
3. Which systems process it before delivery and after delivery?
4. How long does each system retain it, and who can retrieve it?

For example, a password reset email needs an account identifier, destination address, and a reset mechanism. It does not need the customer’s password, security-answer details, full profile, session cookie, government ID, payment number, or medical data. The reset mechanism should be a single-use, time-limited token that is validated server-side—not a reusable credential.

The distinction matters because an email provider can reduce its retention of message content while still necessarily processing sender and recipient addresses, timestamps, delivery outcomes, and other operational metadata. Delivery infrastructure needs enough information to route, authenticate, retry, suppress bounces, investigate abuse, and report outcomes. Design for data minimization rather than assuming metadata can disappear entirely.

Know what Resend and your provider may retain

Resend documents an option to turn off message-content storage for qualifying customers with additional compliance needs. Its documentation currently states that eligibility includes being on a Pro or Scale subscription for at least one month and sending from a domain with an active website. Confirm the current requirements, scope, and onboarding process with the provider before treating the setting as a compliance control. (resend.com)

That setting should be evaluated as one layer of your program, not the entire program. In particular, distinguish message-content storage from request logging. Resend’s API log documentation shows that logs can include request and response bodies; an example request body contains fields such as from, to, and subject. That means your security review should cover API logs as well as the message preview or sent-email view. (resend.com)

Resend’s sent-email documentation also describes viewing message metadata and preview, plain-text, and HTML versions in its email-management experience. If you are requesting reduced content storage, test the precise behavior with a non-production message: send a unique marker in subject and body, inspect every available message view and log surface, and document what remains visible. (resend.com)

The vendor-neutral lesson is straightforward: ask every provider for written answers to these questions.

• Does the provider store HTML, plain text, raw MIME, headers, attachments, or only selected metadata?
• Are API request and response bodies logged? Can fields be redacted or logging reduced?
• What is retained for delivery events, bounces, complaints, suppressions, and abuse prevention?
• Do support personnel, administrators, or API tokens have access to retained data?
• What are the normal retention periods, backup retention periods, deletion timelines, and exceptions?
• Does a configuration change affect past messages, future messages, or both?
• How are inbound messages and inbound attachments treated differently from outbound transactional messages?

Put the answer in your data inventory. “The provider says they do not store email bodies” is not sufficient documentation unless you can identify the exact feature, plan terms, date enabled, technical scope, and exclusions.

Classify data before you create an email template

The best way to keep sensitive data out of a provider is to prevent it from entering templates and send payloads. Create a lightweight classification system that developers can apply during code review.

Usually acceptable when necessary

Some information is operationally necessary for ordinary transactional email. Even then, use the minimum value required for clarity:

• Recipient email address
• First name or display name, where appropriate
• Order number or support ticket reference
• Product name and high-level status
• Date, time, or broad service location
• A server-generated action link

An order reference is normally safer than a full receipt listing address, telephone number, every item, and payment details. A ticket ID is safer than embedding a customer’s complete support history.

Handle with heightened care

These values may be personal data or commercially sensitive, and often do not belong in the subject line or URL:

• Full postal addresses and phone numbers
• Dates of birth
• Account balances and detailed invoices
• Employment, educational, or legal records
• Precise location data
• Internal project names, incident details, or customer lists
• Authentication factors and recovery codes

Never send in ordinary email

Avoid placing the following in transactional messages, including HTML comments, hidden preheader text, attached CSV files, and query strings:

• Passwords, passwords in temporary form, or password hashes
• API keys, SMTP credentials, private keys, bearer tokens, session cookies, or OAuth refresh tokens
• Full payment-card numbers, CVV values, bank-account numbers, or unredacted identity documents
• Protected health information unless your legal, contractual, and technical controls explicitly support that workflow
• Encryption keys or recovery secrets that can independently unlock protected data

Do not rely on base64 encoding, URL encoding, client-side encryption, or “hidden” HTML to change this classification. Encoding is not protection. If the recipient must access sensitive material, send a notification that directs them to an authenticated application session.

Replace secrets with secure, short-lived actions

A transactional email should commonly tell the user that an action is available, not contain the sensitive result of that action. This pattern reduces exposure across mail providers, recipient mailboxes, forwarded messages, screenshots, backups, and endpoint security tools.

Use opaque, one-time tokens

For password resets, email verification, account recovery, statement access, or consent confirmation, generate a cryptographically random opaque token. Store only a hash of that token in your database, associate it with a purpose and user, and set a short expiration.

A reset URL can look like this:

https://app.example.com/reset-password?t=JQd7hZ1KQfZg0Yv... 

The token itself is still sensitive because anyone who receives it may be able to use it. Reduce its risk with these controls:

1. Generate at least 128 bits of entropy using a cryptographically secure random generator.
2. Store SHA-256(token) or a stronger password-hashing approach rather than the raw token.
3. Bind the token to exactly one purpose, such as password_reset.
4. Set a short expiration, commonly 10 to 30 minutes for a password reset.
5. Mark it consumed in the same transaction that changes the password.
6. Invalidate earlier reset tokens when issuing a new one, where that matches your security model.
7. Never place the user’s email address, password, session ID, or other private claims beside the token in the URL.

For particularly sensitive operations, email should only begin the workflow. After the link is opened, require a fresh application login, a second factor, or another step-up check before revealing data or changing an account.

Keep secrets out of URLs where possible

URLs spread widely. They may be preserved in browser history, reverse-proxy logs, analytics tools, referrer headers, link-scanning systems, copied messages, and support tickets. If a token must be sent by email, place it in the fragment portion only if your application architecture can securely exchange it after client-side handling; fragments are not sent in the initial HTTP request, but they can still be exposed to browser extensions, screenshots, and client-side telemetry.

A more conventional approach is to use a short-lived token in the query string, ensure the destination page immediately exchanges it for a server-side session, and avoid loading third-party scripts on that page. Send a strict Referrer-Policy: no-referrer header and avoid redirecting users to unrelated domains before the token is consumed.

Never use predictable identifiers as authorization. A URL such as https://app.example.com/invoice/104932 might be convenient, but it is not a secure access control boundary. Require authentication and authorization on every request, even if the user arrived via an email link.

Design safer subjects, bodies, attachments, and headers

Sensitive information is often exposed through a field developers consider harmless. A provider can disable body storage while the subject line, recipient address, or custom header still appears in operational logs and dashboards.

Subject lines are unusually exposed

Subjects appear in mailbox lists, push notifications, lock-screen previews, desktop alerts, archive searches, and often mail-provider indexing. Keep them generic.

Prefer:

Your account needs attention
Your document is ready
Action required: confirm your email
Update on your support request

Avoid:

Your HIV test result is ready
Your payroll adjustment: $14,500
Reset code for Jane Doe's administrator account
Your case #1234 involving [confidential matter]

The body can provide a little more context, but sensitive details should still reside behind a secure authenticated experience. Include a neutral fallback for users who cannot use the button: for example, “Sign in to your account and open Notifications.”

Treat attachments as high-risk copies

Attachments are durable copies that may be stored by the sender, provider, recipient mailbox, recipient device, endpoint backup, and any forwarding destination. They can also trigger malware scanning and content analysis. For sensitive exports, statements, legal files, or reports, send a notice plus a time-limited authenticated download page instead.

If an attachment is unavoidable, define a policy for encryption, password delivery through a separate channel, access expiration, recipient verification, and revocation. Do not email both an encrypted file and the password in the same message. Also remember that encrypted attachments can impair recipient usability and malware-scanning workflows, so they are not a universal replacement for an authenticated portal.

Avoid unnecessary custom headers and tags

Many APIs and SMTP libraries permit custom headers, tags, metadata, or idempotency keys. These are useful for routing and correlation, but they may be visible in logs, webhooks, raw messages, and debugging tools.

Use a random internal event ID such as evt_01J..., not a customer’s name, diagnosis, invoice amount, or account number. Do not put personal data into headers such as X-Customer-Name, X-Case-Details, or X-Internal-Note. Use a database lookup keyed by a non-sensitive identifier when context is needed.

Reduce leakage through API, SMTP, queues, and logs

A REST email API and an SMTP relay both transmit the email content to the sending provider. The main difference is where your integration may accidentally record it.

REST API integrations

A typical email API request includes JSON fields such as recipient addresses, subject, HTML, plain text, reply-to address, headers, tags, and attachment data. Avoid generic HTTP logging middleware that records entire request bodies for every outbound call. That middleware may copy the email to application logs before it reaches your provider.

Use structured logging with an explicit allowlist. A safe send log might record:

{
  "event":"transactional_email_accepted",
  "provider_message_id":"msg_abc123",
  "template":"password-reset",
  "recipient_domain":"example.net",
  "status":202
}

It should not record the full recipient address, subject, HTML, token, link, attachment content, Authorization header, or complete provider response. Depending on your operational needs, even the local part of the email address may be unnecessary; log a keyed hash or an internal user ID instead.

A successful HTTP response commonly falls in the 2xx range. 200 OK, 201 Created, or 202 Accepted can indicate that the provider accepted the request, but acceptance is not the same as inbox delivery. Treat a 4xx response as a client-side, authentication, validation, or rate-related problem to investigate, and a 5xx response as a provider or transient infrastructure failure that may warrant a controlled retry. Make retries idempotent so a timeout does not result in duplicate account emails.

SMTP integrations

SMTP clients may log full protocol transcripts. Those transcripts can include MAIL FROM, RCPT TO, message headers, body lines after DATA, and authentication negotiation. Configure your SMTP library’s debug mode off in production, and ensure error reporting does not capture message objects.

SMTP reply classes communicate broad outcomes. A 250 response commonly indicates the server accepted a command or message; 451 is a transient local processing failure; and 550 commonly represents a permanent failure such as a nonexistent recipient or rejected mailbox. The SMTP specification defines the three-digit reply-code structure and explains that a 550 response may be used when a recipient is known not to be deliverable. (datatracker.ietf.org)

Do not paste raw SMTP errors into customer-visible interfaces or analytics events without redaction. Server responses can contain recipient addresses, policy information, internal routing hints, or vendor-specific diagnostic text.

Queues, dead-letter queues, and tracing

Email jobs frequently pass through Redis, SQS, RabbitMQ, Kafka, or a database-backed queue. If the job payload contains the rendered HTML, attached documents, or a reset link, your queue becomes another sensitive-data store. Prefer a queue payload containing only a template name, internal recipient ID, event ID, and an encrypted or server-resolved reference to the data needed at send time.

Review dead-letter queues especially carefully. They are designed to retain failures for debugging, which makes them a common location for old payloads. Set expiration policies, restrict access, encrypt data at rest, and build a redacted replay path instead of manually copying production messages into tickets.

Distributed tracing can create the same issue. Never add email bodies, recipient addresses, Authorization tokens, or reset URLs as span attributes. Configure observability tools to scrub sensitive keys before export.

Secure webhooks and control the data you store yourself

Delivery webhooks are valuable, but they are another stream of potentially personal operational data. They may include an email identifier, recipient or sender information, timestamps, event type, and delivery status. Store only what you need for business operations and legal obligations.

Resend documents webhook delivery as HTTPS JSON payloads and supports replaying webhook events. Its documentation also notes that webhook endpoints can fail, be retried, and eventually be disabled if failures continue. Build an idempotent receiver because a retry or replay must not create duplicate records or duplicate downstream actions. (resend.com)

A secure webhook handler should:

• Verify the provider’s webhook signature before parsing or acting on the event.
• Require HTTPS and reject plaintext transport.
• Return a fast 2xx response after durable, minimal processing; offload long work to a queue.
• Use the event ID for idempotency.
• Allowlist event types instead of accepting arbitrary payload shapes.
• Store a minimal event record, such as event ID, message ID, type, timestamp, and normalized outcome.
• Apply a retention period to webhook data and delete it automatically.
• Restrict the endpoint from exposing event contents in error pages or generic request logs.

Resend’s inbound-email documentation is particularly relevant to data minimization: inbound webhooks do not include email bodies, headers, or attachments, and retrieval of those items requires separate API calls. That separation can help you avoid accidentally storing an entire inbound message in every webhook consumer—but only if your application does not retrieve content unnecessarily. (resend.com)

Do not retain raw event JSON “just in case” forever. Normalize the handful of facts you need, such as delivered, bounced, complained, or suppressed, then expire raw payloads quickly. If a support workflow needs message details, grant short-lived, audited access through a controlled tool rather than exporting events into broadly accessible analytics platforms.

Authenticate your domain without exposing private data

SPF, DKIM, and DMARC improve domain authentication and reduce spoofing risk. They do not encrypt email content or prevent provider storage, but they are still important because spoofed email can trick users into revealing sensitive data.

SPF syntax

An SPF record is published as a TXT record at the sending domain. A simple example is:

example.com. IN TXT "v=spf1 include:spf.email-provider.example -all"

Replace the include: domain with the exact value your provider supplies. Do not invent or combine includes from blog posts. SPF has DNS lookup limits and multiple SPF TXT records can cause evaluation problems, so consolidate carefully when you use more than one sender.

DKIM syntax

A DKIM record is also a TXT record, usually at a selector-specific hostname. A generic example is:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Many providers use CNAME-based DKIM delegation instead, for example:

s1._domainkey.example.com. IN CNAME s1.domainkey.provider.example.

Use the exact record type, hostname, and target supplied by the provider. The selector is not a universal constant. Never publish a private DKIM key in DNS; DNS contains the public key or a delegation record only.

DMARC syntax

DMARC is published at _dmarc as a TXT record. A conservative monitoring record is:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

After reviewing reports and confirming legitimate senders authenticate and align correctly, a stricter policy might be:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

DMARC records use tag-value syntax at _dmarc, and the current standards track includes RFC 9989. (rfc-editor.org) Avoid sending aggregate reports to a mailbox that is loosely managed or automatically forwarded, because those reports can disclose sending infrastructure and recipient-domain statistics.

Use tools such as MXToolbox to inspect published DNS records and mail-tester.com to test a non-sensitive sample message for authentication and deliverability signals. Test with a disposable or dedicated test address; do not submit production emails containing customer data to third-party diagnostic tools.

Test retention and access instead of trusting assumptions

A retention setting is only meaningful if you validate it end to end. Build a repeatable test procedure and rerun it after provider changes, new integrations, or changes to observability tooling.

A practical verification test

1. Create a non-production recipient mailbox and a unique harmless marker, such as RETENTION-CHECK-2026-08-13-7F3A.
2. Send a plain-text and HTML test message through your normal production-like API or SMTP path.
3. Include the marker in the subject, body, a custom header, and a provider tag only if you need to test each data surface separately.
4. Inspect the provider’s sent-message views, API logs, activity logs, webhook events, support exports, and any configured archiving functions.
5. Search your application logs, queue payloads, dead-letter queue, trace platform, error tracker, SIEM, data warehouse, and backup inventory for the marker.
6. Verify who can access each location using an administrator account and a least-privilege account.
7. Repeat after the documented retention period and after deletion requests or lifecycle jobs run.
8. Save the evidence, the date, the accounts used, and the result in your security-control documentation.

Use harmless test data. Never plant a real password, API key, health record, or customer identifier simply to prove a retention control works.

Access control is part of storage control. If every engineer, contractor, or support agent can open message content or API request logs, then the effective exposure is broad even when retention is short. Apply role-based access, single sign-on where available, multi-factor authentication, audit logs, and separate production from test environments.

Build an email data-retention policy that engineering can enforce

Written policies fail when they do not translate into code and configuration. Your policy should name data types, locations, owners, retention targets, deletion mechanism, legal basis, and exceptions.

A useful starting matrix might look like this:

Exact retention periods depend on your regulatory obligations, contracts, fraud needs, support model, and incident-response plan. The key principle is defensibility: retain data because you have a documented need, not because deleting it is inconvenient.

When evaluating plans and operational limits for a sending service, compare the actual sending requirements with the available controls rather than assuming every tier offers the same governance features. Review transactional email pricing alongside the provider’s data-processing and security documentation before making a production commitment.

Common mistakes that defeat content-storage controls

Teams frequently enable a retention-related setting and then leak the same data elsewhere. Watch for these patterns.

Sending secrets in the “temporary” email

A temporary password, one-time code, or recovery code may still be copied, forwarded, indexed, and retained. Prefer an expiring action link and step-up verification. If a one-time passcode is required, keep it short-lived, rate-limited, purpose-bound, and never combine it with other authentication factors in the same message.

Logging the full API payload on errors

An engineer adds HTTP request logging to diagnose 400, 401, 429, or 500 responses. Months later, the logging service contains every recipient, subject, reset token, and HTML message. Use field-level redaction and logging allowlists from the start.

Treating delivery events as non-sensitive

A delivery event may reveal that a particular person received a message about a service, event, account, or condition. Event data can be personal data even when it lacks the message body. Store less, restrict access, and expire it.

Using analytics links on account-security emails

Third-party click tracking can create more data flows and may expose action URLs to additional systems. For password resets, verification, and high-sensitivity notifications, consider disabling unnecessary tracking and keeping destination pages free of third-party analytics.

Assuming TLS makes email confidential end to end

SMTP TLS protects transport between participating servers, but it does not prevent the sending provider, recipient provider, mailbox owner, administrators, backups, or forwarding destinations from accessing the message. Transport encryption is necessary, but it does not make email a private document repository.

Conclusion: minimize first, then verify every copy

To ensure sensitive data isn’t stored on Resend—or any transactional email provider—do not begin and end with a provider-side retention request. First remove secrets and unnecessary personal data from the email. Use short-lived, single-purpose actions that lead to an authenticated application. Then audit message storage, API logs, SMTP debugging, queues, webhooks, tracing, support tooling, and recipient-facing exposure.

A strong implementation treats the provider as one processor in a larger data path. The safest transactional email is short, generic, authenticated at the domain level, minimally logged, and backed by a retention policy you can test. For implementation patterns around REST sending, SMTP relay configuration, and domain authentication, consult the email API reference and setup guides.

FAQ

Can Resend completely avoid storing every piece of email data?

Do not assume so. Providers may need operational metadata for routing, delivery, suppression, abuse prevention, billing, and support. Ask for the exact scope of reduced-content storage, what remains retained, who can access it, and how long it is kept.

Does turning off message-content storage protect email already delivered to recipients?

No. It can reduce storage at the sending provider, but it does not delete copies in recipient mailboxes, forwarded mail, device backups, endpoint archives, screenshots, or downstream security systems. Do not put long-lived secrets in email.

Should I send a temporary password by email?

Usually no. Send a one-time, expiring password-reset link instead. Require the user to set a password after arriving at your authenticated application, and invalidate the token immediately after use.

Are webhook payloads safe to keep forever because they do not contain the full email body?

No. Delivery events can still contain personal or operationally sensitive metadata. Store only the fields you need, validate webhook signatures, make processing idempotent, restrict access, and enforce a deletion schedule.

Do SPF, DKIM, and DMARC prevent sensitive-data storage?

No. They authenticate sending domains and help reduce spoofing and phishing. They are essential email-security controls, but they do not encrypt messages, remove provider logs, or prevent recipient mailbox storage.