Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify the MessageGears account and authentication domain
MessageGears documents custom authentication through a delegated subdomain. That subdomain supplies the Return-Path identity and DKIM signing domain, while the service manages the associated records. Start by identifying the Customer Org, sending account, actual From domain and campaign or API route. A domain present somewhere in the organization is not enough: the assignment that applies to this message must be known. MessageGears custom authentication.
Build a small inventory of business workflows before requesting a change. Separate scheduled newsletters, triggered account messages and any application using a different account ID. Retain a baseline message from each active route where available. Assign a campaign owner to validate the intended brand, a DNS owner to review the delegation and a service operator who can coordinate activation with support. This avoids a common migration error: preparing one domain while a production job continues sending from another account.
Request the supported delegation and assignment
Choose an unused subdomain under a domain the organization controls. Send MessageGears support the Customer Org name or ID, chosen subdomain and intended assignment. For a Default authentication domain, specify the account IDs; for a Dynamic domain, identify the From domain. The documented process supplies four NS values, followed by support verification, internal setup and assignment. Default domains belong to accounts; organization-level Dynamic mappings can override the Default when the From domain matches. Delegation and assignment workflow.
Treat this request as an operational handoff with explicit acceptance criteria. Ask support to identify which From domains, accounts and message types the assignment covers, whether any legacy configuration must remain during transition, and how to reverse the assignment if the first controlled sends fail. Preserve the issued nameservers in the restricted change record. Do not substitute another customer's values or delegate the organization's entire DNS zone when only a child subdomain is required.
The DNS owner should inspect the proposed child's existing records and uses before publishing the NS set. A name that looks unused in the marketing dashboard may already serve a website, tracking destination or another vendor. Delegating that name changes who answers for the child namespace. Escalate any conflict before proceeding, and keep a record of the previous authority and intended new authority.
Separate provider examples from the actual SPF requirement
MessageGears' general authentication page publishes an SPF example containing include:_spf.messagegears.net and directs customers to support for custom DKIM. Use that page to understand the service, not as an instruction to replace a domain's current SPF policy wholesale. In a delegated arrangement, first identify the actual envelope domain and who manages its policy. Adding an include to the visible From domain cannot repair SPF at a different evaluated domain. MessageGears authentication overview.
If support separately requests an SPF change at a customer-managed owner name, preserve the legitimate senders already authorized there and publish only one applicable SPF record. Review the complete lookup path, including nested includes, before approving the edit. Multiple TXT records at one name are allowed for unrelated purposes, but multiple SPF policies are not a valid way to combine senders. SPF specification.
Do not use the API's OnBehalfOf setting as a substitute for aligned authentication. MessageGears describes it as an advanced feature that sets the Sender header for older mechanisms. The visible From address, envelope identity and DKIM signing domain still require their own evaluation. OnBehalfOf reference.
Inspect delegation before relying on campaign delivery
After publication, query the child NS delegation through public DNS and query the issued authoritative servers directly. Save the owner names, answers, TTLs, server queried and timestamp. Ask support to confirm that its internal assignment is complete before treating DNS publication as activation. Check that the resulting DKIM selector resolves to the expected public key or supported chain and that SPF resolves at the envelope domain actually used.
Keep tracking tests separate from authentication tests. A working HTTPS link establishes neither a valid DKIM signature nor DMARC alignment. Conversely, authentication can pass while a tracking redirect is broken. In the acceptance checklist, give message authentication, branded links, bounce handling and reply behavior their own rows. Use harmless content and controlled recipients; a production audience is not a diagnostic tool.
Prove the Default and Dynamic routes independently
The following is an original verification design, not an executed result. Send one controlled message through each relevant production-style workflow. When Dynamic mappings are in use, include a message whose From domain should select the Dynamic mapping and another that should remain on the account Default. Record the actual account and template identifiers so a reviewer can distinguish an assignment mistake from a DNS problem.
For every received message, capture the visible From domain, Return-Path, trusted receiver SPF identity and result, all DKIM d= and s= values with their results, and the receiver's DMARC result. Compare the passing authentication domain with the From domain under the effective alignment mode. A sibling or child domain may qualify under relaxed alignment without satisfying strict equality. A valid provider-domain signature alone is not proof that the customer's From domain aligns. DKIM specification and DMARC specification.
If one account passes and another fails, examine the assignment before changing shared DNS. If authentication passes but alignment fails, investigate the selected identity rather than broadening SPF indiscriminately. Preserve the current DMARC policy during diagnosis. A domain-wide relaxation can affect mail unrelated to MessageGears and should not be the default recovery step.
Close the change with explicit evidence limits
Keep the support confirmation, authoritative DNS captures, controlled-message evidence and recovery decision together. Roll back only the affected assignment or records under an approved plan, allowing for DNS caches and messages already in flight. Do not remove old authentication keys until their remaining use and retirement timing are understood.
This candidate is supported by current public MessageGears documentation, but no customer account, live delegation or received message was inspected. Production readiness remains on hold for account-specific instructions, authoritative before-and-after DNS, route-specific live-message proof and human SME review. The original implementation scope is not closed merely because a documented setup path exists; customer-specific acceptance evidence is still required.