A customer data platform (CDP) is software that collects customer data from multiple systems, connects it to a persistent customer profile, and makes that profile available for segmentation and activation. In email, a CDP helps teams use trustworthy identity, behavior, purchase, and consent data to decide who should receive a message, which message they should receive, and when to stop sending.

What is a customer data platform (CDP)?

A customer data platform is designed to solve a familiar operational problem: customer information is scattered. An email platform may know opens, clicks, bounces, and unsubscribes. A product database may know account status and feature use. A commerce system may know orders and returns. A support system may know unresolved tickets. A CRM may know sales ownership and lifecycle stage.

Without a shared data layer, each system can produce a different and incomplete picture of the same person. One team may see a loyal buyer, another may see an inactive subscriber, and a third may see only an anonymous website visitor. A CDP ingests selected information from those sources, applies rules to connect records that belong to the same person or account, and builds a profile that downstream systems can use.

For email senders, the important word is not simply data. It is usable data. A useful CDP profile can make it possible to exclude a person who already purchased, suppress a person who unsubscribed elsewhere, send onboarding content based on a real product event, or stop promotional email while an account has an open support issue.

A CDP is not automatically an email service provider, an SMTP relay, a CRM, a data warehouse, or a consent-management platform. It can connect to each of those systems, but it serves a different role: it helps organize customer data into profiles and audiences that can be activated in channels such as email, SMS, advertising, support, and onsite personalization.

Why a CDP matters for email deliverability

Deliverability is often described as an infrastructure problem: authenticate mail, configure DNS, maintain a stable sending domain, and monitor bounces and complaints. Those controls matter. But mailbox providers also judge how recipients react to a sender’s messages. If people repeatedly ignore, delete, unsubscribe from, or report messages as spam, better DNS alone will not make an unwanted campaign welcome.

That is where a customer data platform can make a practical difference. A CDP can improve the quality of the decision made before a send is created. It can answer questions that a standalone email list often cannot:

  • Is this address currently eligible for promotional email?
  • Did this person recently sign up, purchase, renew, cancel, or contact support?
  • Have they engaged with this category, or have they gone inactive?
  • Are multiple email addresses connected to one customer profile?
  • Is there a current unsubscribe, suppression, regional consent restriction, or frequency cap?
  • Is this message relevant to the individual’s lifecycle stage?

The result should not be “send more personalized email” by default. The more valuable outcome is often send less, with better reasons. For example, an ecommerce sender can exclude customers who purchased the item featured in a campaign yesterday. A SaaS company can avoid sending a trial-conversion sequence to an account that became paid through a sales-assisted deal. A media publisher can reduce newsletter frequency for subscribers who have not engaged in months instead of repeatedly mailing the full historical list.

Those choices can reduce recipient frustration. Lower frustration can mean fewer spam complaints, fewer unsubscribes caused by irrelevant messages, and more positive engagement over time. None of those outcomes is guaranteed by deploying a CDP; they depend on the data, rules, campaign strategy, and execution. But a CDP can give the sending team the inputs needed to make better choices consistently.

Relevance is a deliverability input

A message can be technically flawless and still perform poorly if the audience did not expect it. Relevance starts with the relationship between a recipient and a message. A password reset is relevant because the person requested it. An order receipt is relevant because a transaction occurred. A product recommendation might be relevant when it reflects a recent browsing or buying signal. A generic promotion sent to everyone who has ever entered an email address is much less likely to be relevant.

A CDP helps teams model those distinctions as data. Instead of treating every contact as one row in a mailing list, it can support conditions such as:

Send the renewal reminder when:
- subscription_status = "active"
- renewal_date is within 30 days
- marketing_email_eligible = true
- account has not renewed
- no renewal reminder was sent in the previous 7 days

That is a simple example, but its impact is meaningful. Each condition removes messages that would otherwise be redundant, mistimed, or sent to someone who should not receive them.

Better targeting protects sender reputation

Mailbox providers do not publish a complete formula for inbox placement. Senders should therefore avoid treating any one metric as a universal score. Still, recipient feedback is clearly important. Google’s sender guidance, for example, tells senders to keep spam rates reported in Postmaster Tools below 0.3%, and its requirements for higher-volume senders emphasize authentication and easy unsubscribe mechanisms.

A CDP does not replace those requirements. It strengthens the content and audience side of the equation. Authentication establishes that mail is legitimately associated with the sender. Consent and profile data help establish that the sender is using that authority responsibly.

