GDPR for email sending is the set of data-protection obligations that applies when an organization collects or uses an EU or EEA resident’s personal data for email. It requires a valid legal basis, clear information, respect for recipient rights, appropriate security, and accountable handling of data by both the sender and its email providers.

What GDPR means in email sending

GDPR is shorthand for the General Data Protection Regulation, the EU data-protection law formally known as Regulation (EU) 2016/679. In email operations, it matters because an email address is often personal data, and the surrounding information can be even more sensitive from a compliance perspective: a recipient’s name, IP address, message activity, purchase history, location, support history, and segmentation attributes may all be personal data.

The law is not limited to companies incorporated in the EU. It can also apply to organizations outside the EU or EEA when their processing relates to offering goods or services to people in the Union, or monitoring their behavior there. A U.S.-based SaaS company that markets to, signs up, and tracks engagement from EU users may therefore have GDPR responsibilities even if its infrastructure and employees are elsewhere.

For an email sender, GDPR is not one checkbox beside a signup form. It is an operating model. The model covers how an address enters a list, why each message is sent, which vendors receive the data, how a recipient opts out, when records are deleted, and how the organization can demonstrate that these choices were made responsibly.

It is also important to distinguish GDPR from email-specific marketing rules. GDPR governs personal-data processing more broadly. In many European jurisdictions, separate ePrivacy rules and local implementing laws add requirements for marketing email, particularly around consent. In the UK, the UK GDPR and Privacy and Electronic Communications Regulations (PECR) form a similar layered framework. A lawful basis under GDPR does not automatically mean every promotional email is permitted under the electronic-marketing rules that apply to a recipient.

Why GDPR matters for deliverability and campaign performance

GDPR is a legal and privacy framework, not an inbox-placement score. There is no universal “GDPR rate” that mailbox providers calculate. Yet sound GDPR practices directly improve the inputs that determine email performance: list quality, recipient expectations, engagement, complaints, and the reliability of suppression handling.

A sender that collects addresses with clear expectations is more likely to reach people who recognize the brand and want the messages. Those people are more likely to read, click, reply, or purchase, and less likely to mark messages as spam. By contrast, a list obtained through vague consent language, an unvetted lead source, or an old database can create a mismatch between what the sender believes it may do and what recipients believe they signed up for.

That mismatch is expensive. It can produce lower engagement, more unsubscribes, elevated spam complaints, more support requests, and poor reputation signals. When these signals rise, mailbox providers may place future email in spam, throttle delivery, or reject messages. The underlying issue may begin as a privacy problem, but it often becomes a deliverability problem as well.

Permission quality is a deliverability asset

Permission is not merely a record showing that a form was submitted. High-quality permission means the recipient understood who would email them, what category of messages they would receive, and how often or for what purpose. It also means the sender can connect that permission to the exact address being mailed.

For example, a person who creates an account to receive a password-reset message has a clear relationship with the product. That does not necessarily mean they agreed to a weekly promotional newsletter. A sender should avoid treating one type of interaction as a blank check for every future email category.

The practical deliverability benefit is simple: recipients who expected a security notification tolerate it; recipients who expected a product newsletter may welcome it; recipients who expected neither are much more likely to complain. GDPR encourages the data discipline that prevents these expectation gaps.

Better governance reduces operational mistakes

Many sender reputation incidents are not caused by malicious behavior. They come from ordinary operational failures: a CSV export is reused after a person unsubscribed, an acquisition team imports third-party leads, an automated journey ignores a global suppression list, or a former customer continues receiving marketing after objecting.

A GDPR-oriented process forces teams to map these flows. It asks where the data came from, what legal basis applies, who can access it, whether the purpose changed, and what happens when a person exercises a right. That mapping makes it easier to identify broken data pipelines before they become a campaign-wide spam complaint event.

Strong privacy practices support sustainable growth

Email programs often optimize short-term volume: add more contacts, send more reminders, or retarget more aggressively. But long-term inbox placement depends on trust. Sending only to recipients with a defensible relationship to the brand may reduce a list’s raw size while improving its economic value.

A smaller, engaged audience can outperform a larger, poorly sourced audience. It can generate more opens, clicks, conversions, replies, and revenue per delivered message while producing fewer complaints and fewer reputation problems. GDPR does not promise those outcomes, but the operational habits it requires align closely with them.

The personal data in an email program

A useful GDPR assessment starts by recognizing that email data is more than an address field. An email platform can process personal data at collection, storage, message generation, delivery, tracking, suppression, reporting, and support stages.

