Who owns the footer, unsubscribe link, and merge tags on export

An email footer looks like one block at the bottom of a message, but several systems may be responsible for what finally reaches the inbox.

The email builder controls the visual structure. The ESP controls subscriber data, suppression, and sending logic. The sender remains responsible for making sure the campaign meets the legal requirements that apply to the business and its recipients.

Those roles overlap during export, which is why footers are a common source of duplicated unsubscribe links, broken merge tags, and last-minute design changes.

The safest approach is to treat email footer requirements as both a design problem and a sending-platform problem. The footer needs to look intentional before export, but it also needs placeholders that the destination ESP can turn into working subscriber-specific elements.

Three systems can touch the same footer

It helps to separate ownership before discussing the technical details.

The email builder owns presentation:

• Footer Layout;
• Typography;
• Colors;
• Spacing;
• Logo And Social Links;
• Location Of The Unsubscribe Text;
• Reusable Modules.

The ESP owns sending-time behavior:

• Subscriber-Specific Merge Tags;
• Unsubscribe Processing;
• Suppression Lists;
• Subscription Preferences;
• Tracking;
• Message Headers Such As List-Unsubscribe.

The sender owns the business decision:

• Which Legal Rules Apply;
• Which Sender Identity Must Appear;
• Which Physical Address Is Correct;
• Which Subscription Type The Message Belongs To;
• Whether Consent And Suppression Processes Are Appropriate.

A template can support email compliance, but a template alone can't provide it.

The List-Unsubscribe link is not part of your HTML footer

This distinction causes a lot of confusion.

The unsubscribe link visible at the bottom of an email lives in the HTML body.

List-Unsubscribe, however, is an email header. It sits outside the HTML document and is added as part of the message-sending process.

Under RFC 8058, one-click unsubscribe uses both List-Unsubscribe and List-Unsubscribe-Post headers. Gmail's current bulk-sender requirements also use this mechanism for qualifying promotional and subscribed messages.

You cannot create that header by adding a <div> or <a> element to the footer.

In a normal ESP workflow, the sending platform generates the appropriate message headers because it knows which recipient and subscription list the message belongs to.

This means unsubscribe link setup actually has two layers:

• A Visible Link In The Email Body;
• A Sending-Level Unsubscribe Mechanism In The Message Headers.

They should work together, but they are not the same feature.

Why a hardcoded unsubscribe URL is risky

Suppose a designer adds this:

<a href="https://example.com/unsubscribe">  
  Unsubscribe  
</a>

It looks correct.

But the ESP may have no idea which subscriber should be removed when someone opens that generic URL.

A real unsubscribe mechanism normally needs recipient- or list-specific information. ESP merge tags create that connection at send time.

Conceptually, the template should contain something like:

{{ unsubscribe }}

The exact syntax depends on the ESP.

When the campaign is sent, the platform replaces the placeholder with the correct subscriber-specific destination and connects the action with its suppression or subscription system.

A hardcoded link can bypass that logic.

The visible footer may look fine while the backend process is wrong.

What happens when the template already has a footer

Another common problem appears when an imported template contains a complete-looking footer but not the tags expected by the ESP.

The ESP may then add its own required elements.

The result can be:

Company address
Privacy policy
Unsubscribe

followed immediately by:

Manage preferences | Unsubscribe
Company address

Nothing has technically "broken." Two systems simply believed they owned the same part of the message.

HubSpot is a useful example. Its current marketing-email setup requires footer information and subscription-management links. Custom email footers can be used, but they still need the required HubL address variables and an unsubscribe or preference token.

Other ESPs solve the same problem through their own syntax and validation rules.

That is why the footer should be designed around placeholders before export rather than completed with static links that only look functional.

Merge tags have the same ownership problem

Unsubscribe links are only one kind of merge tag.

A template may also contain:

• First Name;
• Company Name;
• Account Details;
• Preference URLs;
• View-In-Browser Links;
• Dynamic Product Data.

The builder can provide the location and styling for those fields, but the ESP ultimately supplies the values.

And every platform has its own syntax.

That is where exports often fail. A perfectly valid placeholder in one system becomes plain text in another because the destination does not recognize it.

A safer workflow is to choose the destination ESP before final export and convert merge tags into that platform's expected syntax.

Stripo supports platform-specific merge tags as part of the template preparation process, so the placeholder can be prepared for the destination rather than repaired after import.

Design the footer as a reusable module

The design side of the problem should be boring.

You should not rebuild the same footer every time a campaign moves to another ESP.

Create one modular structure containing the stable elements:

• Brand Identity;
• Company Information;
• Physical Address Area;
• Social Or Support Links;
• Privacy Or Preference Links;
• Unsubscribe Placeholder.

Then keep platform-specific behavior in the dynamic fields.

This makes email footer design easier to maintain. If the legal team changes the address or the brand team updates a social icon, one approved module can be updated instead of editing dozens of templates.

The broader principles in email design best practices apply here too: the footer should remain readable, visually consistent, mobile-friendly, and easy to navigate without competing with the main content.

Where the builder-to-ESP handoff still breaks

There is no export workflow that removes every compatibility issue.

Several limitations are worth planning for.

The ESP may require its own tags. A generic placeholder may need to be replaced with platform-specific syntax.

The ESP may inject required content. If it does not detect the expected unsubscribe or address tokens, it may add or require another footer.

Global settings can override the template. An administrator may manage addresses, preference links, or compliance modules centrally.

The imported HTML may change. ESP editors can sanitize or rewrite markup during import.

Different campaign types may follow different rules. Transactional and promotional messages can have different subscription and compliance requirements.

Header behavior is outside the builder. List-Unsubscribe and related sending headers are generated later in the pipeline.

This is why no builder should promise that the exported footer will remain untouched.

The objective is controlled adaptation, not zero change.

Test the footer after export

Do not approve only the version inside the builder.

Send a real test through the destination ESP.

Check:

1. Confirm The Correct Physical Address Appears.
2. Click The Visible Unsubscribe Link.
3. Verify That It Leads To The Expected Subscription Action.
4. Check That The ESP Has Not Added A Second Footer.
5. Test Personalization And Preference Merge Tags.
6. Inspect The Message In Gmail Or Another Mailbox To Confirm The Sending-Level Unsubscribe Option Where Applicable.
7. Test The Mobile Version.
8. Forward The Message And Check That The Footer Remains Readable.

A test recipient should never be a real active customer account if clicking unsubscribe could alter production subscription data.

Use controlled test contacts instead.

The cleanest model is shared ownership

The footer is not owned by one tool from beginning to end.

The builder should own its visual system and reusable structure.

The ESP should own recipient-specific unsubscribe behavior, suppression, merge execution, and sending headers.

The sender should own the decisions that determine whether the campaign follows applicable rules.

Stripo can keep the design side consistent by letting teams reuse a saved modular footer and prepare platform-specific merge tags before export. But the destination ESP still needs to perform the operations that belong to the sending layer.

Keeping those responsibilities separate prevents many of the most common export problems.

When something goes wrong, the first question should therefore not be "Why did the footer break?"

Ask which layer was supposed to control the element that changed.

That usually points to the fix much faster.