Use Atlassian Cloud’s supported custom-email workflow when Jira or Confluence should send notifications from your organization’s domain. This guide covers that organization-administration model. It is not a universal record recipe for Statuspage, Trello, self-hosted Data Center or an external SMTP server; those products and routes require their own first-party instructions.
Confirm the notification model
Identify the organization, application, intended custom From address and administrator responsible for it. Distinguish receiving mail from Atlassian-owned domains from granting Atlassian permission to send with your custom identity. You do not need to edit your domain’s SPF merely to receive a notification sent from somebody else’s domain.
Atlassian’s Jira Cloud guide directs organization administrators to add custom email addresses through Atlassian Administration. Its organization setup workflow separates adding the email domain, publishing the generated DNS records, adding addresses and making them available to the relevant application. Domain verification used for managing accounts is not a substitute for completing this email-authentication workflow.
Publish the complete generated record set
Add the email domain through the current custom-email setup and copy the displayed DNS owners, record types and targets into a change request. Atlassian documents two DKIM CNAME records and a bounce CNAME in this authentication model. The two DKIM records support key rotation. The bounce-domain CNAME alias supports the provider-managed envelope identity and SPF behavior.
Publish exactly the records the organization’s setup screen generates. Do not replace the bounce CNAME with a generic SPF TXT copied from an unrelated Atlassian product, and do not invent selector targets from the application’s URL. Do not add a CNAME at the root of a domain that must retain its normal MX and other records. The generated owner names identify the intended alias names.
Check whether the DNS console expects a full owner name or a relative label. A duplicated domain suffix, missing fallback selector or incorrect target can leave verification incomplete. Query the authoritative DNS service and compare each answer with the setup screen before pressing verification again.
Complete the application handoff
After the records match, wait for Atlassian’s domain provisioning to finish and confirm the domain status is Active. Matching DNS is not the same as completed provisioning; Atlassian documents that this can take up to 72 hours. Only then complete the address and application handoff. Add the required email addresses and make them available to the intended app according to the current administration flow. Select the approved address for the relevant notification configuration. Keep the ownership-verification step, address availability and app selection as separate checklist items: the DNS may be correct while an application still uses its previous default sender.
Trigger a controlled notification from the exact Jira or Confluence workflow. Capture its raw external headers. Record the actual From address, SPF smtp.mailfrom domain, DKIM d= and s= values, and trusted recipient DMARC result. A successful DNS checker is necessary setup evidence, not proof of every application message’s identity.
Evaluate alignment without guessing the bounce format
Atlassian manages the target side of the supplied aliases; the generated values are account-specific evidence. Do not hard-code a bounce hostname pattern in an operational runbook. Compare the domain actually seen in the received message with the From domain under the published alignment modes.
Synthetic example: From notifications@example.com has a passing DKIM signature with d=example.com and an unrelated passing SPF identity. The exact-match DKIM path can satisfy DMARC. If the intended custom signature is absent, a valid signature for an Atlassian-owned domain does not automatically align with example.com. Preserve all signatures and the full route before deciding that DNS is at fault.
Your organization remains responsible for the DMARC policy that protects its visible From domain. Inventory other legitimate senders and coordinate reporting and enforcement. Do not create duplicate DMARC records or replace an existing policy as an incidental step in adding one application.
Preserve delegation through changes and retirement
Retest after moving DNS hosting, changing custom notification addresses, transferring apps, rotating keys or receiving provider instructions to change records. Keep both DKIM delegations intact during ordinary operation. Assign the domain owner and app owner explicit responsibilities for verification and incident response.
When retiring custom-domain sending, first change or disable the dependent app configuration, verify no remaining notifications rely on it, and then remove obsolete authorizations through an approved DNS change. Retain the old values and a rollback plan for the transition. This guide reports first-party documentary findings and illustrative tests, not live Atlassian account execution.
Record the three handoff gates
Use a separate evidence field for each gate: generated records match authoritative DNS; domain status is Active after provisioning; the intended app can select the approved address. Then retain the external notification result. If DNS matches but status is not Active, investigate provisioning rather than guessing a new record. If Active but the old From address remains, inspect address availability and app selection. These are proposed diagnostic branches, not an executed account test.