Typical email-related personal data includes:

Email addresses, names, phone numbers, job titles, and company affiliations when they identify or can be linked to a person.
Signup source, consent timestamp, form version, referral URL, and IP address.
Customer or subscriber IDs, account status, order history, subscription tier, and lifecycle stage.
Event data such as delivery, opens, clicks, bounces, replies, unsubscribes, and spam complaints.
Segmentation fields such as language, city, product usage, interests, or predicted purchase likelihood.
Email content that contains account information, support details, invoices, health data, financial details, or other sensitive information.
Suppression records showing that a person opted out, objected to marketing, or should not be contacted through a particular channel.

Some fields require extra care. Special-category data, such as information concerning health, racial or ethnic origin, political opinions, religious beliefs, or sexual orientation, has heightened protections under GDPR. An email campaign may process such data even if the sender did not explicitly create a field for it. For example, a clinic newsletter, a political fundraising list, or a support email containing medical details can reveal sensitive information through the sender, subject line, recipient segment, or message body.

Data minimization is therefore especially useful in email architecture. Store and transmit only what the system needs to send, personalize, troubleshoot, and comply. If a message can be addressed with an internal user ID and a template variable containing a first name, do not attach an unnecessary full customer export to every downstream workflow.

Lawful bases: the reason you may process email data

Every GDPR processing activity needs a lawful basis. For email senders, the most commonly discussed lawful bases are consent, performance of a contract, legitimate interests, legal obligation, and, more rarely, vital interests or public task. The correct basis depends on the purpose and the facts, not on whichever option seems most convenient.

Consent for newsletters and promotional email

Consent is often central to promotional email, particularly where ePrivacy rules also require prior consent. GDPR consent must be freely given, specific, informed, and unambiguous. It must be expressed through a clear affirmative action; pre-ticked boxes, silence, or inactivity do not create valid consent.

In practice, a newsletter form should make it clear who is collecting the address and what the person is agreeing to receive. A useful statement might identify the sender, describe the type of content, and link to the privacy notice. If a sender wants consent for separate purposes, such as a product newsletter and partner offers, those choices should not be bundled into one unclear agreement.

Double opt-in is not universally required by GDPR, but it is often valuable evidence of intent and a strong deliverability safeguard. It helps establish that the person controlling the inbox completed the subscription step, reduces typo-based subscriptions, and limits abuse where someone enters another person’s address. The confirmation email itself should be narrowly focused on confirming the request rather than being used as a promotional campaign.

Contractual necessity for service messages

Some email is necessary to provide a service a person requested. Password resets, verification messages, purchase receipts, booking confirmations, security alerts, billing notices, and account-access notifications may be processed because they are necessary to perform a contract or take steps at the person’s request before entering into a contract.

The phrase “necessary” matters. A sender should ask whether the specific processing is objectively required to deliver the service. A product announcement that happens to be useful is not automatically necessary for contract performance. Keep transactional email genuinely transactional where possible, especially when the recipient has opted out of marketing.

Legitimate interests and direct marketing

GDPR recognizes that direct marketing may, in some circumstances, be a legitimate interest. That is not a universal permission slip. A sender relying on legitimate interests should perform and document an assessment: identify the legitimate interest, show why the processing is necessary for it, and balance that interest against the individual’s rights and reasonable expectations.

For email marketing, electronic-communications rules may still require consent even if legitimate interests could support an aspect of GDPR processing. This is why teams should not make a sending decision using a GDPR lawful-basis field alone. They need a jurisdiction-aware marketing-permission policy.

Most importantly, people have an explicit right to object to processing for direct marketing. Once someone objects, the organization must stop processing their personal data for that direct-marketing purpose. An unsubscribe mechanism is therefore not just a user-experience feature; it is a core part of respecting the right to object.

Consent records and proof of permission

GDPR uses an accountability principle: it is not enough to act compliantly; an organization must be able to demonstrate compliance. For email, that means keeping usable evidence of how and when a marketing recipient was added, what they were told, and what choices they made.

A practical consent record should usually contain enough information to answer basic questions without reconstructing the event from scattered logs. Useful fields include:

The email address or a stable internal identifier linked to it.
The date and time of the action, stored in a consistent time zone such as UTC.
The collection method, such as a signup form, checkout, account settings page, event registration, or import from a documented source.
The consent language or form version shown at the time.
The specific email purpose or subscription category selected.
Evidence of the affirmative action, such as a checkbox submission or double-opt-in confirmation.
The source page, campaign, or integration where appropriate.
Any subsequent changes, including unsubscribes, objections, preference updates, and resubscriptions.