How a CDP works in an email program

Most CDP implementations follow a sequence: collect, standardize, resolve identities, enrich profiles, create audiences, and activate those audiences. The details vary by vendor and architecture, but the underlying work is broadly similar.

1. Collect customer data from source systems

The first task is deciding which sources matter. For email, common inputs include:

  • Signup forms and preference centers
  • Website and product events
  • Mobile-app events
  • CRM records
  • Ecommerce orders, refunds, and product catalogs
  • Subscription and billing systems
  • Customer-support platforms
  • Loyalty programs
  • Email engagement and delivery events
  • Consent, opt-out, and suppression systems

The purpose is not to copy every field from every database. More fields do not automatically produce better decisions. A profile crowded with stale, duplicated, or unnecessary attributes can make segmentation harder and create avoidable privacy risk.

Start with the decisions your email program needs to make. If the goal is to improve lifecycle messaging, useful fields may include signup date, account state, product milestones, last meaningful activity, subscription tier, and communication preferences. If the goal is to reduce promotional complaints, recent engagement, send frequency, purchase recency, and unsubscribe status may be more useful than hundreds of demographic fields.

2. Standardize events and attributes

Data from separate systems rarely arrives in the same format. One source may write United States, another US, and another USA. A CRM may store Lifecycle Stage, while the product database stores plan_status. The same event can have several names: order_completed, purchase, or checkout_success.

Standardization gives those inputs consistent meanings. That may involve normalizing dates to UTC, defining a canonical event name, formatting phone numbers consistently, using controlled values for account status, and documenting whether an event represents an attempted action or a completed action.

Email teams benefit because segments become easier to reason about. Consider the difference between these two audience definitions:

People with plan = paid

People with subscription_status = "active"
AND billing_status = "current"
AND account_deleted_at IS NULL
AND marketing_email_eligible = true

The second definition is more explicit. It does not guarantee correctness, but it reduces the chance that a loosely named field sends a campaign to suspended, cancelled, deleted, or ineligible accounts.

3. Resolve identities and build profiles

Identity resolution is the process of determining which records refer to the same customer. A person might first appear anonymously through a browser identifier, later submit an email address, then create an account, then make a purchase with a different email address. A CDP may use deterministic identifiers, matching rules, or both to connect those records.

In email, deterministic matching is generally safer for decisions with material consequences. Examples include a verified account ID, a hashed internal customer ID, or a confirmed email address. Fuzzy matching can be useful for data cleanup, but it should be used carefully. Incorrectly merging two people can produce privacy mistakes, mistaken personalization, and email sent to the wrong individual.

A unified profile normally has a stable internal identifier plus linked identifiers from source systems. It may contain attributes such as language preference, country, account state, first purchase date, or loyalty level, along with a chronological event history.

The profile is not necessarily a claim that there is one perfect truth about a human being. It is a governed operational view built from selected source data and rules. Teams should preserve source lineage: when an attribute changed, where it came from, and whether it is authoritative for a particular decision.

4. Create segments and audiences

A segment is a group of profiles that meet defined conditions. A CDP may update that group on a schedule or in near real time as profile values and events change.

For example, a re-engagement audience could be defined as:

marketing_email_eligible = true
AND email_address_status = "valid"
AND last_campaign_engagement_at is more than 90 days ago
AND last_purchase_at is within the last 365 days
AND spam_complaint_at IS NULL
AND unsubscribe_at IS NULL

The logic deliberately includes exclusions. The goal is not merely to find people to mail. It is to prevent messages from reaching people who are no longer eligible, have already complained, or have shown prolonged disinterest.

5. Activate audiences in the sending system

Activation means sending an audience or selected attributes to another tool. In an email stack, activation may update a contact record, assign a tag, call a workflow, trigger a campaign, or make an API request that produces a message.

The activation layer must be designed carefully. A segment can be correct in the CDP but become wrong in practice if it syncs too slowly, overwrites a more recent unsubscribe, or fails to remove people who leave an audience. Treat audience activation as a data pipeline, not as a one-time export.

When a product or engineering team sends mail through an API, it is useful to keep profile decisions separate from the final send request. The CDP or a related decision service determines eligibility and message context; the sending platform handles message construction, authentication, delivery events, and sending reliability. Review your email API setup and sending guides before coupling campaign decisions to production mail flows.

