Netigate SPF, DKIM and DMARC setup, step by step

To authenticate a custom survey sender in Netigate, an administrator adds the sending domain under Account Settings > Custom Domain, opens View details, and publishes the account’s required DNS records. All required statuses must verify before accepting the new route. Verification is also an operational change: Netigate routes new sendouts whose sender domain matches a verified domain through Mailgun. It is not merely a harmless DNS check. Netigate custom-domain setup and routing explanation.

This guide covers native Netigate survey email using an approved dedicated sending subdomain, with an existing approved receiving-mail arrangement and an administrator authorized to configure it. It does not configure legacy Postfix sending, move corporate mailboxes, change an API integration or create a separate Mailgun account. The actual Netigate-issued owners, types and values take precedence over examples.

Confirm the product and the scope of the change

Netigate’s documentation still labels this workflow Netigate Feedback. Its package guide identifies Feedback as the former name of the Surveys package and lists Custom Domains across Surveys, Results, Light Insights and Insights. It also warns that legacy contracts and packages may differ. Check that your existing account has the documented feature; do not assume that a missing control calls for a purchase or a privilege change.

Only administrators can create or edit a custom domain. Choose a dedicated sender such as surveys.example.com only if the organization owns it, has approved that use, and has provisioned the intended sender mailbox and receiving service. The example is not an instruction to create a domain or mailbox without approval.

Before proceeding, record:

• The exact sending subdomain, approved visible From address and Netigate account.
• Existing DNS records, delegated namespaces, direct and inherited DMARC policy, and the authoritative DNS service.
• The receiving-mail owner’s approved MX destinations and a working mailbox for replies.
• Any existing UI sendouts, scheduled distributions, reminders or API integrations using that same sender domain.
• The owner’s approval for the resulting Mailgun routing change, DNS publication and any account-issued CNAME routing or tracking dependency.
• A controlled, non-sensitive survey and test recipient, separate from live respondent lists.

Do not start by replacing the main domain’s SPF or MX. A subdomain separates DNS administration and sender identity, but it does not guarantee independent reputation or eliminate every shared-domain effect.

Approve automatic routing before publishing DNS

Netigate’s Postfix-to-Mailgun article explains that the sender address’s domain determines the route when a sendout is created. A verified domain uses Mailgun; an unverified sender can still use the legacy Postfix route. This applies to both API and interface-created sendouts.

Verifying a domain already used by an integration can therefore move new matching sendouts to Mailgun without changing the integration’s sender parameter. Obtain approval from the owners of those integrations and distributions before publishing the DNS that can complete verification. Do not assume a later manual signing switch will protect an unapproved route change.

For a newly selected child domain, existing senders on the parent do not become child-domain senders automatically. This walkthrough tests only the intended native interface route. Changing API sender parameters, migrating existing campaigns or altering scheduled distributions is a separate, approved task. If you cannot establish which existing sends will be affected, stop before publication and resolve that inventory with the account owner.

The setup article’s broad statement that only verified domains can send and the migration article’s description of legacy unverified Postfix sends have different scopes. Here, verification is required for the new custom-domain Mailgun route. The legacy exception is not a workaround for incomplete authentication.

Decide how replies will be received

Since 2026, Netigate requires at least one MX record for each newly added domain or subdomain. Previously verified domains do not automatically need a change, but re-verifying a changed domain brings it under the new requirement. A child sender domain needs its own receiving configuration; do not assume the parent’s MX is sufficient.

Netigate accepts either your own mail service’s MX records or its provided MX records. There is a crucial difference: Netigate says its provided MX has no inbox behind it. Replies are discarded without a bounce or failure notice. A respondent may believe their reply reached you when it did not. Official MX requirements and warning.

For this guide, retain the approved receiving service and an actual mailbox for the intended sender address. Have the mail administrator confirm the exact domain is provisioned there; merely copying a parent domain’s MX values does not create a mailbox. Preserve valid existing priorities and destinations. Do not replace working corporate MX, add a competing receiving route or use the discard-only alternative just to turn a status green. Choosing to discard replies would require a separate explicit operational decision and is outside this walkthrough.

Obtain the exact account-issued DNS packet