Do not confuse consent records with a broad activity log. The goal is not to retain every technical event forever. The goal is to preserve enough evidence to explain the permission state accurately. Records should be protected, access-controlled, and retained according to a documented retention policy.

A practical permission-state model

An email address may have different permissions for different purposes. A single boolean field named subscribed is often too crude. A more durable system models the relationship between a recipient, a purpose, a legal basis, and a current status.

For example, an internal record might distinguish product_updates, weekly_newsletter, event_invites, and transactional_account_email. It might record opted_in, unsubscribed, objected, pending_confirmation, or suppressed for each applicable category. A person can remain eligible for a receipt while being ineligible for marketing.

The following illustrative JSON structure is not a legal template, but it shows the kind of information an email system may need to preserve:

{
  "contact_id": "usr_8a21",
  "email": "alex@example.com",
  "subscriptions": {
    "weekly_newsletter": {
      "status": "opted_in",
      "lawful_basis": "consent",
      "collected_at": "2026-08-14T16:42:09Z",
      "collection_method": "website_form",
      "form_version": "newsletter-v4",
      "confirmed_at": "2026-08-14T16:46:18Z"
    },
    "product_marketing": {
      "status": "unsubscribed",
      "updated_at": "2026-09-02T09:11:44Z",
      "source": "email_unsubscribe_link"
    }
  }
}

The exact database design can vary. What matters is that campaign selection reads the current permission state before sending and that an unsubscribe or objection updates every relevant sending path promptly.

Transparency, notices, and recipient rights

People should not have to guess what happens to their data after sharing an email address. GDPR transparency obligations generally require organizations to provide concise, intelligible, accessible information using clear language. In an email context, that usually means a privacy notice at the point of collection and email content that accurately identifies the sender and supports recipient choice.

A privacy notice should be tailored to the actual processing. It should explain the categories of data, purposes, lawful bases, recipients or categories of recipients, retention approach, international transfers where relevant, and the rights available to individuals. A generic privacy statement that does not mention marketing, tracking, or email-service providers can create an avoidable gap between operations and disclosure.

Key rights that affect email operations

Recipients may have rights to access personal data, correct inaccurate data, request erasure in certain circumstances, restrict processing, object to certain processing, and receive portable data in applicable cases. The exact scope of each right depends on the request and legal context, but a sender should design systems that can locate and act on a recipient’s information without improvising.

For direct marketing, the right to object deserves special attention. The option to object should be brought to the recipient’s attention clearly and separately from other information. In ordinary email practice, a visible unsubscribe link is the common mechanism, but the backend matters more than the link itself. If a person unsubscribes, every future marketing campaign, automation, CRM export, and manually uploaded segment needs to respect that choice.

Erasure is not always the same as immediate deletion from every system. A sender may need to retain a minimal suppression record to ensure the person is not added back to marketing lists by mistake. The organization should document why the limited record is retained, restrict its use to suppression or compliance, and avoid continuing broad marketing profiling under the guise of maintaining an opt-out list.

Preference centers are useful but not a substitute for an opt-out

A preference center can help recipients choose topics and frequency, which may reduce unsubscribes and complaints. It is valuable when it makes choices clear and easy. But it should not make total opt-out difficult, ambiguous, or hidden behind unnecessary login steps.

Good preference-center design separates choices cleanly. It can offer a one-click unsubscribe from a category, a global marketing opt-out, and optional frequency or content controls. It should also identify any genuinely essential service messages that cannot be disabled because they are necessary for the account or transaction.

GDPR and email tracking data

Open tracking, click tracking, and behavioral segmentation can improve measurement, but they are data-processing activities. An open event may be associated with a recipient address, device characteristics, IP-derived location, time of interaction, and campaign identifier. A clicked link can reveal interests, usage patterns, or a person’s relationship with a product.

This does not mean all measurement is prohibited. It means senders should decide deliberately what they collect and why. They should assess the lawful basis, explain the processing in their privacy information, configure vendors appropriately, control access, and avoid collecting more granular tracking data than the campaign needs.

Open rates are less reliable than they look

Email opens are already an imperfect performance metric. Image caching, privacy features, plain-text readers, blocked images, automated security scanners, and prefetching can all create false positives or false negatives. Treating an open as precise evidence of a person’s behavior can therefore be technically unsound as well as privacy-sensitive.

