Choose the business identity before changing DNS
EngageLab Email has both custom-domain sending and a hosted shared-domain route. Those are different identity choices, not interchangeable shortcuts. Decide whether recipients must see your organization's domain. A successful test from a provider-owned address does not demonstrate that your business domain is authenticated. Record the exact application, visible sender address and message type before opening DNS settings.
The Send Settings documentation describes an initial test domain, a separate shared-domain feature and custom business domains. Its shared route uses a subdomain of base.engagelab.com, with the visible address on that hosted namespace. For business-domain rollout, use the custom-domain workflow. Do not treat the service's claims about shared reputation or free quotas as a delivery guarantee or a contractual entitlement. Confirm commercial limits separately.
Capture the domain-specific configuration
In Setting, domain, create or select the sending domain and obtain its current DNS instructions. EngageLab lists SPF, DKIM and MX as required, with DMARC optional for its validation states. Unverified means a required check is missing; Usable means the required checks pass; Verified means all displayed checks pass. These labels describe product validation, not a received-message verdict.
Have the DNS owner review the entire proposed record set before publication. An MX change affects inbound routing at its owner name. If the proposed name already receives staff mail, pause and resolve the collision rather than replacing its mail exchangers. A dedicated sending namespace can reduce collisions, but its suitability must be confirmed against the actual account configuration. Record the owner name, type, value, TTL, old value and reason for every change.
The Domain API documentation exposes SPF, DKIM, MX and DMARC configuration values and per-record verification results. It is useful for cross-checking what the account expects, not as a source of reusable sample credentials or DNS keys. Copy values from your own domain object. Never reuse the example domain's public key, assume its selector applies to you, or adopt its sample reject policy without reviewing your other legitimate mail streams.
Publish without replacing unrelated permissions
At the authoritative DNS host, add the exact required record types and owner names. DNS panels differ in whether they append the zone name, so inspect the resulting fully qualified name. A misplaced selector can leave a plausible-looking record that receivers never query. Preserve complete key data and avoid adding other data at a CNAME owner.
Where SPF already exists, reconcile the new authorization into that single SPF policy. Do not create a second v=spf1 policy at the same name. Evaluate the combined policy's DNS-lookup dependencies rather than merely counting visible includes. Keep active senders and the established final qualifier unless the domain owner has separately approved a change. None of these steps authorizes broadening permissions to unrelated mail services.
Query authoritative records and compare them with the saved account instructions. Then rerun EngageLab validation after caches have had time to expire. The documentation's estimated DNS delay is not a universal deadline. A wrong authoritative answer will not repair itself by waiting. If the platform and authoritative responses disagree, preserve both with timestamps before troubleshooting resolver caching.
Bind the application to the intended route
EngageLab also instructs users to use different sending domains with different primary domains for trigger and bulk mail, to keep bulk restrictions from delaying trigger messages. Confirm this separation with the account owner before binding the API_USER routes; two subdomains of the same primary domain do not meet that stated instruction. Record the approved domain for each message type.
The documented API_USER setup associates a sending domain and a trigger or batch message type. Verify that the application uses the intended association. Testing one credential while production uses another can produce a misleading green result. Keep secrets in approved secret storage, not this evidence record, screenshots or support attachments.
Create a small route worksheet: application, environment, API or SMTP transport, message type, bound domain, visible From address, owner and rollback route. Test the production-equivalent code path with controlled recipients. Do not infer that a preview, test account or unrelated application proves the integration. For time-sensitive transactional mail, explicitly test the trigger workflow rather than relying on a successful bulk campaign.
Prove alignment with a received message
Retain the original received message and trusted receiver Authentication-Results. Record From, envelope domain, every DKIM d= and s= value, SPF result, DKIM result and DMARC result. SPF authenticates the envelope domain; DKIM authenticates its signing domain. DMARC needs at least one passing authenticated path aligned with the visible From domain under the applicable mode. Authentication does not guarantee inbox placement.
Synthetic reasoning example, not an EngageLab default: From receipts@example.com, envelope bounce@other.example.net and a passing signature with d=example.com. SPF for other.example.net does not align with example.com, but the signature supplies exact DKIM alignment. If that signature is absent or invalid, the assumed DMARC pass is unsupported. Write the identities alongside the verdicts so that a bare word such as pass cannot conceal the wrong domain.
Close the change and preserve recovery
If verification fails, isolate whether the problem is DNS, domain association or message signing. Restore the known-good application route rather than weakening the whole domain's DMARC policy. Do not delete keys still used by queued messages. After success, retain the approved DNS diff, account validation, route worksheet and message evidence, and schedule a repeat check after a transport or domain change.
This is a documentary configuration guide. No EngageLab tenant was changed, no production DNS was measured and no real received-message identity table was collected for this draft. The checks above are acceptance work for the operator, not claimed results. Human approval and a route-specific test remain necessary before production rollout.
Resolve a domain binding mismatch before release
Written case EL-01 assumes the console marks notify.example.com Usable, while the production trigger application remains bound to a hosted shared-domain API_USER. Its intended From is receipts@notify.example.com; the actual From, envelope identity and signature results have not been collected. The usable DNS state cannot prove the intended application identity. The application owner must reconcile the bound domain and trigger type with the approved route before a harmless controlled receipt test. Do not create credentials or change MX merely to make the worksheet green. No API call, secret, DNS edit or message was executed.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.