eTrigue SPF, DKIM and DMARC setup, step by step

To authenticate eTrigue DemandCenter campaign email, review the documented SPF authorization include:etrgmail.com, obtain your domain’s DKIM configuration from eTrigue Customer Success, and verify a newly delivered campaign message. eTrigue also documents a separate custom mail-domain setup that requires DNS work and provider-side completion. Publishing _dmarc alone does not complete that account configuration. eTrigue SPF and DKIM, eTrigue DMARC setup.

This guide concerns DemandCenter campaigns sent through eTrigue infrastructure, not an employee’s regular mailbox or an unverified third-party integration. No customer support request, account configuration, DNS change or email test was performed.

Establish the campaign’s sending identities

Record the approved From addresses used by your campaigns, the DemandCenter account, the DNS administrator and the account owner who can coordinate with Customer Success. Inventory other legitimate senders before editing shared DNS records. A campaign platform and a staff mailbox can display the same domain while using different mail routes.

Three domains need to be distinguished:

The signing selector is the signature’s s= value. It helps locate the public key; it is not a domain or an SPF permission. DKIM validates a signature over message data, not an IP allowlist. SPF identity, DKIM identifiers and keys.

Agree on a small controlled acceptance campaign and a pause or recovery plan. Do not use a large scheduled campaign as the first test of a new domain or signing configuration.

Add the documented SPF authorization safely

The provider’s SPF instructions identify this mechanism, inserted before the final all in an existing policy:

include:etrgmail.com

The page also offers a static IP alternative. Prefer the maintained include for the documented route unless your current account instructions require something else; do not freeze an address range from an old article or add both approaches without a reason. eTrigue directs account-specific IP questions to Customer Success. Official SPF setup and verification.

For a fictional owner with one existing sender, the merge could look like this. The documentation-range address below must not be used as a production authorization:

Before: v=spf1 ip4:192.0.2.20 -all
After: v=spf1 ip4:192.0.2.20 include:etrgmail.com -all

Do not replace a real policy with this example. Preserve staff mail, applications and other approved senders in one applicable SPF TXT record at each owner. Keep the approved all qualifier. SPF ignores redirect= whenever any all mechanism is present, irrespective of ordering; mechanisms after all are unreachable. Preserve the approved qualifier and do not add an all that disables an existing redirected policy. Qualifiers specify SPF outcomes, not guaranteed delivery or rejection. RFC 7208 section 5.1. The provider’s downloadable SPF notes likewise emphasize retaining existing sending sources rather than creating another SPF policy.

Evaluate the actual envelope domain. Updating example.com does not automatically authorize mail using be.example.com; SPF policies do not inherit from a parent domain. Conversely, an apex include does not make an unrelated provider envelope align with your visible From domain. The support-enabled mail-domain flow below addresses a different part of the configuration.

SPF permits no more than ten DNS-lookup terms during evaluation, counting relevant nested processing. This includes more than just include: a, mx, ptr, exists and redirect also matter. An over-budget policy or multiple selected SPF records can produce permerror. Review dependencies before publishing rather than deleting other active senders to make room. SPF record selection and lookup limits.

Request DKIM values and activation instructions

The official guide directs DKIM setup requests to success@etrigue.com, with the subject DKIM Setup Request. Its lookup example uses selector etrigue, but the actual public value and activation details must come from the configuration for your domain. eTrigue DKIM instructions.

Have the authorized account owner request or confirm:

• Which DemandCenter account and sending domain the change covers.
• The intended DKIM d= signing domain and current selector.
• The complete DNS owner, record type, public value or target and any TTL guidance.
• Whether another verification record is required.
• Who enables signing after DNS is visible and how activation is confirmed.
• How future rotation and retirement of the old key will be handled.
• Whether the custom mail-domain procedure in the next section applies to this account.

These are the details needed to implement and test the configuration, not claims that every account has a particular self-service button. Do not guess a key from the selector, create your own unrelated key pair or send account credentials with a request.

For a confirmed d=example.com; s=etrigue, the key lookup owner would be etrigue._domainkey.example.com. If either value differs, the lookup owner differs too. Do not republish another customer’s TXT key or CNAME target. Only public DNS material belongs in DNS; the signing private key must remain private. DKIM key retrieval.

Complete the provider’s custom mail-domain procedure

