Dialog Insight SPF, DKIM and DMARC setup, step by step

To authenticate Dialog Insight email, first choose who will manage the sending domain's DNS. With subdomain delegation, Dialog Insight supplies four NS records and configures SPF, DKIM, DMARC and the custom sending/tracking domains. With self-management, you validate your domains, configure the sender's DKIM and the tracking subdomain, then obtain the required Mail-From DNS records from Dialog Insight support. Do not replace either process with a generic SPF include. Delegated setup and self-managed setup

This guide covers the platform's documented sending-domain configuration, including custom tracking, Mail-From and reply handling. It does not configure a separate corporate mailbox system or assume that a shared-IP account and a dedicated-IP account have interchangeable DNS values.

Employee mail through Microsoft 365 is a separate route; use the Microsoft 365 authentication guide for that service rather than assuming these campaign records configure it.

No customer account was configured, DNS changed or test email sent for this guide. The verification steps below are work for an authorized implementation, not completed results.

Identify the four domains before choosing a route

Dialog Insight separates the public sender identity from the technical envelope and web identities. Write down which name serves each purpose before asking anyone to change DNS.

The current official description uses in-mta before the sender domain for the Mail-From domain, such as in-mta.example.com for From addresses at example.com. The private DKIM signing key stays with Dialog Insight; the corresponding public key is made available through DNS. The actual DKIM signing domain must be checked separately from Mail-From. Domains and email authentication

A landing-page subdomain is optional and has its own web/certificate configuration. A working landing page or tracker does not demonstrate that a message's DKIM signature passes.

Prerequisites and the ownership decision

Have the account owner, authoritative DNS administrator and campaign owner agree on the From domain, tracking name and reply destination. Inventory existing records and dependent services, including mailboxes, websites and previous senders. Keep a copy of the current zone and the approved DMARC policy.

Choose delegation when the organization is willing to give Dialog Insight DNS authority over a dedicated child namespace. Choose self-management when your team must retain that authority and can maintain the required records and tracking security settings. Do not delegate the company's whole root domain as a shortcut.

The provider's delegated route starts with shared IP addresses. A dedicated IP requires further instructions. Check the actual account arrangement before approving a cutover; this guide does not supply a fixed IP list or assert plan-specific availability. Delegation results and dedicated-IP note

Route A: delegate a dedicated sending subdomain

1. Choose a subdomain reserved for these mailings and links. Dialog Insight illustrates a name like c.example.com; the letter is an example, not a mandatory label.
2. Choose an existing generic mailbox to receive customer replies. In this route, Dialog Insight forwards replies to the supplied return address. Use a real monitored inbox, not the sending address or a personal mailbox.
3. Give Dialog Insight support the chosen subdomain under its Sub-Domain Delegation process. Confirm that your DNS host accepts child NS records.
4. Obtain the four exact NS entries from support, publish them at the approved child owner in its parent zone, and notify support when they are present.
5. Wait for Dialog Insight to complete its side, then obtain confirmation of the resulting sender, DKIM, Mail-From, tracking and DMARC configuration. Official subdomain-delegation procedure

What delegation changes

If the child is c.example.com, its delegation belongs at owner c in the example.com parent zone. Do not replace the root domain's nameservers or add the supplied NS entries as though they applied to every domain in the account. After delegation, authoritative data inside c.example.com comes from the child's nameservers. Old DKIM or DMARC records below that boundary in the parent editor are not a substitute for publishing in the child zone. How DNS divides authority

Delegation affects more than email authentication. Before applying it, account for every existing hostname below that child, arrange any needed migration and agree on a recovery plan. If DNSSEC is in use, have the DNS administrator coordinate the delegation and DS records; an inconsistent chain can cause validation failures.

Before publication, the DNS owner must approve the exact four child NS targets and the affected namespace and services, separately from receiving support's packet. Obtain the mail owner's approval for the exact forwarding destination as well. A support-supplied address is not automatic permission to route replies there; keep root nameservers and unrelated inbound mail unchanged.

Ask the provider what DMARC policy will be created in the delegated namespace and where reports will go. Do not approve a weaker child policy without assessing its effect on protection previously inherited from the parent. Test reply forwarding separately after implementation. A correctly signed outbound message says nothing about whether a customer's reply reaches the intended team.

Route B: retain DNS control and configure domains yourself

The current self-managed workflow requires a sender domain, custom trackers subdomain and Mail-From domain. It is not complete after publishing only a DKIM key.

