Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Choose one DKIM design before editing DNS
JangoMail documents two different DKIM workflows: a system key exposed through a CNAME and an advanced key published directly as TXT. They are alternatives, not two records to stack at the same selector. This guide covers JangoMail campaigns and the separately documented custom-envelope controls for API or SMTP relay sends. Verify the route and account before applying either workflow. System DKIM and advanced DKIM.
Assign the account owner and DNS administrator. Record the From domain, current selectors, envelope domain, reply destination and scheduled sends. The relevant first-party setup articles carry 2022 or 2023 update dates, although they remained retrievable on 8 November 2026. Confirm current account behavior before replacing a working key or assuming every interface label is unchanged.
Publish and enable the selected key
For the system method, JangoMail documents Settings > Email Settings > DKIM, creation of a domain key and a Details view. Its published CNAME design uses jm._domainkey beneath the sending domain, pointing to jm._domainkey.jmsend.com. Check that this matches your account's instructions and that the owner has no conflicting record. Publish the CNAME, then return to JangoMail and enable the domain key. Publication alone is not activation. The system article's later reference to checking a TXT record is inconsistent with its explicit CNAME setup; do not interpret it as a second record requirement. System-key instructions.
For the advanced method, create the domain and selector in the DKIM settings, obtain the complete generated Value from Details and publish it as TXT at the specified selector owner. Then use Enable so JangoMail can verify the record and activate signing. Preserve unrelated selectors and obtain a rotation plan before replacing an active key. Never paste a private key into public DNS. Advanced-key instructions.
DKIM is a digital signature, not message encryption. A signature can demonstrate that signed content validates against a domain's published key; it does not make the message confidential or prove a named human wrote it. A header's mere presence also does not establish a passing result. DKIM specification.
Authorize the envelope that actually sends
JangoMail's SPF guidance identifies include:jangomail.com. Add it to the appropriate existing policy instead of replacing other authorized senders or publishing another v=spf1 record. Do not copy the account-setup article's a and mx mechanisms unless those servers genuinely need permission. Review the full evaluated policy and nested DNS lookups. JangoMail SPF and SPF specification.
The custom Return-Path article exposes envelope controls in three places: Campaign Settings > Envelope-Sender Address, the API's mailfromaddress option, and the SMTP relay's X-RelayOptions header. Confirm which applies to the actual sender. Do not insert a literal Return-Path header into the submitted message as a shortcut; the receiving server derives that header from SMTP handling. A custom envelope domain needs appropriate SPF authorization and alignment review. Custom envelope instructions.
Keep the visible From, envelope and signing domain separate in the change record. DMARC can pass through aligned SPF or aligned DKIM; a provider-domain pass that lacks the required relationship to From is insufficient. Do not copy a reject-policy example without reviewing the domain's other legitimate senders. DMARC specification.
Prove activation through the intended workflow
Original acceptance worksheet, not a completed test: send harmless content to controlled external mailboxes using each relevant campaign, API or relay route. Record the route, test time, visible From, Return-Path, trusted SPF result and evaluated domain, every DKIM d= and s= pair, and trusted DMARC result. Confirm reply handling separately. An API test does not certify campaign settings, and a campaign test does not certify an application's relay headers.
If Enable fails, compare the complete DNS owner, type and value with the selected key method. If signing validates but DMARC fails, compare signing and From domains rather than generating another key immediately. If only SPF fails, inspect the actual envelope identity and policy. Pause the affected rollout and retain the previous approved sender while investigating.
No account changes, live DNS checks, delivered-message tests or SME review were performed for this documentary candidate. Release requires current tenant confirmation, resolved record-type instructions, receiver evidence and an approved recovery plan.