The current eTrigue DMARC help page documents a mail subdomain named be, an A record pointing to 199.187.170.200, and an SPF policy on that subdomain. It then requires contacting success@etrigue.com with the subject DMARC Request for account-side completion. Obtain confirmation that this procedure and hostname apply to your account before changing DNS. eTrigue’s full DMARC workflow.

For the illustrative sending domain example.com, its documented record pattern is:

Owner: be.example.com
Type: A
Value: 199.187.170.200

Owner: be.example.com
Type: TXT
Value: v=spf1 mx include:etrgmail.com -all

The DNS and mail owners must approve the destination IP and resulting routing before publishing this A/TXT pair. Compare it with the authorized routing plan and preserve existing address and mail dependencies. A current support packet is not itself permission to redirect a hostname.

These provider-documented values are conditional configuration instructions, not proof that be.example.com is available or that your account already uses it. Do not add the A record at example.com itself or put the subdomain SPF policy at _dmarc.example.com. Ask the provider to confirm the full owner when your From domain is itself a subdomain.

Before creating be, check its A, AAAA, CNAME, MX, TXT and NS records and identify any application using it. An existing service or delegation is a stop-and-reconcile condition. Do not overwrite its address, create a CNAME alongside the requested A/TXT data or assume you can choose a different label without eTrigue’s agreement. If the owner already has an SPF policy, merge only after resolving ownership and intended use.

The mx mechanism above is part of this specifically documented mail-domain recipe. It is not a reason to add mx to unrelated SPF policies or to change the organization’s inbound MX routing. A DNS A record alone neither enables DKIM nor proves the envelope sender has switched.

After the records are verified, the account owner must complete the provider handoff and obtain confirmation. Then inspect a new message’s actual envelope identity. “Enable DMARC” in this support workflow refers to eTrigue account setup; receivers evaluate your domain’s published DMARC policy independently. There is no global DMARC switch that a vendor flips for every message using your domain.

Use exact DNS owners and preserve working records

Map the issued names to the authoritative zone before entry. These examples illustrate naming, not account-generated values:

If _domainkey.mail.example.com is separately delegated, the full owner etrigue._domainkey.mail.example.com has relative owner etrigue at that authority. Preserve its NS delegation, other selectors and DNSSEC configuration.

Use the delegated child’s DNS service when delegation exists. Verify whether the console accepts full names or appends its zone automatically. Avoid an accidental doubled suffix. Keep unrelated selectors, domain-ownership TXT records and MX records intact.

A CNAME cannot coexist with ordinary A or TXT records at the same owner. If support issues a CNAME-based setup, use its exact target and resolve conflicts before publishing; the DNS standard does not allow using a TXT key as a CNAME value. DNS alias behavior.

Only if your current support-issued configuration requires a CNAME: For a required literal authentication CNAME in Cloudflare, use DNS only, turn the applicable per-record Flatten option off when available, and ensure CNAME flattening for all CNAME records does not conceal that alias. Coordinate any shared-zone setting change with affected owners rather than disabling it globally without review. DNS-only alone is insufficient. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the setting. If mandatory behavior or shared dependencies prevent the required literal CNAME answer, stop and coordinate a supported configuration; do not invent a switch or delete NS delegations. Cloudflare CNAME verification, flattening controls. Do not replace the documented be A/TXT pattern or a supplied TXT key with an invented CNAME.

For TXT values, multiple character strings in one resource record can represent one long value. Do not truncate a DKIM key or split an SPF policy into several separate records to accommodate a DNS editor. DKIM TXT string concatenation.

Preserve DMARC policy and review aggregate reports

DMARC requires either a passing SPF result aligned with the visible From domain or a passing aligned DKIM signature. Both are useful operationally, but both are not required for protocol DMARC pass. Relaxed alignment permits the same organizational domain; strict aspf=s or adkim=s requires the exact domain. Thus an envelope such as be.example.com can align with From example.com under relaxed SPF alignment but not under strict SPF alignment. Current DMARC alignment rules.

Find the effective policy for the actual From domain and its applicable parent. Keep an established policy and reporting destination intact. Do not replace quarantine or reject with none to make an unfinished DemandCenter setup appear usable.

Only with domain-owner approval, no direct or applicable inherited policy, and an appropriate monitored rollout, a DNS administrator might adapt this example:

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