1. Add each domain or subdomain in Domain management. Select its entry in Domains to validate and use Validate, completing the ownership instructions supplied there.
2. In Sender domains, add the validated From domain and complete the supplied DKIM setup. Copy its exact record type, complete selector owner and public value or target. Do not invent a selector or generate an unrelated key pair.
3. Under Custom domains → Custom trackers, add the validated tracking subdomain. Choose Custom Trackers in the dialog and complete its DNS, SSL certificate and HSTS requirements.
4. After the sender and tracker are configured, request the Mail-From DNS entries from support@dialoginsight.com. Publish the exact records supplied for your account and complete any requested verification.
5. Manage DMARC with your DNS team. On this route Dialog Insight explicitly leaves policy publication to you. A custom landing-page domain is optional and limited to one per project. Self-managed domain procedure

Treat the support-provided Mail-From record list as a required input, not a gap to fill with a guessed SPF record. The public guide establishes the process but does not provide a universal selector, public key, DNS target or sending-IP authorization for every account. Keep the complete issued record set with the change request. Ask support to resolve a conflict between existing DNS and its proposed owner before replacing data.

If support issues Mail-From MX records, retain each exact full owner, numeric priority and target. These belong at the issued owner, not automatically at the root domain. Do not replace the company's existing inbound-mail MX records. If no MX record is issued, do not invent one or add it beside a CNAME.

Have the routing owner approve the complete resulting MX set for each issued owner, separately from accepting the support packet. Before activation, compare the full owner, all numeric priorities and all targets at authoritative DNS and a recursive resolver with that approved set. Stop if any expected entry is missing, any unexpected entry remains, or a destination is unapproved. Do not infer a universal MX set when support supplies none.

Once configured, confirm that the intended sender domain is allowed for the account and that the campaign actually selects it. Do not stop at ownership validation: proving control of a domain and enabling a correctly signed sending route are different steps.

SPF configuration and alignment: inspect Mail-From

SPF evaluates the connecting sender against the envelope's MAIL FROM domain. For the documented in-mta.example.com route, that is the identity to inspect, rather than automatically checking only the SPF record at example.com. The root policy does not automatically apply to child SPF domains. Dialog Insight's envelope explanation and SPF identity rules

The following is an alignment example, not a captured message:

Visible From domain: example.com
MAIL FROM domain: in-mta.example.com
DKIM d= domain: example.com

If SPF passes:
 SPF aligns with aspf=r, assuming example.com is the organizational domain.
 SPF does not align with aspf=s because the domain names are different.

If the branded DKIM signature passes:
 DKIM aligns with either adkim=r or adkim=s in this example.

For a From domain of news.example.com, use the exact Mail-From identity issued for that domain, not an assumption that all senders use in-mta.example.com. Evaluate the receiver's actual smtp.mailfrom and DKIM d= values under the domain's policy. A provider-owned or otherwise unrelated envelope can pass SPF but fail alignment; a passing aligned DKIM signature can still make DMARC pass. DMARC alignment

If support instructs you to amend an SPF TXT policy, update the one policy at the exact specified owner. Preserve other authorized senders and the intended terminal mechanism. Do not create a second v=spf1 record, copy stale IPs or add an include after all. Count recursive DNS-query-causing terms against SPF's ten-term limit. SPF publication and evaluation

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed redesign. SPF qualifiers describe authentication results, not guaranteed receiver delivery or rejection decisions. SPF all and redirect processing.

Safe owner names for root and child domains

Translate a provider-issued full owner according to the zone actually being edited. The examples below use placeholders rather than deployable provider records.

If the panel wants a full name, provide the full name instead. Verify the saved result to catch suffix duplication. @ refers to the open zone's apex. For a CNAME issued by the provider, keep the supplied target as a DNS alias, without an HTTP proxy. A CNAME owner cannot also retain ordinary A, AAAA, MX or TXT data. Preserve unrelated TXT records and other providers' selectors. DNS aliases

Keep any issued authentication and Mail-From CNAMEs unflattened: public DNS must return their exact aliases, not substituted IP addresses. In Cloudflare, DNS only is necessary but insufficient. Check that each issued CNAME has Flatten turned off. Cloudflare CNAME verification

For the applicable issued aliases, ensure zone-wide settings do not suppress the literal CNAME. Cloudflare's flatten-all setting cannot be overridden per record; apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting. If mandatory apex/same-zone behavior or a shared configuration prevents the required answer, stop and coordinate a supported configuration with the DNS owner and Dialog Insight. Do not disable a shared setting blindly or remove an existing delegation. Cloudflare flattening controls

Preserve legitimate child-domain NS delegation. Publish and check the records at the child's authority, working with Dialog Insight where it operates that zone. Do not delete a valid delegation to make a record in the parent editor appear to work.

If _domainkey.news.example.com itself is delegated, the full owner SELECTOR._domainkey.news.example.com is relative SELECTOR in that delegated zone. Preserve its NS records and active selectors. A full-name field takes the complete issued name; adding it beneath an existing delegation in the parent does not publish it at the active authority. DNS authority boundaries.

