Send Classifications — Commercial vs Transactional | Cleon

Send Classifications are Marketing Cloud's mechanism for declaring what kind of mail you're sending: Commercial (a marketing message subject to CAN-SPAM, CASL, GDPR consent rules) or Transactional (a system-generated message that the recipient is reasonably expecting — password reset, order confirmation, account verification). The classification determines whether MC appends an unsubscribe link, whether it adds a physical-address footer, whether it honors the recipient's global opt-out, and whether the send respects the All Subscribers unsubscribe list.

Get the classification right and your sends comply with the regulatory regimes that apply. Get it wrong and you're either violating CAN-SPAM (a marketing send tagged Transactional skips the unsubscribe link recipients have a legal right to) or breaking transactional reliability (a real transactional send tagged Commercial means recipients can unsubscribe from their own password reset emails).

This page is the reference for the structure and the defaults. The opinions about when to use which live in Config gotchas — #4.

What a Send Classification actually is

A Send Classification in MC bundles three things:

| Component | What it controls | |---|---| | Sender Profile | The visible From Name + From Address + Reply Address. Configured at the BU level. | | Delivery Profile | The IP pool to send from and the header bounce-handling rules. Rarely customized; the default per BU is usually correct. | | CAN-SPAM Classification | The legal/compliance flag: Commercial or Transactional. Determines unsubscribe, footer, and opt-out behavior. |

The wizard in MC Setup → Email Studio → Email Send Management → Send Classifications creates the bundle. Send Activities and Send Definitions reference a Send Classification by name; the three components fire together.

Configuration flow:

1. Create the Sender Profile (or use an existing one) — see SAP setup.
2. Confirm the default Delivery Profile is appropriate (it usually is).
3. Create a Send Classification that bundles Profile A + Delivery B +
   the right CAN-SPAM flag.
4. Reference the Send Classification from every Send Definition that
   should use that bundle.

Reference:

What survives in production

Commercial vs Transactional — what each actually enables

The Commercial / Transactional flag is the part of the Send Classification with regulatory teeth. Each flag changes the platform's behavior:

| Behavior | Commercial | Transactional | |---|---|---| | Appends an unsubscribe link by default | ✓ | ✗ | | Appends a physical-address footer | ✓ | ✗ | | Honors the All Subscribers global unsubscribe list | ✓ | ✗ | | Honors the BU-level unsubscribe list | ✓ | ✗ | | Skips recipients who hit Mark As Spam previously | ✓ | partial | | Sends to recipients flagged as "Held" by complaint history | ✗ | ✓ | | Bypasses Send Throttling rules | ✗ | ✓ (delivers faster) | | Counts against MC's monthly send allotment | ✓ | ✓ (no difference here) |

The transactional flag is a privilege: it lets you reach recipients who can't be reached commercially (they unsubscribed; they complained; they're on a suppression list). That's intentional — a password reset has to reach the recipient even if they're sick of your marketing emails. Misusing it as a way to "deliver better" for marketing sends is a CAN-SPAM violation.

The Sender Profile is per-BU; cloning across BUs doesn't preserve all settings

Sender Profiles are bound to a specific BU. Creating a "Welcome" Sender Profile in BU A and a "Welcome" Sender Profile in BU B requires creating each one explicitly — the names can match, but the configurations are independent. Cloning a Sender Profile to another BU copies the visible settings (From Name, From Address) but does not propagate the SAP-related configuration (custom sending domain, DKIM signing key, link tracking domain). The clone defaults back to the destination BU's SAP.

The hand-off failure:

1. BU A has a fully-configured Sender Profile + SAP for mail.acme.com.
2. Team needs the same setup in BU B (a new sub-BU).
3. They "clone" the Sender Profile from A to B.
4. The clone shows the right From Name in the UI.
5. But B's SAP isn't configured yet — the actual sends from B use
   *.exacttargetapps.com for the From Address, link tracking, and
   image hosting.
6. The clone gave the team false confidence that B was "set up."

The Cleon convention: cloning a Sender Profile is a starting point, not a completed task. The next step is verifying B's SAP separately and running the test-send procedure from SAP setup — Step 6.

The Delivery Profile defaults are usually right — but multi-IP-pool tenants need attention

Delivery Profiles control which IP pool MC sends from and how bounces are handled. For most tenants on a single IP pool, the default Delivery Profile works as-is — the pool is the tenant's standard sending pool, and the bounce-handling matches MC's recommended defaults.