CDP components that matter most for campaigns

Not every CDP capability has equal value for every email team. For campaign performance and deliverability, five components are especially important.

Identity and profile quality

If a customer appears in three systems under three identifiers, campaigns can become duplicated or contradictory. A profile layer can help ensure a sender does not deliver a welcome series to an existing customer, a win-back offer to someone who bought yesterday, and a renewal reminder to someone whose subscription was cancelled.

Profile quality also means knowing what not to merge. Shared inboxes, family email addresses, aliases, role accounts, and business domains can all complicate identity logic. Do not assume that one email address always maps to exactly one person, or that a single person always has one email address.

Consent and communication preferences

Consent is not just a checkbox captured at signup. It is an operational state that must be available whenever a message is sent. The system needs to represent distinctions that matter to the business and to the recipient: marketing versus transactional communication, email versus SMS, newsletter versus product announcements, and global opt-out versus category-level preferences.

A useful consent record includes more than a yes-or-no field. It should retain the legal or business basis used, timestamp, source, form or interaction that captured it, jurisdiction where relevant, and any later withdrawal. The exact model will depend on applicable law and your organization’s policy, so obtain legal advice for your situation.

From a deliverability perspective, a unified suppression signal is essential. If a recipient opts out through an email footer, changes preferences in an account portal, contacts support, or submits a privacy request, the next campaign audience must respect the most current valid instruction.

Behavioral events

Behavioral data can make automation timely, but only if events are meaningful. Page views alone are not always strong intent signals. Better triggers often correspond to moments in the customer journey: account creation, verification completed, trial started, cart abandoned after a valid session, subscription payment failed, order shipped, feature adopted, or renewal approaching.

Use event properties to keep messages concrete. Instead of sending “You left something behind,” an abandoned-cart message might reference a product category, inventory status, or cart value—provided the message does not expose sensitive information and the recipient has agreed to receive the communication.

Frequency and channel coordination

Frequency fatigue is a common cause of poor campaign performance. It occurs when teams operate independently: lifecycle sends a product tip, promotions sends a sale, the newsletter sends a digest, and support automation sends a survey—all within a short period.

A CDP can provide a shared view of recent contact history and support decision rules such as:

  1. Do not send more than three promotional emails in seven days.
  2. Pause promotional sends while a recipient has an unresolved high-priority support case.
  3. Let transactional and security messages bypass marketing frequency caps.
  4. If two campaigns qualify at the same time, send the one with higher customer value and defer the other.
  5. Suppress campaign mail after a recent unsubscribe, spam complaint, hard bounce, or account deletion event.

Frequency capping is not a substitute for relevance. It is a safeguard against an otherwise uncoordinated system.

Delivery and engagement feedback

A CDP can ingest delivery events from an email provider: delivered, bounced, deferred, opened, clicked, unsubscribed, and marked as spam where that feedback is available. These signals should inform future eligibility, but teams should interpret them carefully.

Open events are increasingly imperfect because privacy features, image loading behavior, and security scanners can create or suppress them. Clicks are often more useful, but automated link checking can also distort them. Strong programs combine engagement signals with first-party behavior such as product use, purchases, logins, and direct preference updates.

A CDP is not a deliverability metric

“Customer data platform” is a technology category, not a rate or score. There is no standard formula for calculating a CDP the way you calculate a bounce rate, conversion rate, or spam complaint rate.

That said, a CDP implementation should be measured. The wrong measurement is “how many fields are in the profile?” The better question is whether data quality and activation are improving decisions and outcomes.

Useful CDP-related measurements for email include:

  • Profile match rate: the proportion of source records successfully linked to a governed profile.
  • Duplicate profile rate: the proportion of profiles that appear to represent the same person or account.
  • Known-consent coverage: the share of emailable profiles with a recorded, usable permission state.
  • Suppression propagation time: how long it takes an unsubscribe or complaint to reach every sending audience.
  • Audience freshness: the delay between a relevant event and the audience update that should follow.
  • Segment precision: the share of recipients who truly meet the intended eligibility criteria.
  • Campaign overlap: the proportion of people targeted by multiple campaigns in the same period.
  • Incremental campaign results: the additional conversions, retention, or engagement produced compared with a suitable control group.

Worked example: measuring suppression propagation

