MessageGears SPF, DKIM and DMARC setup, step by step

MessageGears currently recommends authenticating a dedicated subdomain through DNS delegation. Request the setup from MessageGears Support, publish the four NS values it issues, and wait for its team to complete and assign the authentication domain. The resulting subdomain supplies the return-path and DKIM signing identity. Adding an SPF include alone does not complete this workflow. MessageGears custom authentication.

Decide which MessageGears traffic you are authenticating

This guide covers email delivered through MessageGears, including Accelerator and API sending. It does not configure your employee mailbox provider, your data warehouse, or the DNS service hosting your company's main website. The application that prepares an audience is not necessarily the server that delivers its messages. Record the actual outbound route before changing DNS. MessageGears email authentication overview.

For employee mailbox mail sent separately through Microsoft 365, use the Microsoft 365 authentication guide. MessageGears delegation does not replace that tenant’s DKIM or authorize moving employee-mail routing.

Build a small inventory with one row per production stream:

Accelerator Sending Profiles store From Name, From Address and Reply-To, and each profile belongs to a selected account. Check the profile actually used by the template or campaign. Editing Reply-To does not change the domain DMARC evaluates. Sending Profile fields and account association.

Request the correct authentication-domain assignment

MessageGears distinguishes an account-level Default/Custom authentication domain from an organization-level Dynamic domain. A matching Dynamic configuration overrides the account default according to the From domain. Each account still needs a default. Assignment behavior.

Send Support the customer organization name or ID, chosen unused subdomain, and either the account IDs for Default/Custom setup or the From domain for Dynamic setup. Keep their response with the DNS change request. After publication, confirm completion with Support; its team checks the records, performs internal setup and testing, and assigns the domain. The same documentation describes secure tracking beneath the delegated subdomain, commonly prefixed with trk.

For your own change record, ask for the expected return-path domain, DKIM signing domain, selectors to check, and the accounts or From-domain mappings being enabled. These are useful acceptance details, not additional public DNS records to invent.

A practical test matrix matters more than a single successful campaign. Suppose two brands share one organization and three accounts. Test a message for each intended brand/account combination, including a From domain that should use the default rather than a Dynamic override. A wrongly assigned but technically valid signing domain can be missed if you test only the first account.

Delegate an unused subdomain without moving the whole domain

Choose a name such as mg.example.com only after checking that it has no existing website, mail, application or delegation dependency. The four NS targets must come from the current MessageGears request. Do not borrow nameservers from another customer or a screenshot. Current four-NS workflow.

The following is a planning worksheet, not a record set to paste:

Parent zone: example.com
Delegated owner: mg.example.com
Record type: NS
Record values: the complete set of four nameservers issued for this setup

Publish the NS set at the chosen child name in the authoritative parent zone. In a DNS editor that appends example.com, the host field may need mg; in an editor expecting a fully qualified name, it needs mg.example.com. Inspect the saved owner to prevent mg.example.com.example.com.

Do not replace the registrar's nameservers for example.com. That would move authority for the whole domain, not just the intended child. Delegation creates a zone boundary: records beneath it must be served by the delegated authorities. Adding a DKIM TXT record below that boundary only in the parent zone is not a substitute for publishing it in the child zone. DNS zones and delegation.

Before approving the change, export affected DNS records and document the previous state. Check for an existing CNAME, NS delegation or child-zone DNSSEC configuration. Do not delete an active service to make the new name fit. Choose another unused subdomain or arrange a planned migration. If DNSSEC is involved, have the DNS administrator coordinate the child delegation and any DS records rather than disabling protection across the parent domain.

Delegating a child gives its operator control over that child's DNS. Keep that authority narrowly scoped, track ownership and include decommissioning in the service's offboarding plan. This is a meaningful authorization decision even though it leaves the parent zone with your existing DNS host.

Before publication or activation, compare the exact delegated owner and all four issued NS targets with the domain owner’s separately approved delegation plan. A support packet alone is not authorization. Verify the complete approved set at the authoritative parent and through recursive resolution, and check every delegated authority as below. Preserve unrelated mailbox routes and dependencies.

Understand SPF and DKIM ownership after delegation

MessageGears' general authentication documentation publishes this SPF example:

v=spf1 include:_spf.messagegears.net -all

It is an authorization pattern, not a command to replace your root-domain policy. The specific custom-authentication workflow uses delegation so MessageGears can maintain the child zone's SPF and DKIM records. If an existing, nondelegated arrangement needs a manual change, obtain confirmation of its exact record owner and supported procedure from Support first. General SPF example, delegated record management.