For _dmarc.example.com, use relative owner _dmarc in example.com; the child mapping above applies only to an approved child policy. Replace only the mailbox address after mailto: with the approved reporting mailbox. When the Organizational Domain of the report destination host differs from that of the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization for the destination. Destinations within the same Organizational Domain are excepted; a different hostname alone does not trigger that requirement. DNS authorization does not replace the domain owner’s approval of the recipient and report-data sharing. RFC 9990 section 4. Aggregate reports help identify sources, failures and changes over time; they do not certify individual inbox delivery. Assign a reviewer, include other legitimate senders in the rollout and investigate unexplained failures before increasing enforcement. No forensic-report address is needed for the examples in this guide.

For a fictional From: news@example.com, a passing intended signature with d=mail.example.com aligns in relaxed mode (assuming the same Organizational Domain), but not strict mode. A passing d=example.com matches exactly under both modes. These illustrate comparison, not measured provider defaults. Do not accept a rewritten provider-owned From as successful authentication of the intended brand. DMARC alignment.

See raw DKIM results versus aligned DKIM results when a signature passes without authenticating the intended visible identity.

Verify DNS and a delivered DemandCenter campaign

Replace every illustrative domain, selector and server below with the confirmed configuration. Use the authoritative server for the actual owner, including a delegated child when applicable.

dig +short NS example.com
dig @ns1.example.net etrigue._domainkey.example.com TXT +noall +answer
dig +short TXT etrigue._domainkey.example.com
dig +short A be.example.com
dig +short TXT be.example.com
dig +short TXT _dmarc.example.com

Query CNAME and its eventual key target if the issued DKIM configuration uses an alias. Compare the full public answer with the provider’s instructions, not just the presence of some TXT data. Check the actual envelope domain’s SPF and its nested dependencies. Record timestamps and TTLs. Empty answers, NXDOMAIN, SERVFAIL and mismatched key material are unresolved findings, not successful verification.

After provider activation, send the agreed harmless-content controlled campaign to a valid mailbox your team controls through DemandCenter itself and retain the original at the receiver. Inspect the receiver’s trusted Authentication-Results, not merely a header supplied by the sending application. Authentication-Results trust boundary. Establish provenance through the receiving service’s documented or administrator-confirmed processing boundary, including how externally supplied Authentication-Results fields are removed or isolated from trusted results, or use an authenticated receiver trace. A display label alone is not proof. Leave acceptance open when origin or external-header handling is uncertain. A familiar authserv-id name or a header’s position alone does not establish that trust; both can mislead when untrusted results are retained. RFC 8601: forged authentication headers.

Acceptance requires:

1. The expected account, campaign route and visible From domain.
2. A passing signature from the intended branded DKIM domain, with the expected selector and alignment under the effective adkim setting.
3. A trusted dmarc=pass for the visible From domain.
4. The actual smtp.mailfrom domain and its SPF result, recorded independently from alignment.
5. Investigation of real SPF fail, softfail, neutral, none, temperror or permerror, even if DKIM supplies the DMARC pass.
6. Correct reply handling and provider-side confirmation for any custom mail-domain change.

For example, SPF pass on an unrelated provider domain and DKIM pass with d=example.com can yield DMARC pass for From example.com. This is an illustration, not a claim about eTrigue’s default envelope. If only the unrelated provider signature passes, custom branded DKIM is not accepted. If SPF alone supplies DMARC pass while the intended DKIM signature fails, this DKIM implementation is still incomplete.

Troubleshoot by evidence, not by adding permissions

The selector resolves but DKIM is absent. Confirm the exact From domain, current selector and support activation. A public key can exist without the corresponding signer being enabled.

The custom mail domain is published but Return-Path has not changed. Check completion of the DMARC Request workflow and obtain a newly generated campaign sample. Repeatedly adding apex SPF permissions does not activate account routing.

SPF returns permerror. Check multiple policies, invalid syntax, include/redirect loops and the recursive lookup budget. Preserve valid senders while repairing the defective policy.

DKIM passes but DMARC fails. Inspect which signature passed and its relationship to From. Check strict alignment and policy discovery. Do not confuse an unexpected provider-domain signature with the requested branded signature.

A forwarded copy fails SPF. Compare a direct-delivery sample first. Forwarding changes the connecting sender and can break SPF; preserve the DKIM and receiver results rather than broadening SPF to every possible forwarder.

Authentication passes but delivery is poor. Examine the specific bounce or rejection, suppression state, permission to contact recipients, list quality and reputation. Authentication does not guarantee inbox placement.