Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Define the DemandCenter sending boundary
DemandCenter campaign mail originates from eTrigue infrastructure while presenting the configured sender address. The practical task is to authorize that route and establish a passing identity aligned with the organization's visible From domain. It is not enough to confirm that a staff member's ordinary mailbox authenticates: that mailbox may use an entirely different delivery path.
Identify the campaign owner, DNS administrator and person who can coordinate with eTrigue Customer Success. Record the actual DemandCenter account, sending domains, templates and reply handling. Agree on a small controlled campaign for acceptance and a known-good recovery route before changing any existing records. This avoids treating the next large campaign as the first integration test.
Apply current SPF guidance deliberately
References: RFC 7208 §3.2, RFC 7208 §4.6.4.
The first-party setup article specifies include:etrgmail.com for SPF, added before the final all mechanism. It also documents a static-address alternative. Prefer a current provider-confirmed configuration rather than freezing an address range copied from an old example. Ask Customer Success to resolve account-specific uncertainty; do not infer regional addresses from a third-party list.
Take a copy of the existing SPF record and inventory its legitimate senders. Add authorization into the single existing policy where appropriate, rather than publishing another v=spf1 record. Preserve the other active permissions and approved qualifier. Evaluate the complete lookup dependencies, including nested includes. A short-looking record can still exceed the ten-term evaluation budget for include, a, mx, ptr, exists and redirect terms, including nested processing; this is not a raw DNS-packet count.
SPF authorization does not establish that the visible From domain is the identity checked by the receiver. It authorizes the SMTP envelope identity used for that transaction. The message test below determines whether that path aligns with the address recipients see. Do not add increasingly broad permissions in response to an alignment problem that actually needs a different supported identity.
Obtain the DKIM instructions from the provider
References: RFC 6376 §3.6.2.
The eTrigue guide directs organizations to request DKIM setup from success@etrigue.com using the subject DKIM Setup Request. It describes the verification selector as etrigue, but account-specific instructions must govern the actual record. Do not invent the public key or assume that a selector name alone enables signing.
Prepare a support request with the account and sending domain, the intended campaign route, the required record type and full owner name, and a request for confirmation of activation steps. Do not include credentials. This guide does not send that request on your behalf. Have the authorized account owner coordinate it through the organization's approved support process.
When instructions arrive, check the signing domain, selector, DNS owner, public value or target, activation responsibility and expected verification method. Record which party owns key rotation and retirement. A public DNS key can be present while the service is not signing with it; an activation confirmation can exist while DNS points to the wrong name. Require evidence for both halves.
Publish and verify the exact owner names
References: RFC 1034 §3.6.2.
Apply the approved records at the authoritative DNS host. Confirm whether its interface appends the zone automatically. Query the full SPF and DKIM owner names from the authoritative server, then compare recursive results after cache expiry. Preserve old and new record sets with timestamps and TTLs.
If a key is missing, check name duplication, record type, key truncation and selector mismatch before waiting. If there is existing data at a requested CNAME owner, resolve the collision rather than overwrite another service's delegation. Do not rotate or remove an unrelated selector as an improvised fix. Coordinate any replacement with the sending team so queued messages are not needlessly invalidated.
Verify campaign messages and alignment
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Send the agreed controlled campaign through DemandCenter, then retain the received original. Use the receiving system's trusted authentication results, not an untrusted header supplied by the sender. Record visible From, envelope domain, every DKIM d= and s= identity, and the SPF, DKIM and DMARC verdicts. Test reply routing separately if campaign recipients are expected to reply.
Synthetic diagnosis: a campaign claims news@example.com, has SPF pass for a provider-owned unrelated domain, and DKIM pass with d=example.com. The passing aligned DKIM signature can supply the DMARC path even though SPF is unaligned. If the same message instead has only a signature from another unrelated domain, the generic pass labels do not establish DMARC alignment. This is an illustration, not an eTrigue default or customer result.
DKIM authenticates a signing domain and selected message content. It is not an IP allowlist. Avoid carrying over shorthand descriptions that confuse it with SPF. Also separate authentication from inbox placement: a properly authenticated campaign may still be filtered for reputation, consent, content or recipient-specific reasons. Diagnose those only after the identity evidence is clear.
Complete or roll back the campaign change
If DKIM is absent despite correct DNS, compare the actual sending domain and selector with the provider's activation confirmation. If SPF fails, inspect the envelope identity and complete policy evaluation before editing the visible sender's unrelated record. If the route remains unverified, pause the affected campaign rather than weaken the domain's DMARC policy.
Acceptance requires the approved DNS diff, provider configuration instructions, activation evidence and a real received-message identity table. Retain an owner and next review trigger, such as a domain change, key rotation or service migration. On retirement, verify that no active DemandCenter flow depends on the records before removing trust.
No live eTrigue account, DNS or message test was performed for this draft. The support-dependent key and activation details remain account-specific. This source-supported guide explains how to obtain and test them without claiming execution evidence or human approval.