SPF normally evaluates the envelope MAIL FROM domain, reported as smtp.mailfrom and usually visible in Return-Path, rather than the visible From address. A parent SPF policy does not automatically authorize its subdomains. At any manually managed owner, retain one v=spf1 policy, preserve legitimate senders and the approved terminal mechanism, and check the ten DNS-querying-term limit across nested includes. Do not concatenate complete policies or add a second SPF record. SPF identity and record rules.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

For DKIM, the sending service holds the private signing key. Public DNS exposes a verification key at the selector and signing domain used by the message. Never publish a private key or generate an unrelated pair to replace the provider's configuration. The useful question after setup is whether the intended signature verifies, not whether a guessed selector returns some TXT data. DKIM signing and verification.

Existing customers may have older manual records. Do not remove them merely because today's recommended workflow is delegated. Confirm which selectors and domains are still in production before planning any transition.

Check DMARC alignment before changing policy

For an illustrative message with From updates@example.com, a return-path at mg.example.com and DKIM d=mg.example.com, both identifiers can align under relaxed DMARC alignment because they share the organizational domain example.com. Neither is an exact match for strict alignment with example.com. Check aspf and adkim in the effective policy rather than assuming that a branded subdomain satisfies every policy. DMARC needs at least one passing, aligned SPF or DKIM result. DMARC alignment.

If strict alignment is intentional, resolve the From/authentication-domain design with the email-security owner and MessageGears. Do not silently weaken the policy or move the visible From address without considering replies, account mappings and other sending systems.

Preserve existing DMARC enforcement and reporting. Only if no direct or applicable inherited policy exists and the owner approves a monitored rollout, this illustrates an initial policy for a domain you control:

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com: _dmarc.news relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and reporting mailbox with approved values. Publish only one DMARC policy at that owner. p=none does not ask receivers to quarantine or reject failures, and it does not guarantee delivery. Check the effective policy for every visible From domain, including relevant parent/subdomain behavior. DMARC policy specification.

Aggregate reports help compare MessageGears with your other legitimate senders before stronger enforcement. A third-party rua destination may need external reporting authorization maintained by the report recipient. Do not copy a reporting address from another organization. DMARC aggregate reporting. For a consolidated sender review, EmailAuth can help organize authentication and alignment evidence; provider assignment and real-message checks still need to be completed.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS, then verify an actual MessageGears message

The commands below are read-only examples for your administrator. Replace example.com, mg.example.com, NS_FROM_SUPPORT and SELECTOR_FROM_MESSAGE; no customer DNS was queried for this guide.

dig +short NS example.com
dig +trace NS mg.example.com
dig @NS_FROM_SUPPORT mg.example.com SOA +norecurse
dig +noall +answer mg.example.com TXT
dig +noall +answer SELECTOR_FROM_MESSAGE._domainkey.mg.example.com TXT
dig +noall +answer _dmarc.example.com TXT

Interpret the results in order:

1. The parent delegation should lead to the complete issued NS set, not an old DNS host. Check every issued server, not only one.
2. Each delegated authority should answer for the child zone. A referral without working child authority is not a completed setup.
3. The SPF record at the actual envelope domain must be usable. A TXT lookup alone does not evaluate a sending IP or count every nested SPF term.
4. Query the exact DKIM owner constructed from the message's s= and d= values. A different selector's success says nothing about this signature.
5. Confirm that the effective DMARC policy and reporting destination match the approved configuration.

After Support confirms assignment, an authorized operator should send through the real Accelerator campaign or API route to a controlled mailbox. Save the raw message and the trusted receiving service's Authentication-Results. Do not use an ordinary employee-mailbox send as the substitute. Receiver authentication-result semantics.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Accept the configuration only when the evidence supports all relevant checks:

• The expected account and visible From address were used.
• The intended branded DKIM signature passes, with the expected header.d and selector, and that signing domain aligns with From under the effective adkim mode. An unrelated signature or SPF-only DMARC pass does not complete branded DKIM setup.
• SPF passes for the actual smtp.mailfrom. Investigate fail, softfail, none, neutral, temperror or permerror, even if aligned DKIM already makes DMARC pass.
• DMARC passes for the visible From domain under the actual alignment policy.
• The return-path reflects the intended authentication domain; any configured tracking links and reply handling behave as planned.

Keep account-level and Dynamic-domain cases separately in the acceptance record. A green DNS lookup or Support's setup confirmation is useful evidence, but neither proves every production stream uses the new identity.

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Troubleshoot the failing layer

For a Support case, include the organization, account, From domain, intended authentication domain, timestamp, message identifier and redacted authentication results. Keep complete raw messages privately for diagnosis; remove recipient data and tokens from material shared outside the authorized support process.

Documentation and verification limits

This is a documentary configuration guide. No MessageGears account was changed, no support request was submitted, no DNS records were modified and no test email was sent. Account-generated values, domain assignment, live DNS and delivered-message behavior remain implementation checks for your team.