DirectIQ SPF, DKIM and DMARC setup, step by step

To authenticate a DirectIQ marketing sending domain, open Settings → Senders & Domains, add the domain, publish its current DNS records, and select Verify domain. The current documented setup shows three CNAME records for sending, click tracking and DKIM, plus a DMARC TXT record. It does not supply a standalone SPF TXT include. Verify your sender email address separately, then check authentication and alignment on a delivered campaign. DirectIQ domain setup, sender-address verification.

Which DirectIQ sending workflow does this cover?

This guide covers DirectIQ marketing campaigns using a domain you control. It explains domain connection, DKIM-related DNS, SPF validation, DMARC and sender-address ownership. It does not configure employee mailboxes or establish the authentication behavior of every DirectIQ transport.

DirectIQ also documents a separate Transactional Email API. A successful marketing campaign test does not prove that an application using that API emits the same envelope domain or DKIM signature. Validate that route separately using its current account instructions and a real transactional message. DirectIQ transactional email.

Before starting, have access to DirectIQ's domain and sender settings, the sending mailbox, and the DNS provider authoritative for your domain. Save the existing DNS records and identify who owns any current mail, tracking or DKIM setup. Public help pages do not establish the permissions or entitlement of your particular account.

What DNS records does DirectIQ currently show?

Its displayed update age is relative, not a fixed publication date. Use the names and values generated for your domain, not a copied screenshot.

The illustration uses labels such as sender, link and vip._domainkey. Those labels are examples, not permission to assume your selector or copy every destination. In particular, its demonstration domain is directiq.com, so its sending owner and target appear identical. Do not create a CNAME pointing back to itself. If your own account presents an apparent self-reference, ask DirectIQ to confirm the correct record before publishing. Current official DNS illustration.

The fourth record is DMARC, not SPF. Avoid turning the four-record checklist into an invented SPF recipe.

1. Add the sending domain and copy its records

1. Open Settings → Senders & Domains.
2. Find Sending domains and choose Add Domain. If you reach the connected-domain list first, choose Add Domain there.
3. Enter the domain you intend to use and select Continue.
4. Copy each current DNS owner, record type and value from the custom DNS settings dialog.
5. Compare the requested owners with the existing DNS zone before making changes.

To return to an existing domain's settings, use its manage/pencil control. The current article uses Continue, Verify domain and Re-Check records; older instructions with different navigation should not override the settings shown for your account. DirectIQ connection procedure.

Use the exact sending domain, not just whichever domain happens to host your website. If campaigns use different From domains, document and verify each applicable configuration.

2. Publish the records without disrupting other services

Make changes at the authoritative DNS service. A registrar may manage registration while another provider hosts DNS. If a subdomain is delegated to different nameservers, its records belong in that delegated zone.

For each record:

• Use the correct owner format. A DNS panel managing example.com may expect vip._domainkey, while another expects vip._domainkey.example.com. Check the resulting full name to avoid example.com.example.com suffix duplication.
• Use a hostname as a CNAME destination. Do not add https://, a path or an email address. Follow your DNS host's rules for a final dot in a zone-file editor.
• Preserve the CNAME response. Use DNS-only publication for authentication aliases. Do not enable an HTTP proxy or flatten a required CNAME into address records. For tracking records, follow DirectIQ's supported configuration rather than placing an unverified proxy in front of it.
• Resolve conflicts deliberately. An ordinary CNAME owner cannot also hold independent TXT, MX, A or AAAA data. Do not delete a working record just to satisfy the new form. Determine its dependency and agree on a supported alternative with DirectIQ. DNS CNAME rules.
• Keep unrelated records. Do not replace inbound MX records, other services' DKIM selectors or employee-mail SPF as part of this setup.

For Cloudflare, set required aliases to DNS only. Where available, leave each record’s Flatten option off and check that CNAME flattening for all CNAME records is off; the zone-wide setting overrides per-record choices. Coordinate shared-setting changes with the DNS owner first, then query actual CNAME answers. If mandatory apex or same-zone-target behavior prevents the required literal CNAME answer, stop and coordinate a supported hostname/design with DirectIQ and the DNS owner; do not invent a switch. Cloudflare proxy behavior, Cloudflare flattening controls.

