Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Map the sender to the correct Mailjet API key
Mailjet configuration is scoped more narrowly than a company-wide domain inventory. Its domain-validation guide states that validation applies to the API key under which it was performed; a domain used in multiple subaccounts must be verified in each. Begin by identifying the key or subaccount used by the application or campaign, without copying secret credentials into the review record. Then record its From domain, template, responsible team and current authentication status. Mailjet domain-validation guide.
This distinction matters when an organization has multiple brands or separate development and production integrations. A domain can look healthy in one administrative view while the actual job uses another key. Ask the application owner to identify the active integration, and use a controlled send to connect it to a received message. Keep domain ownership, authentication configuration and delivery acceptance as three separately recorded checks.
Before editing, save the existing DNS values and the relevant Mailjet settings. Agree which campaigns or transactional flows will be paused if the test fails. Include anyone responsible for replies and bounce processing in the change plan. The objective is a working, attributable route, not simply a green indicator in an account that production never uses.
Validate ownership before configuring authentication
Mailjet offers domain validation by an account-specified DNS TXT record or a temporary website file. Use the method appropriate for the controlled domain and the exact values shown in the selected account. Completing this step allows the account to recognize the domain; SPF and DKIM configuration follows separately. If validation fails, check the published owner and value or the required file's exact name and contents rather than repeatedly creating new sender entries. Ownership-validation options.
Record the successful validation scope explicitly. If several subaccounts send for the same brand, make a row for each rather than assuming ownership verification propagated across them. A manually verified single address and an authenticated domain are also different pieces of evidence. Keep a list of intended addresses and test the one the real campaign will use.
Publish the active SPF and DKIM configuration
Mailjet documents include:spf.mailjet.com for SPF and an account-provided DKIM TXT value. Retrieve the complete key from the SPF/DKIM Authentication area; never use a truncated public example. Merge SPF authorization into the existing applicable policy rather than publishing a second one. After publication, inspect the domain's status in Mailjet and retain the results with the DNS change record. Mailjet SPF and DKIM guide.
Treat the final DNS owner as part of the evidence. DNS interfaces vary in whether they append the zone, and a record can be saved successfully at the wrong name. Compare the authoritative answer with the complete name supplied by Mailjet. Preserve other valid TXT records and unrelated DKIM selectors. Do not replace the organization's entire SPF policy with a provider-only example or change its terminal qualifier without a separate review.
Key changes deserve their own maintenance plan. Mailjet documents a Regenerate Key control and requires full-domain validation for that operation; validating only an address is insufficient. The guide also warns that DNS providers can truncate unsupported key lengths. Prefer the approved security strength and resolve publication support before changing a working key. Key-regeneration guidance.
Decide whether custom Return-Path is needed
Mailjet's default Return-Path uses bnc3.mailjet.com. Its custom option is documented for paid accounts and requires a customer subdomain CNAME to bnc3.mailjet.com, domain validation and support activation for the selected API key. Only one active custom Return-Path is permitted per key. Publishing the CNAME alone does not complete activation. Mailjet custom Return-Path procedure.
Use the official support channel for activation and provide only the requested non-secret account identification and public DNS evidence. Never include the API Secret Key in a screenshot or change ticket. Record support completion and then inspect a fresh message to establish the resulting envelope identity. An approved domain elsewhere in the same organization is not automatically an appropriate bounce domain for this route.
For a multi-brand key, Mailjet documents that multiple sender domains can still authenticate using correctly configured DKIM, even though the key has only one custom Return-Path. It suggests separate API keys where per-domain return-path and tracking consistency is required. Mailjet sender and API-key scope.
That is an architectural choice for the owner, not an automatic instruction to create extra keys. Assess how many domains genuinely need envelope alignment, what applications share the existing key, and who will maintain each configuration. Avoid adding credentials or splitting production routing without approval and a clear operational reason.
Read authentication and alignment from the received message
SPF evaluates the SMTP envelope identity, or HELO in the relevant cases, rather than the visible From. Adding Mailjet's include to a customer domain does not make a provider-owned envelope domain align with it. DKIM provides an independent signing identity through d= and a selector through s=. Preserve the trusted receiver's results for both methods. SPF specification and DKIM specification.
DMARC can pass through an aligned passing DKIM signature even when SPF passes for an unaligned provider envelope. Conversely, a custom bounce subdomain should not be assumed to satisfy strict SPF alignment with a different From domain. Compare the actual domains under the policy's effective alignment settings. A reply address or branded tracking URL does not participate in that comparison. DMARC specification.
Create the API-key-specific acceptance record
Send a harmless campaign or application message to controlled recipients through the actual integration. For each API key and From-domain combination, record the non-secret account identifier, workflow, template, send time, From, Reply-To, Return-Path, receiver SPF identity/result, each DKIM d=/s=/result and DMARC result. Add whether a custom Return-Path was requested, activated and actually observed. Store the original received message and DNS snapshots in restricted evidence storage.
Expected values belong beside observed values, not in their place. A support ticket saying activation is complete supports the configuration history, while the fresh received message supports actual use. Test each materially different sender brand and repeat after a key rotation or routing change. Add separate outcomes for replies, unsubscribe handling and tracking where those features form part of the approved service.
Diagnose the narrow failure and recover
If validation or authentication fails in Mailjet, confirm the selected key and exact DNS owner first. For SPF errors, check duplicate policies and the protocol lookup limit. For DKIM errors, compare the complete public key and observed selector; do not regenerate repeatedly while stale DNS is still being evaluated. If both methods pass but DMARC fails, inspect alignment rather than treating another include as the default cure.
If mail authenticates but is delayed or filtered, investigate provider events, recipient responses, content and reputation separately. Authentication is a prerequisite for trust, not a guarantee of inbox placement. If the change breaks a live workflow, pause that route and restore the last approved application or DNS configuration where safe. Coordinate custom Return-Path rollback with support and preserve evidence of the before-and-after identities.
No Mailjet tenant, customer DNS or live received message was inspected for this manuscript. The exact-route original identity table, tenant-specific feature confirmation and human SME review remain open. These steps are a researched candidate for implementation and verification, not a claim that a customer configuration already passes.