Sender Authentication Package: the setup playbook | Cleon

The Sender Authentication Package (SAP) is the foundational Marketing Cloud setup that determines what a recipient actually sees in their inbox: your branded From name, a sending domain that resolves to your company instead of *.exacttargetapps.com, a reply address that routes back to your team, a DKIM signature that says the email is actually from you, and the SPF / DMARC alignment that keeps mailbox providers from filtering you into the spam folder. Without SAP configured, every email goes out from the generic tenant defaults — spam filters love them, recipients learn to ignore them, and your deliverability ceiling is a fraction of what it could be.

This page is the setup playbook anchored to the rollouts Cleon has done across multi-tenant Marketing Cloud implementations. The sequence works the same on a fresh tenant and on a migration from another ESP. Each step is followed by the verification check that confirms it landed, plus the failure mode that most often surfaces in production sends after the SAP is supposedly "done".

What the SAP actually bundles

[ Sender Authentication Package ]
        ├── Custom sending domain (e.g. mail.yourbrand.com)
        ├── Branded From Name (visible at inbox level)
        ├── Reply Mail Management (RMM) — where replies go
        ├── DKIM signing (cryptographic proof the mail came from you)
        ├── SPF alignment (which IPs are authorized to send for your domain)
        ├── DMARC alignment (the policy that ties DKIM + SPF together)
        └── Account-Level Personalization (the default sender profile)

You don't configure each component independently — you configure the SAP as a unit, and MC propagates the choices into the right surfaces. The sequence below treats the SAP as one durable rollout instead of seven separate tasks.

Prerequisites

Before opening MC's SAP wizard, gather:

| Prereq | Where it comes from | |---|---| | DNS edit access for the sending domain | Your DNS / hosting provider (Cloudflare, Route53, GoDaddy, internal DNS team) | | MC Administrator role on the BU where SAP will live | MC Setup → Users; verify before you start | | Branding decisions: the sending domain, the From name, the reply address | Marketing + Legal — these are visible to every recipient | | A list of the IPs MC will send from | MC Setup → Sender Authentication → IP Addresses (the values you'll add to SPF) | | A test inbox you control (preferably one per major mailbox provider — Gmail, Outlook, corporate) | For the post-rollout verification sends |

The hand-off failure shape: the SAP wizard prompts for DNS records halfway through, the person running the wizard doesn't have DNS access, and the half-done SAP sits in a "pending verification" state for days. Confirm DNS access before opening the wizard.

Step 1 — Choose the sending domain

The sending domain is what shows up after the @ in the From address. The Cleon convention: use a dedicated subdomain of your primary brand domain, not the apex domain.

| Pattern | Example | Use | |---|---|---| | Apex domain | from@yourbrand.com | Avoid — couples deliverability to your primary domain | | Marketing subdomain | from@mail.yourbrand.com | Default — isolates email reputation | | Transactional subdomain | from@transactional.yourbrand.com | When marketing + transactional volumes differ enough to warrant separate reputations | | Per-product subdomain | from@news.yourbrand.com, from@offers.yourbrand.com | Large programs where bouncing one product shouldn't affect the others |

Why a dedicated subdomain:

- A spam complaint at scale on @mail.yourbrand.com doesn't poison
  @yourbrand.com for transactional mail (password resets, receipts).
- You can transition between ESPs by re-pointing one subdomain
  without touching the apex.
- DMARC enforcement on the apex can be stricter than what marketing
  programs need; subdomains can have their own DMARC policy.

Decide the subdomain before opening MC's wizard. Once entered, it's tedious to change — the SAP rebuilds, and any in-flight Send Definitions referencing the old domain break.

Step 2 — Add the DNS records

The MC wizard produces three categories of DNS records you must add at the DNS provider for your sending domain. The records are domain-specific; MC generates them after step 1.

SAP-mandated DNS records:

1. CNAMEs for the sending domain
   - Used for MC to claim the subdomain
   - Example: mail.yourbrand.com → cnames.exacttarget.com

2. CNAMEs for image/link tracking (the "RMM" subdomain)
   - Example: reply.yourbrand.com → mta.exacttargetapps.com
   - This is what makes RMM work end-to-end

3. TXT records for SPF, DKIM, DMARC
   - SPF: a single TXT record listing all authorized senders
   - DKIM: TXT records containing the public key for signing
   - DMARC: TXT record at _dmarc.yourbrand.com defining the policy

After adding the records, wait for DNS propagation before proceeding. The verification step in MC pings the DNS and fails if the records haven't propagated yet. Cleon convention: 24-hour wait after the DNS edits go in, then run the verification. Trying to verify too early is the most common SAP rollout delay.

Use dig or an online checker to confirm propagation:

# Confirm CNAME resolution
dig mail.yourbrand.com CNAME

# Confirm SPF (look for the v=spf1 record)
dig yourbrand.com TXT | grep spf1

# Confirm DKIM (the selector MC gave you — e.g. selector1._domainkey)
dig selector1._domainkey.yourbrand.com TXT

# Confirm DMARC
dig _dmarc.yourbrand.com TXT

If any of the four returns nothing, the record didn't propagate or isn't where you expect. Don't proceed to the next step until all four resolve.

SPF flattening: the gotcha that bites multi-ESP organizations

SPF has a hard limit of 10 DNS lookups per evaluation. Each include: in your SPF record counts as a lookup. If your organization uses Marketing Cloud + Google Workspace + a transactional ESP + a marketing automation platform, you can easily blow past 10.

# Naive SPF (likely to exceed 10 lookups):
v=spf1 include:_spf.google.com include:spf.protection.outlook.com
       include:exacttarget.com include:sendgrid.net
       include:mailchimp.com -all

# When SPF exceeds 10 lookups, mailbox providers return PermError —
# and your DMARC alignment fails, even though your DKIM is fine.
# The send still goes through, but spam filtering and inbox placement
# silently degrade.

The defense is SPF flattening — using a third-party service (or a manually-maintained TXT record) that resolves all the include: directives into a single static IP list. If you're running the SAP setup for an org with more than two senders on the same domain, audit the SPF lookup count before you ship.

Step 3 — Configure Reply Mail Management (RMM)

RMM is what makes reply@mail.yourbrand.com route to your team instead of being lost in MC's send-only infrastructure. Two things to configure:

The reply subdomain: typically reply.yourbrand.com (CNAMEd to MC's MTA in step 2). When a recipient hits Reply, the email goes to <token>@reply.yourbrand.com.
The forwarding rule: MC routes inbound replies to one of:
- A real mailbox you control (replies@yourbrand.com)
- An RMM ticketing integration (Salesforce Service Cloud, Zendesk, etc.)
- A black hole (rare, only for one-way sends — confirm with the team this is intended)

The Cleon convention: never black-hole replies on customer-facing programs. Even no-reply addresses should route to a monitored mailbox that catches the "we sent the wrong thing" replies and the occasional bounce notification that didn't classify properly.

Step 4 — Configure the From Name and Reply Address

The From Name is the visible "Who is this from?" at the inbox level. Two configuration options:

Sender Profile: per-send default (Send Activity uses this unless overridden)
Account-Level Defaults: applied to every BU unless overridden at the BU level

The Cleon convention:

- One Sender Profile per *brand persona* (not per program).
  "YourBrand", "YourBrand Newsletter", "YourBrand Support" — not
  "Q1 Promo", "Winter Sale", "Welcome Email".

- From Name should match the brand recipients recognize. Don't
  test with "Marketing Team" and ship with "Acme Inc." — recipients
  hit Mark As Spam on unfamiliar From Names.

- Reply Address must match the RMM configuration. If RMM forwards
  reply.yourbrand.com → support@yourbrand.com but the Sender Profile
  says reply-to is help@yourbrand.com, replies disappear.

Step 5 — Activate the SAP in MC Setup

Once DNS is verified, RMM is configured, and the Sender Profile is set, activate the SAP via MC Setup → Email Studio → Email → Sender Authentication. The activation:

Switches all sends from the BU to use the new sending domain
Begins DKIM-signing outbound mail with the configured key
Enables RMM routing for the reply subdomain
Applies the new Sender Profile to existing Send Definitions unless they explicitly override

The activation is not silently reversible — once active, in-flight Send Definitions that were configured for the old (default) domain will break. Plan the activation for a quiet window (no scheduled sends in the next 24 hours), and re-test all production Send Definitions immediately after.

Step 6 — Verify with a test send

The only conclusive verification is a real test send to a real inbox you control, examined for:

| Check | What to look for | |---|---| | From name displays correctly | Inbox sender column reads your branded name, not exacttargetapps.com | | From address uses sending domain | Open the email; "From: Name <from@mail.yourbrand.com>" | | Reply works end-to-end | Hit Reply; verify the message lands in the configured reply mailbox | | DKIM passes | View original / show source; look for DKIM-Signature header + dkim=pass | | SPF passes | Same headers view; look for spf=pass | | DMARC aligns | dmarc=pass and the header.from aligns with the SPF/DKIM domain | | Links route through tracking subdomain | Inspect any link in the email — href should be https://click.mail.yourbrand.com/... not *.exacttargetapps.com | | Tracking pixel loads from the right domain | Inspect the email source; image URLs should be on the SAP'd domain |

If any check fails, the SAP isn't done — work backward through the steps to find where it broke. Most often it's a DNS record that didn't propagate fully (one provider returns the record, another doesn't), or a Sender Profile that didn't update after activation.

Repeat the test send across at least three mailbox providers (Gmail, Outlook, and one corporate mailbox you have access to). Each provider can interpret SPF / DKIM / DMARC slightly differently; passing all three is the bar.

Common gotchas during a first SAP rollout

| Gotcha | Symptom | Fix | |---|---|---| | DNS verification fails on step 5 | MC wizard hangs at "Pending Verification" | Wait 24 hours after DNS edits; use dig to confirm propagation before retrying | | SPF exceeds 10 lookups | Test send shows spf=permerror | SPF flattening; remove unused include: directives | | DKIM signs but DMARC fails alignment | dkim=pass but dmarc=fail | DKIM d= domain doesn't match the From domain; reconfigure DKIM at the correct subdomain | | RMM replies go nowhere | Test reply doesn't arrive | Reply subdomain CNAME not propagated, or RMM forwarding rule not configured | | Old Send Definitions break after activation | Send Activity errors with "sender domain not valid" | Edit the affected Send Definitions to use the new Sender Profile | | Tracking links still point at *.exacttargetapps.com | Link inspection shows the old domain | Click-tracking subdomain CNAME not propagated, or the Send Definition is referencing the old click domain | | Test send works on Gmail but fails on Outlook | DKIM/DMARC pass on one provider, fail on another | Outlook is stricter about DMARC alignment; usually a d= mismatch or SPF flattening issue | | The branded From name reverts to "Marketing Cloud" | Recipient inbox shows wrong From name | Sender Profile wasn't activated, or the BU is overriding with Account-Level Defaults |

Post-rollout checklist

After the SAP is activated and the test sends verify:

[ ] All production Send Definitions re-tested with the new Sender Profile
[ ] DMARC report monitoring set up (use a service like Postmark / dmarcian / valimail; first report arrives within 48 hours)
[ ] DNS records documented in the team's infrastructure runbook (TTLs, what each record does, who has DNS edit access)
[ ] Rollback procedure documented (which DNS records to revert if SAP needs to be undone)
[ ] RMM ticket routing tested with a real reply that reaches the support team
[ ] BU-level overrides audited (which BUs intentionally use a different Sender Profile)
[ ] First production send after activation reviewed for deliverability metrics (delivered %, bounce %, complaint rate vs the baseline before SAP)

Marketing Cloud principles from production — the meta-rules that apply to setup decisions
MC SQL Style Guide — the convention reference for the de_log_* log DEs SAP-related audit work writes to
MC AMPscript — Cloud-write functions — Cloud-writes depend on the SAP being correctly configured at the BU running the send

Catalog progress: with this page, the Config subcategory opens with its first article. Following the SQL/SSJS/AMPscript catalog shape, the next pieces target Business Unit architecture decisions, Send Classifications, Data Extension architecture patterns, and a Config Style Guide tying the setup discipline together.