Preserve legitimate NS delegation for child zones, including _domainkey, and their DNSSEC records. Publish each selector in the zone actually authoritative for it, coordinating with that zone’s operator. For a hypothetical full owner ISSUED_SELECTOR._domainkey.news.example.com, use ISSUED_SELECTOR._domainkey.news in the parent example.com zone, ISSUED_SELECTOR._domainkey in a separately delegated news.example.com zone, or ISSUED_SELECTOR in a delegated _domainkey.news.example.com zone. These naming examples are not issued records. Do not remove delegation merely to add a record in the parent. If a delegation conflicts with the requested CNAME owner, obtain a supported alternative. DNS-host delegation guidance.

A DKIM CNAME lets the service manage the key at its target. Do not generate your own replacement key or add a competing DKIM TXT at the CNAME owner. The published public key must match the private key actually used to sign your messages. DKIM key lookup.

3. Handle SPF according to the actual envelope domain

There is no universal DirectIQ SPF include established by the current domain-connection instructions. Follow the current account-generated records rather than adding a guessed include to your root SPF policy.

SPF evaluates the sending IP against the domain in the SMTP envelope sender, normally recorded as smtp.mailfrom in the receiving system's authentication results. For a null reverse-path, SPF uses the HELO identity. The visible From address and a click-tracking domain are different identities. DirectIQ's reviewed documentation does not specify the exact emitted MAIL FROM/Return-Path for this workflow. The label sender in a DNS example is not proof of what that value will be. SPF identities.

After an authorized campaign test, identify the domain the receiver actually evaluated. If it belongs to DirectIQ, investigate its SPF result with DirectIQ rather than broadening an unrelated customer-root policy. If it is your domain, check the policy or managed DNS chain at that exact owner. SPF does not automatically inherit the apex domain's record.

If DirectIQ gives account-specific instructions requiring an SPF TXT change, reconcile those instructions with the existing policy:

• Maintain one v=spf1 TXT policy at that owner, not a second competing SPF record.
• Preserve every legitimate sender and the intended final all mechanism.
• Assess the full evaluation against SPF's maximum of ten DNS-querying terms, including nested include and redirect processing. a, mx, ptr and exists also consume that budget; counting only the includes visible in the first record is insufficient.
• Do not replace a maintained provider include with a hand-copied snapshot of its IP addresses.

Any all mechanism makes redirect ineffective: SPF ignores the redirect when all is present. Preserve the existing qualifiers and redirected authorization design; do not add all while merging without understanding that change. Qualifiers do not guarantee delivery or rejection. SPF redirect rule.

These are SPF safety rules, not an instruction to modify SPF when your DirectIQ configuration does not request it. SPF publication and limits.

4. Preserve DMARC policy and verify alignment

DirectIQ's illustrated TXT value is v=DMARC1; p=none. Treat that as a starter example, not a command to downgrade an existing quarantine or reject policy or remove reporting destinations. Publish only one DMARC policy record at a given owner.

For a visible From domain of news.example.com, first inspect _dmarc.news.example.com. If no valid direct policy exists, an applicable policy may be discovered through the DNS tree walk, including the organizational domain. Review inherited subdomain policy as well as direct records. An explicit new p=none at the sending subdomain can weaken protection that previously came from the parent. Current DMARC policy discovery.

DMARC passes when at least one mechanism both passes authentication and aligns with the visible From domain:

• DKIM: compare the passing signature's d= domain with the From domain.
• SPF: compare the passing MAIL FROM domain with the From domain.
• Relaxed alignment: the domains share the organizational domain determined by DMARC discovery.
• Strict alignment: adkim=s or aspf=s requires exact equality for that mechanism.

For a hypothetical From news.example.com, an intended passing signature with d=example.com aligns in relaxed mode but not strict mode. A passing d=news.example.com exactly matches that From in either mode. These are illustrative identity comparisons, not measured delivery results. For help interpreting results, see EmailAuth's raw DKIM results versus aligned DKIM policy results.

A provider-domain SPF pass is not automatically aligned, and a passing DKIM signature from an unrelated domain is not sufficient. DMARC alignment.