1. As the authorized administrator, open Account Settings > Custom Domain.
2. Select Add Domain, enter the approved exact sending domain, check it carefully and select Save.
3. Use the three-dot menu beside that domain and select View details.
4. Record every displayed owner, record type, value or target, MX priority where applicable, and verification status. Keep this packet with the approved change record.
5. Compare it with existing authoritative DNS and the approved receiving and DMARC plans before publishing anything.

The current prose documents SPF, DKIM, DMARC, CNAME and MX requirements but does not justify a universal selector, record count or target. Do not copy a screenshot’s tenant values, invent a mailgun selector or configure a separate Mailgun dashboard. If your displayed record purpose or destination is unclear, obtain clarification before publishing it.

The setup documentation requires SPF, DKIM and CNAME values to match the displayed configuration, while allowing an appropriate existing or chosen DMARC and MX configuration. These alternatives are not permission to omit required checks.

Publish SPF without confusing verification with validity

Netigate explicitly checks the published SPF policy for include:mailgun.org. Its recommended example for an otherwise isolated, Mailgun-only sending subdomain is:

v=spf1 include:mailgun.org ~all

This is a conditional example, not an instruction to overwrite an existing policy or change its qualifier. Reconcile the actual account packet with the domain’s authorized senders. Keep exactly one v=spf1 policy at the evaluated owner, with all still-required authorizations and its approved terminating policy. Do not add a second SPF TXT record.

A dynamic SPF service can authorize a sender through valid macro-based processing while failing Netigate’s literal published-entry check. That is a limitation of this documented Netigate verifier, not proof that SPF macros are invalid. Do not disable the corporate SPF service or copy legacy Postfix instructions to satisfy this new route. The dedicated approved subdomain avoids casually rewriting the parent’s design.

SPF checks the SMTP MAIL FROM domain, not automatically the visible From address. A child envelope domain does not inherit its parent’s SPF. During acceptance, record the actual envelope identity and check its policy rather than assuming it equals the entered sender domain.

The protocol limit is ten evaluated DNS-dependent terms, including nested processing, not ten visible includes or a guaranteed fixed number consumed by Mailgun. An all mechanism makes redirect ineffective regardless of placement. Preserve an existing redirect design rather than appending ineffective terms after all. A lookup permerror is a permanent SPF error, not the same result as having no SPF policy. SPF specification.

Netigate expressly warns that a domain can verify even when its SPF record exceeds the lookup limit. Check the resulting policy independently. A green Netigate status cannot override an invalid SPF result, and SPF softfail does not by itself dictate a recipient’s spam-folder decision.

Publish DKIM and CNAME records without breaking other services

At the authoritative DNS host, translate Netigate’s full owners into the host’s required input format. Some panels append the zone name automatically. Confirm the final full DNS name so that a child label or _domainkey owner is neither duplicated nor placed at the parent by mistake.

For example, an issued owner SELECTOR._domainkey.surveys.example.com maps to SELECTOR._domainkey.surveys in the parent example.com zone, to SELECTOR._domainkey in a separately delegated surveys.example.com zone, or to SELECTOR if _domainkey.surveys.example.com itself is delegated. Use the actual authority and issued selector. Preserve the delegation’s NS records and shared active selectors; do not remove a delegation just to publish in a convenient parent-zone panel.

For a public-key TXT record, retain the complete issued value and its tags. DNS TXT string splitting must preserve the complete logical record. Never publish a private key. For a CNAME, use the exact issued target, not a guessed provider suffix. DKIM record specification.

Check each owner for existing TXT, CNAME, MX or other conflicting records and for delegation. A CNAME cannot simply be added beside other ordinary data at the same owner. Do not delete another signer, website record, receiving route or shared namespace to make the new row fit. Stop and have the responsible owner resolve the conflict.

Required authentication or verification CNAMEs must remain visible as literal DNS aliases to their exact issued targets, not hidden behind a web proxy or replaced only by address answers. For Cloudflare, keep those records DNS-only and inspect per-record, whole-zone, apex and same-zone flattening behavior. Where supported and approved, turn off the relevant per-record Flatten option and ensure applicable zone settings preserve the required CNAME answer. A whole-zone flattening setting cannot necessarily be overridden per record; apex and same-zone behavior may be mandatory. Do not change unrelated zone settings globally. If the required literal answer cannot be preserved, stop and coordinate a supported configuration rather than inventing a switch or deleting shared records. Cloudflare’s actual flattening controls and exceptions.