Suppose a retailer sends promotional email from three systems: a campaign tool, a product-notification service, and a legacy CRM workflow. During one week, 2,000 people unsubscribe from promotional mail.

After auditing the systems, the team finds:

  • 1,960 unsubscribes reached all three systems within 15 minutes.
  • 30 reached the campaign tool immediately but took more than 24 hours to reach the legacy workflow.
  • 10 failed to reach at least one system because of an integration error.

The timely suppression propagation rate for the 15-minute service-level objective is:

Timely propagation rate = unsubscribes propagated within 15 minutes / total unsubscribes × 100

= 1,960 / 2,000 × 100
= 98%

A 98% rate may look high, but the remaining 2% represents 40 people whose request was not honored quickly across all promotional systems. If the company continues to send to those people, the operational cost is more than a dashboard blemish: it can generate complaints, undermine trust, and create compliance exposure. The target should be based on the organization’s obligations and architecture, but the example shows why propagation speed matters as much as the raw existence of an unsubscribe field.

Common CDP problems that hurt email performance

A CDP can improve decisions, but poor implementation can also amplify mistakes at scale. The most damaging failures are usually not exotic technical bugs. They are ordinary data-governance failures that become automated.

Stale or conflicting consent records

A common issue is storing consent in multiple systems without a clear authority. The ecommerce platform says subscribed; the support platform says opted out; the campaign tool has an older import with no preference state. If the sending system uses whichever value arrived last, it may mail someone who has opted out.

Fix this by defining an authoritative consent model, clear precedence rules, and a durable event history. A newer opt-out should not be overwritten by an older “subscribed” import. Test the full path from preference center to every activation destination.

Overmatching and incorrect identity merges

Matching “Alex Smith” at the same company or using similar email addresses can accidentally combine separate people. Once merged, one person’s purchase history, preferences, or suppression can affect another person’s email.

Use high-confidence identifiers for high-impact actions. Maintain match confidence and source lineage. Create review processes for ambiguous matches, and make profile merges reversible where possible. The goal is not maximum match rate at any cost; it is reliable matching that supports safe decisions.

Duplicate sends caused by multiple identifiers

The opposite problem also occurs: one person has several records and receives the same campaign repeatedly. This may happen when a subscriber uses both a personal and work address, changes their address, or has an old CRM contact plus a new product account.

Define contact policies. For a customer-level promotion, you might select one preferred deliverable address per profile. For security or account communications, multiple addresses may be appropriate only when the account settings explicitly support them. Track email-level eligibility separately from profile-level eligibility.

Treating anonymous behavior as permission

An anonymous page view may be useful for onsite personalization or aggregate analysis. It does not, by itself, create permission to email a person. The CDP must distinguish browser or device identifiers from known, contactable profiles and must not turn a behavioral cookie into an email audience without an appropriate connection and permission state.

Event duplication and out-of-order events

Distributed systems retry requests. Webhooks can be delivered more than once. Events can arrive late. If a campaign triggers every time it sees order_completed, duplicate events can produce duplicate receipts or promotions.

Use event IDs, idempotency controls, event timestamps, and business-level safeguards. For example, before sending an order confirmation, verify that the order is in a completed state and that the confirmation has not already been sent for that order ID. For lifecycle mail, retain a message history that can prevent duplicate sends even if upstream events repeat.

Confusing transactional and marketing eligibility

A purchase receipt, password reset, and account-security alert usually have a different purpose from a newsletter or promotion. Treating every email as “marketing” can block important service communications. Treating every email as “transactional” can become an excuse to send promotions without honoring preferences.

Define message classes in advance, involve legal and compliance stakeholders, and implement them as enforceable fields or policies. The classification must reflect the message’s primary purpose, not merely the team that sends it.

How to improve a CDP for better email results

Improvement begins with discipline, not more integrations. Add only the data and automation that support a defined customer decision.

Start with a sending decision inventory

List every important type of email: welcome, verification, trial onboarding, abandoned cart, product updates, renewal reminders, newsletters, receipts, password resets, surveys, and win-back campaigns. For each one, document:

  • The trigger or audience rule
  • Required profile attributes and events
  • Consent or preference requirements
  • Suppression conditions
  • Frequency limits
  • The authoritative source for each critical field
  • What happens if a field is missing or delayed
  • The expected delivery and conversion outcome

This exercise exposes gaps quickly. A renewal campaign may depend on a cancellation field that is updated only nightly. A cart workflow may not know that the order completed through a different checkout path. A newsletter may use a stale export that bypasses the current unsubscribe list.