DMARC policy and reporting without weakening protection

Check the exact From domain's DMARC record and the policy inherited through DMARC discovery where relevant. Preserve existing p, subdomain-policy settings, alignment modes and reporting destinations unless their owner approves a change. Do not replace an established policy with a tutorial's p=none sample. DMARC discovery and policy

Only if no direct or applicable inherited policy exists, and the owner approves an appropriate monitoring plan, a first-policy example is:

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

Replace the domain and mailbox with real, approved values. The full owner _dmarc.example.com is relative _dmarc in zone example.com; use the child mappings above when appropriate. p=none requests no DMARC-specific quarantine or rejection; it neither guarantees delivery nor requests reports by itself. The rua destination requests aggregate reports. Keep one DMARC policy per policy owner, and avoid failure reporting without a privacy decision.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the report receiver's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

On a delegated subdomain, agree these settings with Dialog Insight because its nameservers administer that child. On a self-managed domain, the DNS team publishes them. Review observed sources, volume and alignment over representative traffic before tightening enforcement; validate other platforms using the same From domain as well.

Verify authoritative DNS and provider activation

The following commands are diagnostic templates. Replace every uppercase placeholder; use the correct parent and child nameservers rather than assuming one server answers for all records.

# Delegated route: verify the referral and the child authority.
dig @PARENT_NS DELEGATED_CHILD NS +noall +answer +authority
dig @CHILD_NS DELEGATED_CHILD SOA +noall +answer

# Both routes: inspect the actual issued records and effective policies.
dig @OWNER_AUTH_NS DKIM_OWNER RECORD_TYPE +noall +answer
dig @OWNER_AUTH_NS MAIL_FROM_OWNER RECORD_TYPE +noall +answer
dig @OWNER_AUTH_NS DMARC_OWNER TXT +noall +answer
dig DKIM_OWNER TXT +noall +answer
dig MAIL_FROM_DOMAIN TXT +noall +answer
dig DMARC_OWNER TXT +noall +answer

# Only if the issued Mail-From record set includes MX:
dig @OWNER_AUTH_NS ISSUED_MAIL_FROM_MX_OWNER MX +noall +answer
dig ISSUED_MAIL_FROM_MX_OWNER MX +noall +answer

RECORD_TYPE means the type Dialog Insight actually supplied, not a guess. If it is CNAME, inspect the exact alias first, then resolve its target's relevant data through recursive DNS. For DKIM, the final public key must correspond to the issued selector and signing domain. For SPF, inspect the policy actually reached for the envelope domain. For delegation, compare all four NS targets with support's list and confirm that the child answers authoritatively.

For an issued Mail-From MX record, accept the answer only when its full owner, numeric priority and target match support's record list. Check every issued MX entry, without assuming a priority or using the company's inbound-mail MX as a substitute. Keep the existing corporate MX configuration intact; these conditional queries do not imply that every account needs an MX change. MX record fields

Compare authoritative answers with public recursive results. A stale cache can explain a temporary difference after a correct change; it cannot explain away an absent record at the authoritative server. Once DNS is correct, confirm the application's validation and support-side completion separately. Certificate and tracking checks are additional operational checks, not substitutes for message authentication.

Prove branded DKIM on a delivered message

Use an authorized, harmless test through the real campaign route to an external mailbox you control. Inspect the raw original and the final receiving service's trusted Authentication-Results. Do not accept a sender-inserted header as proof. Trusting authentication results

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain receiver-controlled diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

Accept the authentication setup only when:

• The visible From is the intended address and domain.
• The intended branded DKIM signature reports pass, and its d= domain aligns with From under the applicable policy. Retain the s= selector. A pass for an unrelated vendor signature is insufficient.
• SPF passes on the direct sending route for the actual smtp.mailfrom identity. Record alignment separately; an unaligned pass is different from a failed SPF check.
• DMARC reports pass for the intended From domain, with a passing aligned mechanism that explains that result.
• Tracking links use the intended hostname and work, and a test reply reaches the chosen mailbox where reply forwarding is part of the setup.

The protocol permits DMARC to pass with only one aligned mechanism, but that does not complete a requested DKIM implementation if branded signing is missing. Likewise, do not dismiss spf=permerror, temperror or an authorization failure just because DKIM saved DMARC. Repeat acceptance for different sender domains and materially different sending paths. Keep redacted headers, DNS answers, provider confirmation and the test time together.

Troubleshooting by layer

If everything authenticates but messages still land in spam, investigate sender reputation, content, recipient consent and receiver filtering. Authentication is not an inbox guarantee.