On this page: Scope and prerequisites · Establish the real return path before editing SPF · Choose one DKIM publication method · Preserve DNS and validate the published names · Retain DMARC policy and prove alignment · Troubleshooting JangoMail authentication · Frequently asked questions · Review boundary
Authenticate JangoMail by authorizing its sending service in the appropriate SPF policy, creating a System DKIM CNAME or Advanced DKIM TXT in your account, publishing the issued public records, and returning to Enable DKIM. Check the actual envelope sender before deciding where SPF belongs. Finish with a delivered-message alignment test, not just a DNS lookup. System DKIM, SPF instructions.
Scope and prerequisites
This guide covers JangoMail-originated email and its documented API/SMTP envelope controls. It does not authenticate messages that bypass JangoMail, or replace a separate JangoSMTP account's configuration review. Record which account sends each campaign or application message, and whether the application overrides the sender.
You need an organizational sending domain, permission to manage its DNS, JangoMail access to email settings, and a controlled receiving mailbox for later testing. Capture the existing DNS records and DMARC policy, including inherited policy, before making changes. Assign an application owner and DNS owner. A free consumer mailbox address is not a domain whose authentication you can configure.
Build a four-column identity worksheet: visible From domain; envelope MAIL FROM domain; DKIM signing domain; tracking hostname. The first is what the recipient sees. The second is what SPF normally authenticates. DKIM uses the signature's d= domain. A tracking hostname brands links and is not evidence that the message passed authentication.
If employee mail also uses Microsoft 365, configure and test that separate route with the Microsoft 365 authentication guide. Adding JangoMail does not replace Microsoft 365 authorization or DKIM.
Establish the real return path before editing SPF
JangoMail's custom-return-path documentation describes the From address as the default and supports an explicit envelope override. For API submissions it documents mailfromaddress; for SMTP relay it documents X-RelayOptions: mailfromaddress=.... For campaigns, find the override under Campaign Settings → Envelope-Sender Address. These controls affect the envelope identity, not just the visible From address. Confirm the chosen value with the application owner and later compare it to the receiver's smtp.mailfrom. Do not merely insert your own Return-Path header and assume that it controls delivery. Custom Return-Path Header.
The official SPF page specifies include:jangomail.com. Its JangoMail-only example is not a replacement for an existing multiprovider policy. When the applicable owner already has SPF, merge the necessary authorization into that policy before its terminal all; preserve other legitimate senders and the reviewed ending. A custom envelope subdomain requires its own SPF assessment, rather than assuming that a parent-domain record is inherited. JangoMail SPF.
If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.
The vendor page uses the general phrase “FROM address.” For protocol diagnosis, distinguish the visible header From from SMTP MAIL FROM. SPF does not authenticate the visible From simply because you added an include there. SPF identity rules.
Choose one DKIM publication method
System DKIM: provider-managed CNAME
In Settings → Email Settings → DKIM, enter your domain and select CREATE DOMAIN KEY. Open DETAILS and copy the complete DNS owner, type and value. The current System DKIM article documents a CNAME at jm._domainkey pointing to jm._domainkey.jmsend.com; confirm that your account requests those exact values rather than treating this article as your account's record export. Publish the CNAME, then return to JangoMail and select ENABLE for the domain. Until enabled, DNS publication alone is not completion. The article's enable paragraph says “TXT” despite describing a CNAME workflow; do not create an extra TXT record alongside the CNAME to satisfy that wording. System DKIM workflow.
Advanced DKIM: account-created public-key TXT
The Advanced path uses the same DKIM settings area. Enter the domain and selected supported selector, save, then open Details. Publish the full public value at the displayed selector._domainkey owner as TXT. Return to Enable after DNS resolves. Obtain the actual selector and public key from your account, not from another customer's screenshot. Never place private signing material in DNS, this worksheet or a support attachment. Do not combine this TXT with the System CNAME at the same owner. Advanced DKIM workflow.
An older guide may call the menu “Sending and Receiving → DomainKeys/DKIM.” Use the current account's corresponding control rather than creating a duplicate domain because the label differs. If the interface or selector conflicts with an existing integration, ask JangoMail to confirm the correct method before changing production records.
Preserve DNS and validate the published names
Save the original record values and TTLs. Check whether your DNS editor appends the zone automatically: a relative jm._domainkey in an example.com zone becomes jm._domainkey.example.com. A fully qualified name entered into a relative-only field can produce a duplicated suffix. The examples here describe names, not an instruction to configure example.com.
For an illustrative issued owner jm._domainkey.news.example.com, a suffix-appending editor for example.com uses jm._domainkey.news; one for a separately delegated news.example.com zone uses jm._domainkey. If _domainkey.news.example.com itself is delegated, use relative jm in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries. For Advanced DKIM, substitute its actual account selector; jm here illustrates the System name, not a requirement for every Advanced key.
Do not remove other DKIM selectors, MX records, verification TXT records or unrelated senders. CNAME values are hostnames, without https://; a CNAME owner cannot coexist with ordinary TXT or other data. Resolve ownership conflicts before publication. DNS alias rules.
The following alias controls apply to System DKIM's CNAME only, not to the Advanced direct-TXT public key. Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.
Keep one SPF policy at each exact owner. Assess the complete evaluation, including nested includes and redirects: SPF allows ten evaluated DNS-querying terms, not ten provider includes. include, a, mx, ptr, exists and redirect count; ip4, ip6 and all do not count toward that limit. Exceeding it produces permerror. Do not use +all or weaken an existing ending as a workaround. RFC 7208, section 4.6.4.
Read-only checks, with every uppercase placeholder replaced by the exact account-issued or observed name:
dig +short TXT ENVELOPE_DOMAIN
dig +short CNAME SYSTEM_DKIM_OWNER_FQDN
dig +short TXT SYSTEM_DKIM_TARGET_FQDN
dig +short TXT ADVANCED_DKIM_OWNER_FQDN
dig +short TXT _dmarc.FROM_DOMAIN
Use only the DKIM queries for your selected method. Expect the System CNAME target to match the account and lead to a public key; expect Advanced TXT to contain the full issued public value. Query the authoritative nameservers when recursive answers disagree. A blank answer needs investigation of owner, zone, delegation and cache state; it does not prove that waiting alone will fix it. Recheck JangoMail's Enable result after DNS is correct.
Retain DMARC policy and prove alignment
DMARC passes when SPF or DKIM both authenticates and aligns with the visible From domain. Relaxed alignment accepts the same organizational domain; strict alignment requires an exact match. A custom bounce subdomain can align under relaxed SPF but not strict SPF. Aligned DKIM can independently satisfy DMARC. Preserve existing policy, reporting and intentional alignment settings. If no applicable policy exists, a monitored p=none rollout can be considered before enforcement; do not downgrade an established policy to finish setup. The current DMARC standard is RFC 9989, and pct has been removed. DMARC specification.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.
Do not add ruf automatically: failure reports may expose message content and personal data. Failure-report privacy.
Publish a first DMARC policy only when appropriate
First inspect the applicable exact-domain and inherited policies. Only if there is no applicable existing direct or inherited DMARC policy, and the domain owner approves a monitored rollout, create a TXT record at _dmarc beneath the visible From domain with the minimal value v=DMARC1; p=none. For From addresses at example.com, the full owner is _dmarc.example.com; for From addresses at news.example.com, it is _dmarc.news.example.com. In the example.com DNS zone, relative-name fields take _dmarc and _dmarc.news respectively. A separately delegated news.example.com zone instead takes _dmarc. Confirm how your DNS editor handles names before saving.
These are illustrative names, not records to publish unchanged. Maintain one DMARC policy at the intended owner: edit the existing record after review rather than adding a duplicate or overriding a protective inherited policy with p=none. A minimal policy requests no aggregate reports. If monitoring is approved, append ; rua=mailto:AGGREGATE_REPORT_ADDRESS only after replacing the placeholder with a provisioned, authorized report address. Apply the Organizational Domain authorization rule above when selecting the destination. External report authorization, RFC 9990 section 4.
After an authorized operator completes setup, send a non-sensitive message through each actual campaign, API or SMTP route. In the receiving mailbox's original message, inspect the trusted receiver-added Authentication-Results, not an untrusted header injected by a sender. Record spf, smtp.mailfrom, dkim, header.d, selector s=, dmarc and header.from. Expect a valid DKIM signature for your intended domain, the expected envelope identity, and dmarc=pass supported by alignment. A signature's presence alone proves nothing about cryptographic validation. Save the timestamp and route beside the results.
Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.
For this branded DKIM setup, require the intended JangoMail signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate.
Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.
Do not accept a campaign test as evidence for an application that sets a different envelope address. Test direct delivery first; forwarding can change SPF behavior and content rewriting can damage DKIM. Successful authentication does not guarantee inbox placement.
Troubleshooting JangoMail authentication
- DKIM is published but disabled: verify the account's Enable step and the selected CNAME versus TXT method. Check public resolution at the full owner before retrying.
- SPF passes but DMARC fails: compare
smtp.mailfromwith the visible From domain, then inspect DKIM alignment. A passing unrelated envelope domain is insufficient. - A selector already exists: identify which service owns it. Do not overwrite that key or add a CNAME alongside a TXT. Resolve the selector choice with support.
- Campaigns pass, SMTP messages do not: compare the actual From and
mailfromaddressoverride, account and DKIM selection. Keep route-specific evidence. - DNS looks right but DKIM fails: compare
d=ands=with the published key owner, confirm enablement, then check whether a later gateway altered signed content. Give support a sanitized header and timestamp, not credentials.
Review boundary
No customer account, DNS change or sending test was performed. Complete the account and message checks above before relying on the configuration in production. Successful authentication does not guarantee inbox placement.