Build a minimum viable profile

Do not wait for a mythical 360-degree view before improving email. Start with the smallest profile that safely supports one use case. For a SaaS onboarding program, that could mean:

profile_id
primary_email
email_eligibility_status
marketing_consent_status
signup_at
email_verified_at
plan_type
trial_end_at
key_activation_event_at
unsubscribe_at
spam_complaint_at
last_marketing_send_at

These fields can support meaningful decisions without immediately ingesting every support transcript, advertising impression, or browsing event. Expand only after the first use case is accurate and measurable.

Make suppression immediate and centralized

An unsubscribe must be more than a tag in one campaign database. Build a central suppression event that is available to every marketing activation. Include global unsubscribe, category-level preferences, spam complaints, hard bounces, legal holds, deletion requests, and internal do-not-contact flags as separate states where needed.

For subscribed marketing mail, make opting out easy. The CAN-SPAM Act requires commercial email to provide a way for recipients to opt out, and it imposes requirements around honoring those requests. Google’s sender requirements for higher-volume senders to personal Gmail accounts also require easy unsubscribe handling for applicable messages. Technical support for one-click list unsubscribe is standardized in RFC 8058.

Test audiences as if they were production code

A segment is executable logic. It deserves change management, test cases, review, and monitoring.

Before launching a high-volume campaign, test representative profiles:

  1. An eligible subscriber who should receive it.
  2. An unsubscribed recipient who must not receive it.
  3. A recent purchaser who should be excluded.
  4. A hard-bounced address that must remain suppressed.
  5. A profile with missing consent data.
  6. A profile with multiple linked email addresses.
  7. A profile that meets two campaign rules at once.

Then inspect the final activated audience, not just the CDP preview. Confirm that removes and suppressions have reached the system that will actually transmit the email.

Establish a preference for recency and authority

When data conflicts, the system needs predictable rules. A current account cancellation should generally outrank a stale CRM lifecycle value. A direct preference-center opt-out should outrank a historical import. A verified email should outrank an unverified form entry.

Document those rules. A field dictionary should state its meaning, source, update cadence, owner, and whether it is authoritative. This is unglamorous work, but it prevents seemingly sophisticated personalization from running on unreliable assumptions.

Use holdouts to prove value

Campaign metrics can improve for reasons unrelated to the CDP: seasonality, a stronger offer, changing traffic quality, or a new subject line. When possible, use a randomized holdout group or an A/B comparison to measure whether the CDP-driven audience or trigger created incremental value.

For example, compare a behavior-based onboarding sequence against a time-based sequence for otherwise similar new users. Evaluate not only clicks and conversions but also unsubscribes, complaints, support contacts, and downstream retention. A campaign that lifts clicks while increasing complaints may be a poor trade.

CDP, CRM, data warehouse, and email platform: what is the difference?

These systems can overlap, and many organizations use combinations of them. The distinction matters because choosing the wrong tool for a job often creates fragile email operations.

CDP versus CRM

A CRM is typically centered on managing business relationships and workflows, especially for sales, service, and account management. It often holds leads, contacts, accounts, opportunities, tasks, and notes. A CDP is typically more focused on unifying data from many systems into customer profiles and audiences for activation.

A CRM can be the authoritative source for sales ownership or account stage. A CDP can combine that information with product activity, purchase behavior, and email preferences to create a campaign audience. Neither automatically replaces the other.

CDP versus data warehouse

A data warehouse is designed for storing and analyzing large volumes of structured data. It may be the best place for historical reporting, advanced modeling, and custom analysis. A CDP often adds packaged identity resolution, profile management, segmentation, and activation workflows on top of, alongside, or independently from warehouse data.

For email teams, a warehouse can answer complex questions. A CDP can make approved answers operational by continuously building and syncing audiences. Modern architectures vary: some CDPs use a warehouse as their primary data store, while others maintain their own profile store.

CDP versus email sending platform

An email sending platform handles message delivery: SMTP or API submission, sender authentication, domain configuration, bounce handling, delivery events, logs, templates, and throughput. A CDP does not replace the need for reliable email infrastructure.

Think of the CDP as helping answer whether, to whom, and with what context to send. The email platform helps answer how the message is transmitted, authenticated, tracked, and managed after submission. Keeping that boundary clear helps engineering teams avoid placing deliverability controls inside a marketing audience tool.

