On this page: Establish the list, sender and product scope · Configure SPF without replacing other senders · Publish both MailUp DKIM records · Configure the current custom Envelope Sender workflow · Preserve DMARC and choose a safe monitoring start · Verify DNS, activation and real message identity · Troubleshooting and frequently asked questions · Related guidance and review boundary
For MailUp, verify the From address, configure the documented SPF authorization and branded DKIM, then inspect a delivered message. A custom Envelope Sender is a separate workflow: the current interface generates CNAME records, whereas older documentation describes MX and TXT setup. Use the workflow for your account rather than combining them. Current Envelope Sender instructions
Establish the list, sender and product scope
This guide covers email sent by the MailUp platform, not corporate mailbox hosting, SMS sender IDs or another vendor with a similar name. Record the account, list/environment, sending application, exact From address and DNS owner. Repeat the inventory for lists using other brands or subdomains. A successful check on one sender does not prove that all campaigns select that sender.
MailUp's sender management lets you add a sender, complete email-address verification and inspect test results. Use Settings > Account settings > Senders Management > Senders authentication in the documented navigation. Open Test Results for details; Repeat the tests refreshes checks after changes. Address verification establishes access to a mailbox, not cryptographic authentication for the domain. Sender management
Confirm whether your organization uses MailUp Shield or Brand Shield. The pricing page describes MailUp Shield as replacing the sender domain with a MailUp domain, while Brand Shield provides custom alignment using your brand. Both are listed as optional features, so do not assume an existing subscription includes your desired customization. Current plan comparison
This distinction matters when assessing a “pass.” A rewritten provider-domain From address might pass DMARC without meeting your branding requirement. Write the intended visible From domain into the acceptance checklist before beginning. If preserving the brand is essential, resolve feature availability with the account administrator before changing records.
Configure SPF without replacing other senders
MailUp's published authorization mechanism is include:musvc.com. For an owner whose only authorized sender is MailUp, the documented starting example is:
Owner: example.com
Type: TXT
Value: v=spf1 include:musvc.com ~all
Replace the example owner with the sending domain in the applicable setup. If SPF already exists, add the mechanism before the final all rather than creating a second policy. Keep other legitimate authorizations and the existing policy ending unless a separate review approves changing it. MailUp setup reference
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
SPF checks the envelope MAIL FROM domain, usually exposed as Return-Path, not the visible From domain. Adding the mechanism to a branded domain does not by itself switch MailUp's envelope address to that domain. Treat authorization and actual envelope selection as separate checks.
Use one SPF policy per evaluated owner and check the ten DNS-lookup-causing-term limit across nested evaluation. A record with only a few includes can still exceed the limit through their dependencies. Never merge two complete v=spf1 strings or paste a standalone example over an established policy. SPF standard
If the current Envelope Sender workflow asks for a CNAME at a particular owner, do not also add a local TXT SPF record there. An alias and ordinary data cannot coexist at the same owner. Follow the exact records issued for that route; the older root-domain example is not a replacement for generated envelope configuration.
Publish both MailUp DKIM records
MailUp's published branded-DKIM configuration uses these CNAMEs:
Owner: ml01._domainkey.example.com
Type: CNAME
Target: ml01.dkim.musvc.com
Owner: ml02._domainkey.example.com
Type: CNAME
Target: ml02.dkim.musvc.com
These are official public targets, not invented tenant keys. Replace the example signing domain and compare the records with the current account instructions. If the DNS host cannot support the required CNAMEs, MailUp directs customers to support for a TXT alternative; do not generate an independent key and expect MailUp to sign with it. Official DKIM record instructions
Publish both records, even if a single sampled message uses only one selector. The public records provide key discovery; a delivered signature establishes which selector was used. Never put a password, API key or private DKIM key in DNS. The relevant message fields are d= for signing domain and s= for selector. DKIM standard
For news.example.com authenticated inside the parent example.com zone, a relative owner is ml01._domainkey.news, not simply ml01._domainkey. For a root sender, a panel that appends the zone uses ml01._domainkey. Inspect the fully qualified saved name to avoid duplicated suffixes.
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
If either selector already contains another record, investigate before replacement. Another account or older configuration may still use it. Preserve unrelated DKIM selectors, inbound MX and website records. Keep the CNAME targets as hostnames, without protocol prefixes, paths or pasted spaces.
Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
Configure the current custom Envelope Sender workflow
Open the domain's Envelope Sender configuration and choose Get DNS records. Publish the generated CNAME name and target exactly, then use Verify now if status does not update. MailUp's documented states distinguish NOT CUSTOMIZED and PENDING, which still use a shared MailUp envelope domain, from CONFIGURED, which uses the selected custom envelope. A free-provider domain can be NOT CONFIGURABLE. Envelope Sender states and setup
Do not invent a universal bounce target or copy a record from another account. Save the issued public records with the domain and list inventory. Check the configured state before sending a new sample, then confirm the actual Return-Path. State transitions and real message behavior are complementary evidence, not interchangeable.
Older MailUp guidance describes a dedicated bounce subdomain with MX and SPF TXT records. It also warns that changing MX hands mail handling for that owner to the platform. Do not apply that older recipe on top of a newly generated CNAME, and never point your normal corporate mailbox domain at bounce handling. Existing legacy arrangements should be reviewed with MailUp rather than deleted as “wrong” solely because the current screen differs. Older configuration reference
Tracking-domain customization is separate. A branded click URL does not demonstrate that the envelope or DKIM identity changed. Likewise, an optional product label does not prove strict alignment: inspect the actual domains under the policy in use.
Preserve DMARC and choose a safe monitoring start
Check the exact From domain and applicable parent policy first. A missing local _dmarc record does not mean a subdomain lacks inherited enforcement. Retain established p=reject or p=quarantine protection and reporting destinations. Do not create a child monitoring exception simply to satisfy a setup wizard.
Only for a genuinely new policy with no existing or inherited protection to preserve, an approved monitoring example is:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
For From addresses at news.example.com, the local policy owner is _dmarc.news.example.com. Use _dmarc.news in the parent example.com zone, or _dmarc when editing a separately delegated news.example.com zone. Confirm the full saved owner. External aggregate-report destinations must satisfy RFC 9990 section 4 reporting authorization; use the reporting service’s issued authorization rather than guessing a record.
Use your actual domain and provisioned report mailbox. Retain semicolons between tags and publish one policy at this owner. If a reporting service provides an external destination, follow its authorization requirements. Review results across all senders before considering enforcement.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For the apex example _dmarc.example.com, enter relative _dmarc in the example.com zone, not @.
DMARC passes with either aligned passing SPF or aligned passing DKIM. Relaxed alignment permits a shared organizational domain; strict alignment requires an exact match. A custom bounce subdomain can therefore satisfy relaxed SPF alignment without satisfying strict SPF alignment. Do not weaken alignment settings just to make a new service appear correct. RFC 9989 replaces RFC 7489 and removes pct, which appears in older vendor examples.
Verify DNS, activation and real message identity
Replace these examples with your configured names:
dig +short NS example.com
dig +short TXT example.com
dig +short CNAME ml01._domainkey.example.com
dig +short CNAME ml02._domainkey.example.com
dig +short TXT _dmarc.example.com
Also query CNAME at the exact account-generated envelope owner. Expect the issued target, both DKIM aliases, one appropriate SPF policy where a TXT policy is required, and the intended DMARC policy. Confirm authoritative DNS rather than relying solely on a registrar's saved screen. If recursive results lag, compare TTLs and cached answers before making another edit.
Follow each issued DKIM alias to its usable public verification key as well as checking the exact CNAME target. A matching alias alone does not prove key availability.
Run MailUp's sender checks and confirm any custom-envelope activation. Then send a newly generated campaign through each relevant list and route to a mailbox you control. Inspect the recipient system's trusted Authentication-Results. Capture spf with smtp.mailfrom, dkim with header.d, and dmarc with header.from; record the corresponding DKIM selector. Do not trust arbitrary sender-inserted authentication headers. Receiver-header trust model
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
Success means the intended branded From remains intact, the expected signing/envelope configuration appears, and the trusted receiver reports dmarc=pass through an aligned path. Keep a redacted header sample, list ID and timestamp. Avoid uploading confidential campaigns to public diagnostic tools. Passing authentication does not guarantee an inbox result.
For this branded-DKIM deployment, require the intended provider signature itself to have trusted dkim=pass and a d= domain aligned with the intended unchanged visible From under effective adkim, plus the trusted receiver’s dmarc=pass for that From. A DMARC pass through SPF alone does not complete the DKIM task. DMARC alignment. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Troubleshooting and frequently asked questions
Why is SPF green while DMARC fails?
A check can confirm authorization without confirming the message's aligned identity. Inspect the actual Return-Path and branded DKIM result. If the envelope is still shared, check whether custom setup remains pending or the wrong sender/list is selected.
Why do public records look correct but the panel stays pending?
Compare exact generated targets, authoritative nameservers, owner suffixes and DNS proxy settings. Then run the documented recheck. Do not repeatedly regenerate records, which can leave administrators troubleshooting values that no longer match the account.
Why did the visible sender change?
Check whether MailUp Shield or an automatic authentication option is active. A provider-domain replacement is not the same as Brand Shield. Resolve the chosen sender behavior with the account owner, rather than disabling security features blindly.
Can I reuse the same records for a sender subdomain?
Not by assuming parent-domain configuration covers every sender. Publish records for the exact signing domain requested and validate each From route. DMARC inheritance and provider-domain verification are different mechanisms.
Should I follow the older MX instructions or the new CNAME screen?
For a new supported account workflow, use its issued CNAMEs. For an existing legacy setup, ask MailUp to confirm the migration plan before replacing records. Never combine incompatible record types at the same owner.
Related guidance and review boundary
Keep employee mail separate: EmailAuth's Workspace alias and secondary-domain alignment guide addresses another sending route that may share your domain.
No account settings, DNS records or campaigns were changed or tested for this guide. Complete the account, DNS and delivered-message checks above for your sending route. Authentication does not guarantee inbox placement.