For deliverability decisions, aggregate signals such as deliveries, bounces, complaints, unsubscribes, clicks, conversions, replies, and active-user events may provide a more reliable picture than individual open events alone. Where possible, use aggregated analysis and shorter retention periods for granular event data.

Avoid excessive profiling

Segmentation can be helpful when it serves a clear recipient benefit, such as sending content in the recipient’s selected language or suppressing irrelevant product promotions. It becomes riskier when the sender creates detailed behavioral profiles, combines data from unrelated sources, or makes impactful automated decisions without appropriate safeguards.

A practical question is: would a reasonable recipient understand and expect this use? If the answer is no, reconsider the collection, explain it more clearly, seek an appropriate permission where needed, or redesign the campaign to use less intrusive data.

Processors, email APIs, and data-sharing responsibilities

Most organizations do not send email entirely on their own infrastructure. They use an email API, SMTP relay, analytics provider, CRM, customer-data platform, form tool, support platform, or cloud host. GDPR requires the sender to understand the role each vendor plays and to put appropriate contractual and technical safeguards in place.

In many common arrangements, the business deciding why and how customer email data is used is the controller, while an email delivery platform processes that data on the business’s documented instructions as a processor. However, roles are determined by the facts, not simply by labels in a contract. A vendor may act as an independent controller for some narrowly defined activities, such as its own account administration or legal obligations.

A controller using a processor needs a data-processing agreement containing the required GDPR terms. The agreement should address the subject matter and duration of processing, nature and purpose, categories of data and individuals, instructions, confidentiality, security, subprocessor management, assistance with rights requests, breach support, deletion or return of data, and audit-related obligations.

Before integrating a sending provider, teams should review where data is stored and processed, whether subprocessors are used, how event data is retained, what export and deletion capabilities exist, and how access is secured. Email infrastructure design is part of privacy design.

When implementing consent fields, suppression synchronization, and event handling in an application, consult the platform’s email API reference and setup guides alongside your privacy and security requirements. Technical implementation should make the compliant action the default action: recipient selection should check eligibility, unsubscribe events should update source-of-truth records, and sensitive message data should not be copied into logs without a clear need.

International transfers and vendor locations

Email is inherently distributed. A message may pass through sending infrastructure, DNS services, anti-abuse systems, inbox providers, analytics tools, customer-support systems, and cloud-hosted databases. If personal data is transferred outside the EU or EEA, GDPR’s international-transfer rules may apply.

The correct transfer mechanism depends on the destination and the facts. Potential approaches include an adequacy decision, appropriate safeguards such as standard contractual clauses, and limited derogations for particular situations. Organizations should not assume that a vendor’s headquarters location alone answers the question; they should understand where processing occurs, which entities receive data, and which safeguards are documented.

Transfer compliance is not solved by a checkbox in procurement. The sending organization should maintain vendor records, review data-processing terms, evaluate transfer documentation, and reassess its setup when it adds a new analytics, enrichment, support, or automation tool. This is particularly important because email data often flows into more systems than teams initially realize.

Security, retention, and breach preparedness

GDPR requires appropriate technical and organizational measures to secure personal data. For email programs, the right controls depend on risk, but common measures include role-based access, multifactor authentication, encryption in transit, secure credential storage, least-privilege API keys, audit logs, environment separation, and documented incident-response procedures.

An email platform account can be a high-impact target. An attacker who gains access may export recipient lists, send phishing messages from a trusted domain, inspect message content, alter webhooks, or create new API credentials. The damage can include privacy harm, brand harm, mailbox-provider reputation damage, and downstream fraud.

Retention should be purposeful

The principle of storage limitation means personal data should not be retained indefinitely just because storage is cheap. Define retention periods for contacts, consent evidence, raw delivery events, tracking events, bounced addresses, account records, backups, and suppression data.

Different data can justify different retention periods. A raw open event may become less useful quickly. A minimal unsubscribe suppression record may need to remain longer to prevent accidental resubscription through an import. A consent record may need to be retained long enough to demonstrate the basis for past or continuing processing. The policy should explain these distinctions rather than applying a single arbitrary number to every record.

Plan for incidents before they happen

A privacy incident is not limited to a large-scale breach. A misaddressed campaign, exposed CSV, compromised API key, incorrectly public webhook endpoint, or unauthorized employee export may require investigation. Teams should know who triages the event, how access is revoked, how evidence is preserved, how affected systems are identified, and when legal or privacy specialists are involved.

