For Mapp Engage native email using a dedicated delegated sending subdomain, the domain administrator delegates that approved child zone to Mapp, verifies the nameserver answers and notifies the Mapp representative. Mapp provisions authentication for the system. Before sending, confirm that provisioning is complete, use an exactly registered group From domain, and validate the intended aligned DKIM signature on a real controlled campaign message.
This is a representative-assisted delegation workflow, not a universal SPF include or a self-service “Enable DKIM” recipe. It does not cover historical BlueHornet instructions, Empower, Mapp Intelligence, external SMTP, or a manually managed nondelegated additional domain. Corporate succession does not make an older product’s DNS records interchangeable with current Engage settings.
No customer delegation, support outreach, account configuration or sending was performed.
On this page: Define the scope with the domain owner and Mapp · Delegate only the approved child zone · Verify nameservers, then notify the representative · Obtain the provisioning details needed for acceptance · Check SPF at the actual envelope domain · Use an exactly registered From in the group · Accept only the actual native campaign result · Troubleshooting and change control · Frequently asked questions
Define the scope with the domain owner and Mapp
Mapp’s sender-domain overview requires a configured, verified and authenticated sending domain before productive sendouts. Its DKIM documentation says DKIM is configured during initial system setup, while its SPF documentation directs configuration questions to the customer-service representative.
Choose an unused, dedicated sending subdomain such as news.example.com, with the domain owner’s explicit approval. That reserved example is not a required product value. Agree the exact child zone, native Engage system, intended From domain and supported routing with the Mapp representative before changing DNS.
Delegation transfers DNS authority for the child zone to Mapp. It is not merely a TXT verification token. The owner must understand and approve the authority transfer and the mail, web, tracking or other routing that Mapp will provision inside that child. Compare the proposed destinations and purpose with the authorized routing plan; do not activate an unapproved route just because it appears in a provider packet.
Save existing child-zone records, parent delegation, relevant TTLs and any active dependencies. Review direct and inherited DMARC protection before provisioning. A previously unused subdomain may still inherit policy from its Organizational Domain; “no direct DMARC record” does not mean “no applicable protection.” Preserve existing approved report destinations.
You need the parent zone’s DNS administrator, a Mapp representative and appropriate Engage system/group permissions. Mapp’s roles documentation explains that effective permissions combine system and group roles. Do not assume one universal administrator role or grant broader access just to follow this guide.
Delegate only the approved child zone
The official Delegate a Domain procedure specifies three nameserver targets:
ns1.shortest-route.com.
ns2.shortest-route.de.
ns3.shortest-route.com.
Confirm those targets and the exact child with your representative. In the authoritative parent zone, create the approved child’s NS delegation. For an illustrative news.example.com child under an example.com parent, the zone-file shape is:
news.example.com. IN NS ns1.shortest-route.com.
news.example.com. IN NS ns2.shortest-route.de.
news.example.com. IN NS ns3.shortest-route.com.
Replace the example owner with the approved child. A DNS editor using relative names in the parent zone may expect news; one accepting full names may expect news.example.com.. Check how the editor appends the zone and treats trailing dots so neither owner nor target acquires a duplicated suffix.
Do not change the registrar’s nameservers for example.com, replace the parent’s NS records, or move the root domain to Mapp. The procedure grants authority only for the specifically approved subzone. An A record or CNAME pointing at Mapp does not create that DNS delegation.
If the chosen child already hosts a website, mailbox, alias, delegation or another service, stop for a dependency review. Prefer an unused approved subdomain rather than deleting an existing A record or replacing live NS blindly. Preserve _domainkey delegations and active selectors elsewhere. If the child has DNSSEC or DS dependencies, have the DNS administrator coordinate a supported delegation plan; do not disable security or leave an invalid chain as an authentication shortcut.
This guide does not configure alternative record-pointing, CDN or WAF arrangements. Mapp’s delegation documentation distinguishes those from the supported direct-delegation route and warns about their additional complexity. Do not conceal a failed delegation behind an improvised proxy or alias.
Verify nameservers, then notify the representative
Verify the actual child’s NS answers from the parent’s authoritative delegation and from recursive DNS. The response must correspond to the approved Mapp targets. Resolve missing nameservers, doubled suffixes, stale delegation or unexpected targets before proceeding.
A diagnostic query for the reserved example is:
dig NS news.example.com
Use your approved child instead. A cached recursive result alone is not enough to diagnose a conflicting parent delegation; compare it with the authoritative configuration and inspect any DNS errors. Respect the relevant positive or negative cache TTLs rather than promising a fixed propagation interval.
Mapp explicitly instructs customers to notify their representative after successful delegation. Provide the approved child and the public validation findings through the established support channel. Do not include credentials or private keys. The guide is not permission for an assistant or administrator to send an unapproved message on someone else’s behalf.
Nameserver resolution is not completion of SPF/DKIM provisioning. Obtain confirmation that Mapp has configured and registered the intended domain for this Engage system and completed its authentication setup before a productive sendout. There is no universal self-service activation switch or guaranteed completion time established by these sources.
Obtain the provisioning details needed for acceptance
Ask the representative to confirm the actual:
- Registered sending domain and permitted group From domain for this system.
- DKIM signing domain, selector and public DNS owner used by the native route.
- SMTP MAIL FROM or envelope domain and its SPF authorization.
- Intended mail and other service routing within the delegated child.
- Applicable DMARC policy, including how existing inherited protection and approved reporting destinations are preserved.
- Completion of authentication provisioning and readiness for the approved controlled test.
Mapp controls DNS within the delegated child. Do not duplicate child TXT records into an inactive parent-zone copy or generate a separate private/public key pair locally. Obtain the account’s actual public evidence rather than inventing selectors, keys, Return-Path patterns or a universal include.
Compare the public DKIM owner and complete value with the representative’s packet. A key lookup normally uses SELECTOR._domainkey.SIGNING-DOMAIN; the actual d= may differ from the Engage system domain. If _domainkey is itself delegated, validate through the authoritative namespace without removing that delegation. Long TXT values may be split into quoted character strings within one record; their concatenated public value must remain complete. Do not confuse those strings with multiple independent key records or publish private key material.
The current DKIM page describes both delegated system domains and associated main domains, while the domain-verification page warns against assuming a parent domain is authorized. The safe rule for this guide is use the exactly registered delegated child. An associated apex or another domain requires explicit representative registration and valid DKIM configuration; sharing an Organizational Domain is not product authorization.
Check SPF at the actual envelope domain
SPF authenticates the SMTP MAIL FROM domain, or HELO in the applicable null-reverse-path case, not automatically the visible From address. Confirm the actual evaluated domain and provider-managed policy rather than adding a guessed authorization at the root domain.
A child’s SPF is separate from its parent’s SPF. Adding a policy at example.com does not automatically authorize an envelope at news.example.com or a deeper bounce domain. Conversely, a provider-controlled envelope’s SPF pass does not establish alignment with your visible From.
For this delegated workflow, have Mapp confirm its published SPF configuration. If a legitimate shared sender requires changes at an owner under the delegation, coordinate the exact policy with Mapp and the domain owner. Do not edit an inactive parent copy or replace existing authorizations with an old literal IP range found in a general verification article.
The published policy should have one v=spf1 TXT record per evaluated owner. Preserve legitimate senders and approved qualifiers. Necessary mechanisms must be reachable before a terminating all; adding a second policy or an include after all does not solve authorization. An all mechanism anywhere in a policy causes redirect= to be ignored, so redirected policies require deliberate integration.
Validate the ten evaluated DNS-dependent term budget, including nested mechanisms and redirects, not just ten top-level includes. These rules follow RFC 7208. A final qualifier describes an SPF result, not a guaranteed delivery or rejection outcome.
Mapp documents Message Check as an SPF preflight. Use it before sendout, but retain the actual DNS and receiver checks: a successful preflight does not prove the intended DKIM signature survives the real campaign path.
Use an exactly registered From in the group
Open Audience → Group Management → Groups → Change Settings → Reply Handling, as documented in Group Creation: Reply Handling.
The From choices include:
| Choice | Authentication check before use |
|---|---|
| Defined Address | Enter the approved address. Email is mandatory; display Name is optional. Its domain must be registered for the system. |
| Message Author | Confirm the author address resolves to the approved registered domain, rather than assuming the user’s login identity is suitable. |
| Name and Email of the Group | Confirm the group’s predefined email uses the approved registered domain. |
For the most explicit test, use the agreed address on the registered child, such as newsletter@news.example.com with your actual approved domain substituted. A display name or Reply-To does not authenticate the visible From domain.
The domain-verification page describes an orange triangle near the email field and a sendout status warning for an unauthorized domain. Resolve the warning with the representative or use a properly registered address; do not bypass it by copying a generic SPF policy. The absence of a warning is still not proof of passing aligned DKIM.
The SPF documentation says a group’s domain cannot be edited after creation. Do not invent a rename or delete-and-recreate workaround. If the wrong domain is bound to an existing group, agree a supported correction with the administrator and representative while preserving recipients and operational settings.
Although the tab is named Reply Handling, this authentication task does not require changes to reply forwarding, IMAP storage, unsubscription, deletion or event automation. Those settings can redirect or delete messages and affect contacts. Leave them unchanged unless separately authorized.
Accept only the actual native campaign result
After the representative confirms provisioning and preflight checks succeed, obtain permission for a controlled native group campaign to a valid recipient owned or approved for the test. Use non-sensitive content and the intended From domain. Do not send to the production audience or import customer data merely to validate authentication.
Use Authentication-Results produced inside the receiving service’s known processing boundary, following its documented treatment of externally supplied result fields. A familiar authserv-id, favorable pass string or header position alone is not proof of receiver origin. Ignore attacker-supplied results and ask the receiving administrator if provenance is uncertain. See RFC 8601.
Acceptance requires:
- The visible From remains the intended registered branded address, not a rewritten provider identity.
- The intended Mapp-generated DKIM signature passes, with the observed
d=ands=matching the confirmed signing setup. - That intended signature aligns with the visible From under the active policy.
- The trusted receiver reports
dmarc=passfor the intended identity. - SPF’s actual result and envelope identity are separately checked and unexpected errors are addressed.
Relaxed alignment means the DKIM signing domain or SPF MAIL FROM domain shares the visible From domain’s Organizational Domain. Strict alignment requires the respective domain to exactly match the visible From domain. A child envelope does not automatically satisfy strict SPF alignment. RFC 9989 defines the distinction.
DMARC can pass with aligned DKIM even when SPF is unaligned. It can also pass through SPF while the intended DKIM signature fails. The latter is not successful DKIM setup. See EmailAuth’s raw DKIM results versus aligned DKIM policy results. Do not treat a registered group From, a DNS key or a clean preflight as interchangeable with this receiver evidence.
Troubleshooting and change control
The child resolves to old nameservers. Check the parent’s delegation, actual authoritative zone, TTLs and exact owner formatting. Do not replace root nameservers or remove unrelated records.
Delegation works but authentication records are missing. Confirm the representative received the completion notice and finished provisioning. Do not generate substitute keys or paste old IP ranges into the parent zone.
The group warns about an unauthorized From. Check the exact domain against the registered system configuration. An apex address is not automatically authorized because a child is delegated. Ask for supported registration rather than bypassing the warning.
DNS is correct but the expected signature is absent or fails. Confirm native campaign routing, representative completion, actual selector and signing domain, and changes to signed headers or body. Investigate before regenerating keys or changing groups.
SPF fails. Compare the real envelope owner and receiver’s connecting IP with Mapp’s confirmed current policy. temperror requires investigation of transient DNS resolution; permerror requires correcting structural issues such as multiple policies or excessive evaluated terms. Diagnose both separately from ordinary failure even if DKIM currently gives DMARC pass.
DMARC fails despite passing authentication. Compare actual identifiers and alignment modes. Preserve inherited and direct protection while fixing the sender. Do not introduce a monitoring override, unapproved report recipient or duplicate policy to hide the error.
A delegation change must be rolled back. Coordinate with Mapp and the domain administrator before restoring anything. Review queued messages, active keys, routing and shared dependencies; removing authority can break more than email authentication. Restore only an approved known-good configuration and repeat DNS and real-message verification.
Authentication does not guarantee acceptance, inbox placement or reputation. Investigate actual recipient responses rather than weakening filtering or promising a propagation deadline.