Define the emBlue route before changing DNS
An emBlue Sender, a published key and a received message are three different pieces of evidence. Treat them separately. This guide concerns the emBlue campaign interface documented in its Help Center, not every service carrying a similar brand or every integration connected to an account. The retained public instructions were reviewed on 9 November 2026; they do not establish a particular tenant's current settings, subscription entitlements or outgoing identities.
Start a change record with the account owner, intended From address, business workflow and receiving test mailbox. Record who controls DNS and who can approve changes to domain-wide policy. A campaign preview, an integration-triggered message and a verification email might follow different paths. Choose the workflow that needs authentication and keep other routes outside the acceptance claim until separately inspected.
Separate sender approval from message authentication
The official Sender instructions describe Remitentes y dominios, Agregar remitente, corporate sending and reply addresses, a default Sender choice and an email-verification step. Capture the selected Sender without assuming that its display name, Reply-To address or verification badge establishes DMARC alignment. An authorized administrator must complete any actual setup; none was performed for this guide.
The protocol distinction matters. SPF normally evaluates the SMTP MAIL FROM identity, while DKIM identifies a signing domain through its d= tag. DMARC relates a passing authenticated domain to the domain in the visible From field. A reply destination serves another purpose. Under RFC 9989, section 4, an aligned passing SPF path or an aligned passing DKIM path can satisfy authentication. Both are not universally required for a DMARC pass.
Treat the published configuration as a starting point
The emBlue configuration page names an SPF include, a bounce CNAME, an epexo selector and a separate legacy _domainkey policy record. It also contains wording that associates the bounce alias with DKIM alignment. These are documented assertions, not proof of the identities emitted by a current account. Obtain the account's supported configuration before preparing an executable DNS change.
Do not reproduce its published key as a newly issued tenant key. DKIM verification retrieves a public key using the signature's selector and signing domain; the private signing key is not something recipients need. The old policy record alone cannot supply that selector lookup. Apply RFC 6376, sections 3.5 and 3.6 to distinguish the signature and key record. Have the provider resolve any discrepancy between its page, the account and the actual signature.
Prepare a bounded DNS change
Inventory existing records before adding anything. For an SPF proposal, identify the domain actually being authorized, retain other legitimate senders and assess the evaluation cost of the combined policy. Publishing a second SPF policy at the same owner name is not a safe merge. The DNS-querying-term limit in RFC 7208, section 4.6.4 applies during evaluation, including relevant nested processing; counting visible include words alone is inadequate.
Keep any envelope-domain request distinct from DKIM. A name containing “bounce” does not establish the SMTP identity used on the wire, the ownership of its SPF policy or the alignment mode that will apply. Ask for these facts in the proposed change record. Leave the custom-envelope capability unresolved when the documentation and tenant evidence do not establish it. Do not invent a fallback record to make a dashboard look complete.
For DMARC, preserve the existing domain policy unless its owner approves a specific revision after considering all senders. Do not replace enforcement with a sample monitoring policy to accommodate one campaign. Report destinations need a responsible recipient and appropriate authorization. A public setup example does not authorize disclosure of reporting data or establish that a mailbox is monitored.
Design verification around identities
Prepare an empty evidence table with workflow, timestamp, From domain, receiver-observed envelope domain, each DKIM d= and s= pair, authentication results, alignment conclusion and evidence location. Label every uncollected cell “not observed.” A hypothetical message from notices@orchard.example with a passing signature from orchard.example illustrates an aligned DKIM path; it is a fictional teaching case, not an emBlue test or a promised account behavior.
After an approved implementation, send a controlled message through the chosen workflow to an authorized mailbox. Preserve its original headers and identify the receiving system that supplied the authentication assessment. An upstream sender can insert an Authentication-Results field; rely on the assessment produced within the receiver's trusted processing boundary, not the field name alone. RFC 8601, section 7.1 explains why the trust boundary matters. Redact recipient information in review copies without destroying the evidence needed to understand the route.
If verification disagrees with a dashboard, isolate the disagreement: record publication, signing activation, stale observation, wrong Sender or a different application path. Repeating a bulk send is not a diagnostic shortcut. Retain the proposed rollback, including the previous configuration and dependencies, but avoid deleting a selector while legitimate queued mail might still need its public key.
Acceptance remains open
The exact catalogue requirement is: Current emBlue first-party setup evidence and a received-message identity table from the exact product and route.
The documentary portion is supported, with material caveats; the received-message table is absent. Current key ownership, custom-envelope support and tenant applicability also remain unresolved. A technical reviewer must reconcile the legacy instructions before a production procedure is approved. This manuscript neither certifies a working configuration nor guarantees inbox placement, and publication still requires owner, source, visual and site acceptance.