Use only approved report recipients and review their access and retention arrangements. Aggregate reports expose sending IP addresses, domains, message counts and authentication outcomes. The external-authorization test in RFC 9990 compares the organizational domain of the domain from which the policy was retrieved with the organizational domain of the reporting URI’s host. Different hostnames under the same organizational domain do not alone trigger that test; when those organizational domains differ, the report-generating receiver must check that the report destination has authorized the relationship in DNS. This protocol authorization is separate from the domain owner's decision to share the report data. For example, a policy retrieved for example.com pointing to reports@reports.example.net is authorized at example.com._report._dmarc.reports.example.net, normally with a TXT containing v=DMARC1. That record belongs to the report receiver, not an arbitrary location in your sending zone. External reporting authorization.

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

Type: TXT
Full owner: _dmarc.news.example.com
Value: v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX

Replace the example domain and substitute the approved mailbox address only after mailto:. For that child policy, use relative _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. For a root policy at _dmarc.example.com, use _dmarc in the example.com zone. This conditional example does not override existing policy or account requirements.

If DirectIQ rejects a valid established policy, investigate the checker result with support. Do not weaken policy merely to reproduce the screenshot.

5. Verify the domain and the sender address separately

After publishing the records, return to the domain dialog and complete the displayed confirmation step, then select Verify domain. Successful checks change from red to green. Re-Check records lets you repeat pending checks. DirectIQ's text allows up to 24 hours for DNS changes, but waiting will not repair a wrong name, target or authoritative zone. Domain verification.

Next, verify the mailbox used as your campaign sender:

1. Open Settings → Senders & Domains → Senders.
2. Select Add Sender.
3. Enter the sender's email address and name, then Continue.
4. Retrieve the code sent to that mailbox, enter it and select Verify.
5. Confirm that the sender no longer shows Pending.

Changing the sender email address requires verification of the new address. Domain DNS verification does not prove mailbox ownership, and mailbox verification does not prove DKIM or DMARC success. DirectIQ sender procedure.

6. Check public DNS and an actual delivered campaign

Confirm the published DNS answers

Use the precise names copied from DirectIQ. The commands below are illustrative; replace the sample names before running them.

dig +short NS example.com
dig +short CNAME sender.example.com
dig +short CNAME link.example.com
dig +short CNAME vip._domainkey.example.com
dig +short TXT vip._domainkey.example.com
dig +short TXT _dmarc.example.com

Check each CNAME against the account's destination. A recursive TXT query for the DKIM owner should follow its alias chain to the public-key TXT. Query the target directly if necessary. Compare authoritative answers with recursive answers to distinguish incorrect publication from cached data; for delegated subdomains, use their actual authoritative servers. Use your real DMARC owner, including the sending subdomain where applicable.

Confirm receiver authentication

After the domain and sender are verified and your team authorizes a test, send a representative marketing campaign to a mailbox you control. Inspect the original message there. Use receiver-controlled authentication diagnostics, or have the receiving mail administrator establish that its trust boundary strips or clearly distinguishes externally supplied Authentication-Results before relying on the result. A familiar authserv-id or header position alone does not establish provenance. Authentication-Results trust boundary.

Record:

1. The visible From domain and the expected DirectIQ campaign route.
2. The actual smtp.mailfrom identity and SPF result.
3. Each DKIM signature's d= and s= values, and the receiver's result for the relevant signature.
4. Whether the intended customer-domain signature passes and aligns under the applicable adkim mode.
5. dmarc=pass for the intended header.from, with the aligned passing mechanism identified.

Use the delivered s= and d= to look up selector._domainkey.signing-domain; do not keep testing an illustrative selector if the message uses another one. A DMARC pass through SPF alone does not finish the intended branded-DKIM task. A rewritten provider From is not successful authentication of the intended brand. Investigate SPF fail as a sender-authorization/route issue, permerror as policy syntax, duplicates or lookup-budget failure, and temperror as a temporary DNS/resolver issue, even if aligned DKIM supplies DMARC pass. Repeat for materially different From domains and sending routes.

Troubleshooting DirectIQ authentication

For a support case, provide the domain, failing DNS owner, expected target, observed result and a redacted message sample with relevant authentication headers. Do not send passwords or API secrets.