Required CNAME rows may affect routing or tracking as well as authentication. Do not guess their purpose or publish an unapproved route. Verify the final authoritative and recursive answers, not just the saved panel setting.

Preserve DMARC, including inherited protection

Netigate accepts an inherited DMARC policy. Inspect the direct _dmarc record for the intended From domain and any applicable inherited policy, including child-domain treatment and adkim/aspf modes. Do not add a weaker child override merely because a verifier is slow to display the inherited policy. Preserve enforcement and authorized report recipients. Netigate inheritance guidance.

Only if no direct or applicable inherited policy exists, and the domain owner approves a first monitoring deployment, the initial TXT policy can be:

v=DMARC1; p=none

Its owner is _dmarc.<approved-sending-domain>: for the illustrative sender surveys.example.com, that is _dmarc.surveys.example.com, not _dmarc.example.com. Resolve DNS-host suffix rules before adding it. This example does not enforce rejection or collect reports by itself; arrange an approved monitoring plan. Do not duplicate a DMARC record, weaken an existing policy or introduce obsolete percentage-rollout instructions. Current DMARC specification.

If aggregate reporting is separately approved, the report-generating receiver must check DNS authorization when the destination’s Organizational Domain differs from the Organizational Domain of the domain where the policy was found. A destination within that same Organizational Domain is excepted. This includes inherited-policy cases. DNS authorization does not replace the owner’s permission to share reporting data. Aggregate-report authorization.

Wait for every required verification status

Return to View details and inspect every required status. Netigate documents up to 48 hours after DNS publication, not a guaranteed completion time. A missing or unverified row is not permission to omit it or treat the domain as ready. The prose does not establish a separate manual signing-enable button for this workflow.

Compare public DNS with the exact packet, including full child-domain owners, record types and targets. Confirm the receiving-mail and DMARC alternatives are the approved ones. If a status remains unverified beyond the documented window, check copied values and parent-versus-child placement, then escalate the specific discrepancy to the account’s support contact. Do not rotate keys, delete inherited protection or replace working MX as speculative fixes.

When all statuses verify, remember that matching new sendouts can now select Mailgun. Keep the approved change window and affected integration owners informed. Verification is eligibility evidence, not proof that an actual message has the intended passing signature.

Test the native survey email and its replies

Use an isolated non-sensitive survey with only a controlled recipient you own or have permission to contact. Do not import a production respondent list, trigger a customer reminder or forward another respondent’s personalized survey link. Preserve required unsubscribe behavior. Review automations and all recipients first.

In the documented Email sendout workflow, choose Email, add only the controlled recipient, and set From to the approved mailbox on the verified exact domain. A display name alone is not that address. Keep the survey’s required [[LINK]] token and review the subject, content, scheduling and reminder settings.

Order sendout is a real sending action, not a preview. It can also ask to activate the survey. Netigate says a past scheduled time can cause sending within 5–10 minutes. Obtain specific approval for this isolated test and any required survey activation before ordering it. Do not activate a real customer survey just to test authentication. If you cannot isolate the test safely, stop. A preview or ordered-status circle alone is not delivered-message evidence.

At the controlled receiving service, inspect the original message and results generated inside that service’s known processing boundary. Establish how it handles externally supplied Authentication-Results; header position or a familiar authserv-id string alone does not establish trust. Ignore sender-supplied result fields. Authentication-Results trust boundaries.

Accept the intended branded route only when:

• The visible From is the approved address on the verified Netigate sender domain, not a rewritten provider address.
• The intended Netigate/Mailgun route’s DKIM signature passes, with the expected signing domain d= and selector s= established from the issued configuration and actual message.
• That passing signer aligns with the visible From under the effective DMARC adkim mode.
• The trusted receiver reports dmarc=pass for that intended From domain.

Relaxed alignment means the same Organizational Domain; strict alignment requires an exact domain match. For DKIM compare d= with From under adkim; for SPF compare the authenticated MAIL FROM domain with From under aspf. DMARC can pass through either aligned SPF or aligned DKIM, but an SPF-only pass or unrelated passing signature does not prove this DKIM setup. See raw DKIM results versus aligned policy results.

Record SPF separately and resolve errors at its actual envelope owner. Then send an approved non-sensitive reply and verify receipt in the intended mailbox. Authentication success does not prove replies are received, and inbox placement is not guaranteed. Retain only necessary diagnostic evidence, not customer content or credentials.

Troubleshooting