Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Map the MailUp sender before changing authentication
MailUp distinguishes a verified sender address, domain authentication, a custom Envelope Sender and tracking-domain customization. Treat those as separate checkpoints. Begin with the account, list, campaign or workflow, intended From address and the owner of its DNS zone. Identify whether the account is using ordinary sender authentication, Brand Shield customization or an older support-managed arrangement. A successful send from another list does not establish this list's identity.
The first-party sender guide describes adding a sender with New Sender, checking its test results and repeating those checks after corrective changes. It also describes provider automatic authentication for addresses without customer SPF or DKIM setup. That fallback should not be assumed to authenticate the customer's own domain for DMARC. Inspect the emitted identities before relying on it. MailUp sender authentication.
Have the marketing owner inventory default sender addresses, scheduled campaigns and active workflows. Have the DNS owner preserve existing SPF, selectors and any proposed CNAME owners. The mail-security reviewer should record the required alignment mode and acceptance criteria. Work on an approved test list or tightly controlled recipient selection so that identity changes do not unexpectedly affect the whole customer database. Preserve baseline messages where available and note which production paths remain untested.
Apply the documented basic SPF and DKIM setup
MailUp's basic SPF guide specifies include:musvc.com, inserted into an existing SPF policy rather than published as a second policy. Its DKIM guide specifies two CNAME owners, ml01._domainkey.<your-domain> and ml02._domainkey.<your-domain>, pointing respectively to ml01.dkim.musvc.com. and ml02.dkim.musvc.com.. Those pages remain accessible but display older revision dates, so compare their values with the current account configuration or provider confirmation before editing. MailUp SPF setup and MailUp DKIM setup.
Document both selectors even if only one appears in the first received message. Do not remove the second because it looks unused. Check for existing records at each owner, accidental domain suffix duplication, incorrect record types and proxy behavior that changes the public DNS answer. The basic DKIM guide directs customers to contact MailUp for a TXT alternative if CNAME publication is unavailable. Do not manufacture a TXT key or copy another account's public-key material.
Keep SPF authorization tied to its actual purpose. Publishing an include at the visible From domain does not by itself change MailUp's SMTP envelope. The SPF result used for DMARC concerns the authenticated envelope identity, not an arbitrary TXT lookup of the address displayed in the inbox. Check effective DNS-lookup cost after merging includes and retain every other legitimate sender that still uses the policy. SPF specification.
Configure a custom Envelope Sender where supported
MailUp's current documentation places Envelope Sender customization under Brand Shield. The accessible Spanish user guide, updated June 20, 2025, describes a domain list derived from verified senders. Open the relevant domain's configuration, request its DNS records, publish the generated CNAME and use Verify now when needed. The guide distinguishes not customized, pending, configured and nonconfigurable domains; pending configuration continues to use the shared MailUp envelope domain. Use the exact generated owner and target rather than reconstructing a value from examples. MailUp Envelope Sender guide.
Confirm that the feature is available in the actual account before planning a change. This research did not inspect commercial entitlement, console availability or a customer's generated records. The procedure above is grounded in the retained first-party Spanish guide; this package does not establish an inspection of the English Envelope Sender page. Confirm the current account labels. Ask for current account or support evidence if the live interface differs.
For a pending state, compare the complete public CNAME answer with the generated target, then repeat the platform verification. Check the hostname's DNS-only behavior if a proxy service obscures the record. A configured state is still only a platform check: the next controlled message must demonstrate the envelope that was actually used. Preserve bounce handling as part of that test, using only an approved controlled failure scenario when one is needed.
Keep tracking customization separate from authentication
MailUp's advanced tracking guide describes one customized second-level tracking domain applied across all lists in the platform. It generates three CNAME records for tracking, image hosting and HTTPS certificate support. Review that account-wide effect with every affected brand owner before changing it, and publish the generated set rather than treating a single tracking alias as the whole configuration. Advanced tracking-domain customization.
This setting deserves a functional acceptance check of its own. Inspect a safe clicked link, an image URL and successful HTTPS loading in the received campaign. A working tracking domain is useful branding evidence, but it does not substitute for the receiver's SPF and DKIM results. In a multi-brand account, document how the one tracking-domain choice relates to each list's From domain instead of implying that all domains automatically become identical.
MailUp's alignment guidance identifies Brand Shield as a way to coordinate From, DKIM, Return-Path and tracking domains. That is a configuration objective, not evidence that the account has already achieved it. MailUp alignment guidance. Retain distinct expected and observed values for all four identities so that a partially completed migration remains visible.
Prove alignment with the actual list and workflow
DMARC can pass through aligned SPF or aligned DKIM. A monitoring policy does not make a failed authentication result pass, and an existing enforcement policy should not be weakened simply to match a setup example. Compare the actual From domain against the authenticated identities under the applicable policy's alignment mode. Reply-To and tracking links do not enter that comparison. DMARC specification.
The required original received-message identity table remains unexecuted. Add a row for each tested list, sender domain and workflow. Record account, list, campaign or automation identifier, time, From, Reply-To, Return-Path, receiver SPF domain/result, every DKIM d=/s= and result, alignment determination, DMARC result, Envelope Sender status, tracking hostname and restricted evidence location. Keep screenshots of generated public records alongside the original received source, but never substitute screenshots for the message itself.
Test the actual production-style path with controlled recipients. An editor test and an automated workflow may select different defaults, so include both when both are material. Retain all DKIM signatures, not just the one whose domain looks familiar. A signature may pass while another fails, and the reviewer needs to know which passing signature supplies alignment. DKIM specification.
Recover without leaving hidden senders active
For missing DKIM, compare the received selector with the published records and confirm that the campaign uses the intended sender. For an unexpected shared envelope, check whether custom configuration is pending or whether another verified sender domain is active. For authentication passes with DMARC failure, investigate domain alignment before rewriting SPF. For link failures, inspect tracking and certificate CNAMEs separately from the mail-authentication records.
Pause the affected workflow or campaign explicitly when recovery requires it. MailUp warns that deleting a verified sender does not stop sends already using that address until the sending configuration is modified. Therefore, deletion is not a reliable emergency stop. Sender deletion behavior. Restore approved prior settings as needed, then retest messages, replies, links and bounce handling before restarting production.
No MailUp tenant, generated DNS values or live messages were inspected here. The original route-specific identity table, account feature confirmation, FAQ relevance review and human mail-security SME approval remain open. Preserve those gates before treating this unpublished candidate as an approved implementation record.