The exception is tenants with multiple IP pools (Enterprise editions with dedicated IPs for transactional vs marketing). In that setup, the Delivery Profile becomes a real choice: tagging a send to the marketing pool vs the transactional pool affects deliverability and reputation. The bundling of Sender Profile + Delivery Profile + Classification is what makes this manageable — the Send Classification "Transactional" can be bundled with the transactional IP pool, and the right pool is selected without per-Send-Definition configuration.

Send Classification overrides at the Send Definition level

A Send Definition references a Send Classification, but can also override specific components. The Sender Profile can be overridden per-send (a one-off campaign that wants a custom From Name). The Delivery Profile can be overridden (rarer; usually wrong if you're tempted). The CAN-SPAM flag cannot be overridden — it's locked at the Send Classification level by design.

The override rule:

- Sender Profile override at Send Definition: legitimate for one-off
  campaigns with custom branding (e.g., a co-marketing send with a
  partner-branded From Name).
- Delivery Profile override at Send Definition: rare; usually means
  the Send Classification structure is wrong.
- CAN-SPAM flag override: not available. To send a different
  classification, reference a different Send Classification.

The locking of the CAN-SPAM flag is intentional: it forces the Commercial vs Transactional choice to be made deliberately at the Send Classification level, not on a per-send basis. A team that wants a Send Definition to skip the unsubscribe link must explicitly switch the Send Classification reference, which is visible in code review.

Naming Send Classifications by purpose, not by content

A useful naming convention reflects what the classification is for, not what specific content uses it.

Good Send Classification names:

  - SC_Commercial_Marketing
  - SC_Commercial_Newsletter
  - SC_Transactional_AccountVerification
  - SC_Transactional_OrderConfirmation
  - SC_Transactional_PasswordReset
  - SC_Commercial_PartnerCoBranded

Bad Send Classification names:

  - SC_Q4_Promo               (campaign-specific; reusable beyond Q4)
  - SC_Welcome                (which Welcome? Commercial onboarding
                               vs Transactional verification?)
  - SC_Custom1                (says nothing)

The Cleon convention: SC_<Classification>_<Purpose> — the prefix marks it as a Send Classification, the classification spells out Commercial vs Transactional, and the purpose names the kind of send. Newly-added Send Classifications stay scarce — a tenant with 30 Send Classifications is over-classified; 5-10 covers most operations.

Reply Mail Management (RMM) tied to the Sender Profile

The Sender Profile bound to a Send Classification carries the Reply Address used by RMM (see SAP setup — Step 3). The Reply Address controls where replies route — a real mailbox, a ticketing system, or a black hole. The classification doesn't change RMM behavior, but the Sender Profile within the classification does.

A common operational failure: a transactional Send Classification was set up with a no-reply@yourbrand.com Reply Address. A customer hits Reply to a password reset email expecting to ask a question; the message goes to the no-reply mailbox; nobody reads it; the customer is unhappy. Transactional sends should not use no-reply Reply Addresses — they should route to support or to an explicit triage queue.

Quick decision

Use a Commercial Send Classification when:

The send is marketing content (promotions, newsletters, product announcements, lifecycle nurtures)
The recipient could reasonably want to unsubscribe from this type of content
The send has any sales or promotional intent

Use a Transactional Send Classification when:

The send is generated by an action the recipient took (placed an order, requested a password reset, signed up)
The content is the action's confirmation or status update, not promotional
The recipient legitimately needs to receive the message to continue using the service

Create a new Send Classification when:

The Sender Profile differs from existing ones (different brand persona, different From Name)
The Delivery Profile needs to be a different IP pool
A small handful of programs justify the new bundle (don't create per-campaign classifications)

Reuse an existing Send Classification when:

The same Sender Profile + Delivery Profile + Classification combination already exists
The send is part of an existing program family (newsletter, promo, lifecycle)

Avoid creating a Send Classification for:

A single campaign or a single Send Definition
A test or one-off that won't repeat
The convenience of "different from name" when the existing classifications work fine

MC Config gotchas — see #4 (CAN-SPAM / Send Classification misuse)
MC Config Style Guide — the discipline checklist for tenant setup
Sender Authentication Package setup — the SAP that the Sender Profile within a Send Classification depends on
Business Unit architecture — Sender Profiles are per-BU; the BU axis affects how many classifications you need
Data Extension architecture — Send Classifications reference sendable DEs; the DE design affects the operational shape

Catalog progress: with this page, Config has 5 page-pairs (gotchas + DE architecture + BU architecture + SAP setup + Send Classifications). Remaining: Subscriber Key strategy (decision-framework), Config Style Guide (decision-framework) to close the section at ~7 page-pairs.