Privacy, security, and governance in CDP-based email

A CDP concentrates customer data. That concentration makes governance more important, not less. The system may connect identifiers, behaviors, purchases, location, preferences, and support context that were previously separated by application boundaries.

Apply data minimization. Collect and activate only the information needed for a defined purpose. Restrict sensitive attributes from campaign tooling unless there is a clear, justified use and appropriate controls. Avoid putting sensitive data into subject lines, URLs, or email content that can be exposed in notifications, logs, forwarded messages, or shared inboxes.

Access should follow least-privilege principles. A marketer who needs to create an audience may not need raw payment data, internal support notes, or full identity-resolution settings. Audit access, retain event histories, secure integration credentials, and establish retention and deletion processes.

Transparency matters as well. People should be able to understand what communications they can expect and manage their preferences. Legal obligations differ by location, audience, and message type, so consult qualified counsel rather than assuming a single rule applies everywhere.

A practical CDP email implementation roadmap

A phased approach is safer than attempting to connect every system at once.

Phase 1: Establish the non-negotiables

First, ensure that promotional email has a reliable eligibility and suppression model. Define the difference between transactional and marketing mail, centralize unsubscribe handling, record hard bounces and complaints, and identify the system of record for consent.

At the sending layer, configure domain authentication and maintain a clean event stream. If you send at scale, monitor mailbox-provider guidance, complaint trends, and delivery failures alongside campaign outcomes.

Phase 2: Connect high-value lifecycle data

Add the few product, commerce, or account events that support the most valuable workflows. Typical candidates are account creation, verification, first key action, trial start and end, purchase, shipment, cancellation, payment failure, and renewal.

Build a small number of high-confidence automations. A verified-account welcome series is usually a better starting point than a sprawling, highly personalized campaign built on loosely defined web behavior.

Phase 3: Add identity and frequency controls

Implement profile linking with conservative rules, define a preferred email address policy, and establish cross-campaign frequency controls. Audit campaign overlap and create suppression logic for recent purchasers, current customers, and support-sensitive situations.

Phase 4: Measure, test, and refine

Measure data freshness, audience accuracy, suppression propagation, deliverability indicators, and incremental business results. Review failures at the profile level. When an inappropriate message is sent, find the precise rule, source field, timestamp, and sync path that allowed it.

This makes the CDP an accountable operational system rather than a black box that merely promises a “single customer view.”

Conclusion

A customer data platform (CDP) is valuable for email when it helps a sender make safer, more relevant communication decisions. Its best contribution is not a larger database or more elaborate personalization. It is the ability to connect accurate identity, current consent, meaningful behavior, and suppression data before a campaign reaches the sending infrastructure.

For deliverability, that means fewer messages to the wrong people, faster suppression of people who opt out, better lifecycle timing, less campaign overlap, and a clearer path from customer activity to useful communication. Pair those audience controls with sound email infrastructure, authentication, unsubscribe handling, and continuous monitoring. The inbox is ultimately earned through recipient trust; a well-governed CDP gives teams a better way to protect it.

FAQ

Is a CDP required for email marketing?

No. A small program can run effectively with a CRM, email platform, clean consent records, and disciplined segmentation. A CDP becomes more useful when customer data is fragmented across multiple systems, campaigns need real-time behavioral triggers, or several teams need to coordinate audiences and preferences.

Does a customer data platform improve inbox placement by itself?

No. A CDP cannot replace SPF, DKIM, DMARC, reliable sending infrastructure, list hygiene, unsubscribe handling, or relevant content. It can improve the audience and timing decisions that influence recipient reactions, which can support healthier long-term deliverability.

What data should an email CDP collect first?

Start with identity, email eligibility, consent and unsubscribe status, account or purchase status, a small set of meaningful lifecycle events, and recent send history. Add fields only when they support a specific sending decision.

Can a CDP send transactional email?

A CDP can trigger or activate an event that leads to transactional email, but it is not necessarily the system that transmits the message. A dedicated email API or SMTP provider usually handles delivery, authentication, bounce processing, and event reporting.

How does a CDP handle unsubscribes?

A strong implementation treats an unsubscribe as a durable, centralized suppression event. That event should quickly update every marketing audience and sending system, preserve the timestamp and source, and prevent an older import or profile sync from re-subscribing the person accidentally.