GDPR includes breach-notification obligations in certain circumstances, including a requirement to notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a qualifying personal-data breach. Whether a specific incident triggers notification depends on the risk and facts, so an incident playbook should include an escalation path rather than a blanket assumption that every event is either reportable or harmless.

How to assess GDPR readiness for an email program

Because GDPR is not a percentage or a delivery metric, there is no formula that proves compliance. A useful readiness review is evidence-based: can the sender demonstrate that each email use has a defined purpose, justified legal basis, accurate recipient status, transparent disclosure, secure vendor arrangement, and workable rights process?

A practical audit can proceed in the following order:

Inventory every data flow. List all forms, product events, imports, CRM syncs, webhooks, email APIs, SMTP systems, analytics tools, and exports that process recipient data.
Classify each message type. Separate receipts, authentication, security alerts, account notices, lifecycle messages, newsletters, product promotions, and partner marketing. Do not rely only on an internal label such as “transactional” if the message contains substantial promotion.
Assign a lawful basis and marketing-permission rule. Document why each processing activity is permitted under GDPR and which ePrivacy or local marketing rules apply.
Test the evidence trail. Select a random recipient and confirm that the organization can show source, notice version, consent or other basis, purpose, and current subscription status.
Test suppression end to end. Unsubscribe a test address, then attempt to include it through every campaign builder, automation, CSV import, and CRM sync. The system should block the marketing send reliably.
Review retention and deletion. Confirm that old contacts, stale event logs, and inactive integrations are handled according to policy rather than accumulating by default.
Review vendor contracts and security. Verify processor terms, access controls, user permissions, API key rotation, subprocessor information, and international-transfer documentation.
Exercise rights and incident workflows. Run a table-top exercise for an access request, an objection to marketing, a deletion request, and a suspected account compromise.

This type of audit exposes the gaps that matter in real sending operations. It also produces documentation that is useful to privacy teams, security teams, customer support, and deliverability owners.

A worked operational example: fixing a stale marketing list

Consider a B2B software company with 50,000 addresses in a “product updates” segment. The list has grown over five years through webinars, trial registrations, content downloads, partner events, and CRM imports. The company plans to send an announcement to all 50,000 contacts.

The team should not begin with the campaign editor. It should begin with eligibility.

Suppose the audit finds the following:

22,000 contacts have a current, documented opt-in for product marketing.
8,000 are active customers who need account-related notices but never opted into product promotions.
6,000 came from a partner event, but the documentation does not show consent for this company’s own marketing.
5,000 opted out previously.
4,000 have not engaged or updated their preferences for several years, and the permission evidence is incomplete.
3,000 are hard-bounced, invalid, or clearly obsolete records.
2,000 have an unclear source due to a legacy import.

The campaign’s defensible promotional audience is not automatically 50,000. At minimum, the 5,000 prior opt-outs and 3,000 invalid or hard-bounced records should be excluded. The groups with no marketing permission, incomplete records, or unclear source need separate review under the company’s applicable legal and marketing rules.

If the organization sends only to the 22,000 contacts with current documented marketing opt-in, it reduces nominal reach by 56%. But it likely increases relevance and lowers complaint risk. It can then use other lawful channels or carefully designed re-permission efforts where permitted to resolve the uncertain records rather than treating uncertainty as permission.

The numeric lesson is not a GDPR formula. It is a list-quality calculation. Sending to 50,000 records may look better in a campaign report, but sending to 22,000 people who demonstrably expect the message can be far better for trust, complaint rates, and long-term deliverability.

Common GDPR mistakes in email programs

The most common failures are usually process failures, not obscure legal interpretations. They occur when marketing, product, engineering, and operations use different definitions of a subscriber or do not share a reliable source of truth.

Treating every contact as a marketing contact

An account holder, buyer, support requester, trial user, event attendee, and newsletter subscriber may all have different relationships with the organization. A recipient can be eligible for a password reset but ineligible for promotional email. Combining every address into one generic audience makes accidental over-mailing more likely.

Relying on purchased or poorly documented lists

A list vendor’s assurance that contacts are “GDPR compliant” is not sufficient evidence for the sender. The sender needs to understand what recipients were told, whether consent was valid for the sender’s own messages where consent is required, whether objections were honored, and whether the data is current. Weak provenance is also a major deliverability risk because recipients may not recognize the sender.

Making unsubscribe difficult or incomplete

An unsubscribe link that works only for one campaign tool while another automation continues sending is not an effective suppression process. Nor is a preference page that forces a recipient through multiple confusing steps to stop all marketing. The system needs a clear path from recipient action to a durable, centralized restriction.

Logging too much message content

Delivery logs are useful for troubleshooting, but they can unintentionally collect message bodies, recipient identifiers, tokens, and sensitive template variables. Logging should be deliberate. Redact sensitive data where possible, limit retention, and restrict access to teams that truly need it.

Calling promotional content transactional

A receipt that contains a discreet, relevant product recommendation is not necessarily treated the same way everywhere, but relying on a transactional label to bypass marketing restrictions is risky. The more a message’s primary purpose shifts toward promotion, the more carefully the sender should assess marketing permissions and recipient expectations.

How to improve GDPR compliance and deliverability together

The best fixes are often architectural rather than cosmetic. A new footer or revised privacy policy helps, but it cannot repair a system that repeatedly imports unverified contacts or loses unsubscribes between tools.

Start by creating a single source of truth for marketing eligibility. Every campaign tool and automation should consult this source, or receive near-real-time updates from it. Preserve purpose-level permissions, global opt-outs, complaint suppressions, and hard-bounce suppressions separately so that a marketing re-subscribe does not accidentally override a safety or deliverability suppression.

Next, design collection flows around clear choices. State what the person is signing up for, avoid preselected marketing boxes, capture form versions, and consider double opt-in for higher-confidence subscriptions. Make it easy for people to change preferences or stop marketing entirely.

Then establish operational guardrails:

Require review before importing an external list.
Block sends to addresses with unresolved permission status.
Automatically synchronize unsubscribe, complaint, and bounce events to the CRM and campaign systems.
Limit who can export contacts or create API credentials.
Use separate sending streams or tags for transactional and marketing email.
Review inactive and stale records on a documented schedule.
Train support and marketing teams to recognize objections and rights requests received by reply email or other channels.

Finally, treat privacy, security, and deliverability as one program rather than three separate projects. The teams may have different responsibilities, but they are managing the same recipient relationship. Clear permission improves engagement; secure handling preserves trust; accurate suppression reduces complaints; and good data governance makes every system easier to operate.

Conclusion

GDPR for email sending is about more than avoiding regulatory risk. It is a practical framework for sending email people understand, expect, and can control. It asks senders to know why they have each address, what they are allowed to send, how they can prove it, which vendors process the data, and how they will honor a recipient’s choices.

For deliverability teams, the value is concrete: better list provenance, fewer unwanted messages, more reliable suppressions, stronger engagement, and less reputation damage from surprise campaigns. Start with permission records and subscription architecture, then extend the work to transparency, tracking, vendor governance, security, retention, and incident readiness.

This glossary entry is educational information, not legal advice. GDPR and electronic-marketing requirements can depend on recipient location, message type, business relationship, and national law. For a high-risk campaign, sensitive data, large-scale profiling, or uncertain legal basis, involve qualified privacy counsel before sending.

FAQ

Is GDPR a deliverability metric?

No. GDPR is a data-protection law, not a mailbox-provider metric. However, GDPR-aligned practices such as clear permission, accurate lists, prompt unsubscribes, and careful data governance often improve the engagement and complaint signals that influence deliverability.

Do I need consent for every email under GDPR?

No. Some emails, such as password resets, receipts, security alerts, and necessary account notices, may rely on a lawful basis other than consent. Promotional email requires a more careful assessment because GDPR and applicable electronic-marketing rules can both apply.

Can I keep an unsubscribed email address?

Often, an organization may need to keep a minimal suppression record so it does not accidentally resume marketing to that person. The record should be limited to that purpose, protected, and retained under a documented policy rather than used for continuing marketing.

Does double opt-in make an email program GDPR compliant?

No single mechanism guarantees GDPR compliance. Double opt-in can strengthen evidence that the inbox owner requested a subscription, but senders still need clear notices, an appropriate legal basis, rights handling, secure processing, vendor controls, and accurate suppression management.

Does GDPR apply to a U.S. company sending email?

It can. A company outside the EU or EEA may fall within GDPR’s scope when its processing relates to offering goods or services to people in the Union or monitoring their behavior there. The facts of the activity, not only the company’s location, matter.

GDPR for Email Sending: What It Means for Deliverability