To authenticate custom-domain Jira and Confluence notifications, add an email domain in Atlassian Administration, publish the complete generated DNS set, run the records check, and wait for the domain to become Active. Then make the sender address available to the relevant app and configure that app to use it. DNS verification alone does not finish the application handoff. Atlassian’s custom-email workflow
This guide covers the organization-level Atlassian Cloud custom-email-address workflow for Jira and Confluence notifications. It is not a universal SPF recipe for Trello, Statuspage, Data Center, or an external SMTP integration. Statuspage has its own notification authentication instructions.
No organization settings, customer DNS records, or live notifications were changed or tested.
Separate the three configuration gates
Treat this as three linked tasks with separate evidence:
- Domain authentication: The generated DNS records exist and match Atlassian’s requirements.
- Provider provisioning: The domain has completed activation.
- Application selection: The intended notification actually uses the configured sender.
Assign an owner to each gate. In a larger organization, the DNS administrator may finish their work before the Jira administrator starts. A handoff that says only “DNS complete” leaves the most visible part of the change unverified.
Adding a domain for notification email differs from verifying a domain to manage user accounts. An existing account-management verification should not be treated as email authentication. Organization admins can add email domains across Atlassian Cloud plans according to the current documentation. Email-domain scope and permissions
Record the intended From address, organization, site, app, notification type, and authorized test recipient. For example, a Jira project notification and a Confluence notification are separate checks even if they share a domain. Do not use a successful message from one app as evidence about every Atlassian service.
Prepare authoritative DNS access
You need authorized access to the domain’s actual DNS host as well as organization-admin access. The registrar is not necessarily the DNS provider. Confirm authoritative nameservers before editing and save the existing relevant records.
Inventory current SPF, DMARC, DKIM selectors, verification tokens, and records at any generated bounce hostname. Preserve website and inbound-mail records. A notification-sender change is not a reason to replace MX records or move DNS hosting.
Check the DNS editor’s suffix behavior. If Atlassian supplies GENERATED_SELECTOR._domainkey.example.com, an editor managing example.com may expect only GENERATED_SELECTOR._domainkey. Those uppercase words are placeholders. Confirm the public owner rather than assuming the dashboard interprets a fully qualified name correctly.
For an issued child-domain owner GENERATED_SELECTOR._domainkey.notifications.example.com, enter GENERATED_SELECTOR._domainkey.notifications in the parent example.com zone, or GENERATED_SELECTOR._domainkey in a separately delegated notifications.example.com zone. If _domainkey.notifications.example.com is itself delegated, the relative name there is GENERATED_SELECTOR. Preserve the shared NS delegation and publish at its actual authority. These names explain placement, not an account-issued selector or automatic eligibility for a new sender.
Do not overwrite another application’s CNAME, TXT, or address record at a required owner. CNAME names have exclusivity restrictions. Resolve an unexpected collision with the responsible administrators or Atlassian Support. DNS record conflicts
Add the email domain and collect its records
In Atlassian Administration, select the correct organization, then open Organization settings > Emails. Use Email domains > Add domain, enter the intended domain, and choose Add. The DNS records dialog provides the account-specific setup. Add your email domain
If the dialog was closed, return to the domain’s See DNS records action. Atlassian currently describes a set of five or six records. Copy the complete set rather than assuming that every organization receives identical rows. Publish DKIM1 and DKIM2 as CNAMEs, the bounce record as a CNAME, and each TXT entry with its specified name and value. Publish the generated record set
Create a change worksheet with one row per supplied record. Include its purpose, type, full owner, target or value, and observed public answer. Keep verification tokens from the current organization; a token from another account or a documentation screenshot is not interchangeable.
The two DKIM aliases support key rotation. The bounce CNAME is part of Atlassian’s documented SPF authentication model. Preserve all three aliases after verification; their purpose is ongoing authentication, not merely a one-time proof of ownership. Atlassian DNS record roles
Handle SPF without guessing the sending identity
There is a useful nuance in the official documentation. The organization-administration reference describes SPF through the bounce CNAME. A separate Cloud troubleshooting article still documents include:_spf.atlassian.net for configurations that require an SPF TXT entry. Therefore, use the actual generated record set for your domain rather than adding or deleting a root SPF include by assumption. Current bounce model and Atlassian SPF troubleshooting
If your setup requests that include, incorporate it into the existing policy at the specified owner. Preserve other legitimate senders and the established terminal qualifier. Do not create a second SPF policy, and check the total ten DNS-lookup-term limit, including nested includes. SPF evaluates the SMTP envelope sender, not simply the visible From address. SPF specification
An all mechanism makes redirect ineffective and mechanisms after all unreachable. Preserve any existing redirect-based authorization and reviewed qualifiers; do not append a canned terminator. An SPF -all failure does not guarantee receiver rejection. SPF all and redirect rules.
Do not claim SPF alignment solely because a CNAME exists. The actual envelope domain must be observed on a delivered notification. This matters particularly where a strict alignment policy is already in force.
For another sending platform sharing the root domain, retain its independent authentication. EmailAuth's raw-versus-aligned DKIM guide explains why a passing signature alone does not prove authentication of the intended brand.
Check records and wait for activation
After publication, open See DNS records and choose Run DNS records check. Review individual failures rather than repeatedly recreating the entire domain. Atlassian also checks records every 24 hours. Record-check controls
A matching DNS set triggers provisioning. Atlassian says this can take up to 72 hours and the completed domain status becomes Active. Treat that interval as documented guidance, not a guarantee. Provisioning and Active status
If a check fails, compare the exact owner, record type, and target against the current account. Verify that the DNS record is public, not only present in an internal resolver. Leave generated CNAMEs as DNS records rather than hiding their targets behind a website proxy.
Where Cloudflare hosts the issued aliases, use DNS only and turn the relevant per-record Flatten option off when available. Its zone-wide flatten-all setting cannot be overridden per record. The required end state is that zone-wide flatten-all does not suppress these issued literal CNAME aliases: turn it off if applicable, but coordinate affected services before changing shared zone behavior. If that end state cannot be achieved safely, stop and coordinate a supported layout rather than proceeding with hidden aliases. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the setting. If mandatory behavior cannot preserve a required literal CNAME, stop and coordinate a supported layout. Do not remove shared NS delegations to make verification pass. These are conditional DNS-host controls, not Atlassian settings. Cloudflare verification and flattening controls and exceptions.
Keep a dated record of the completed checks. If a domain subsequently stops working after a DNS migration, this gives the next administrator a concrete baseline instead of a vague claim that setup once succeeded.
Complete the sender-address handoff
After domain verification, use the Email addresses tab to add the intended role-based sender address and select which Jira or Confluence app instances can use it. Atlassian currently documents a maximum of 30 addresses per site. Add email addresses and select app instances
For Jira Cloud, open Settings > Spaces, select the target space’s More actions > Space settings, then Notifications > Internal notifications. Choose Edit under Notification email, then Edit beside the email card. Select the custom address in the Email dropdown and save. Current documentation calls these containers spaces; older interfaces may use project terminology. The selection is specific to that space. Jira sender-selection steps
For Confluence Cloud, a Confluence administrator opens the administration wheel, then Settings > Configuration > Notifications. Select the sender in Email addresses and choose Save changes. Allow up to one hour for the change to take effect. Content-sharing notification emails remain Atlassian-sent even with a custom sender selected, according to the documented exception. Choose an ordinary activity notification for the custom-domain test. Confluence sender selection and exception
Do not stop at “address available.” Trigger the exact notification the team needs and confirm its actual From address. A default sender can continue to authenticate successfully while failing the business requirement to use the custom domain.
Preserve DMARC and verify the effective policy
DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict alignment requires exact matching. A provider-owned signature can pass cryptographically without aligning to your domain. Current DMARC standard
For example, passing DKIM d=notifications.example.com with visible From updates@example.com aligns in relaxed mode when both share Organizational Domain example.com, but fails strict alignment. Passing d=example.com matches that From domain in both modes. These are illustrative identities; inspect the actual notification rather than assuming its signer.
Query _dmarc.example.com for a sender at example.com. For a sender at notifications.example.com, query _dmarc.notifications.example.com and investigate applicable parent-policy inheritance. Preserve existing policy, reporting, and strictness. Do not replace an established p=reject or p=quarantine policy with a setup tutorial’s p=none example.
Only where no direct or applicable inherited policy exists, the owner explicitly approves first-time monitoring, and someone will review reports, an initial TXT record at _dmarc.example.com might contain v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Use an approved, monitored destination. In the example.com zone, the relative host is _dmarc; for an approved policy on From notifications.example.com, full owner _dmarc.notifications.example.com maps to _dmarc.notifications in the parent zone or _dmarc in a separately delegated notifications.example.com zone. Do not override inherited enforcement with a child monitoring policy. Publish only one policy at that owner. RFC 9989 replaces RFC 7489 and removes pct, so new rollout instructions should not rely on that tag. Policy publication and discovery
Compare the Organizational Domain of the report destination with that of the domain where the DMARC policy was found. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted even when its hostname differs. Arrange required authorization with the report operator and separately obtain the domain owner’s data-sharing approval. RFC 9990 section 4.
Validate public DNS and trusted receiver headers
Use these read-only templates, replacing uppercase placeholders with the exact generated names or identities observed in the message:
dig +short CNAME DKIM1_OWNER
dig +short CNAME DKIM2_OWNER
dig +short CNAME BOUNCE_OWNER
dig +short TXT GENERATED_TXT_OWNER
dig +short TXT MESSAGE_SELECTOR._domainkey.MESSAGE_SIGNING_DOMAIN
dig +short TXT OBSERVED_MAIL_FROM_DOMAIN
dig +short TXT _dmarc.VISIBLE_FROM_DOMAIN
Repeat the TXT query for each generated TXT owner. All supplied aliases and verification values should match the account’s set. For active DKIM, the message’s selector and signing domain identify the key lookup. A published public key is not itself proof of a valid message signature. DKIM verification model
Send the chosen Jira or Confluence notification with non-sensitive test content to a valid authorized external test mailbox. Inspect original headers from that mailbox. Use its trusted Authentication-Results, not an authentication claim copied from an earlier or untrusted hop. Authentication-Results trust
Have the receiving administrator or service documentation establish which Authentication-Results fields were generated inside its known processing boundary and how externally supplied fields are stripped or distinguished. If that cannot be established, use receiver-controlled authentication diagnostics. Header position or a familiar authserv-id alone is not proof; ignore attacker-supplied result fields.
The acceptance record should show the intended From address, dkim=pass with an aligned signing domain, and dmarc=pass. Require the intended branded signature and intended From: SPF-only DMARC success or a provider-rewritten From does not prove this DKIM setup works. Record the SPF result and smtp.mailfrom independently, comparing that identity with the visible From under the applicable alignment mode. Investigate unexpected SPF failures separately even when aligned DKIM produces a DMARC pass. Compare the observed envelope domain, sending IP, DNS policy, and any forwarding hop before changing authorizations. Retain message ID, timestamp, app, site, and notification type.
Distinguish SPF fail from permerror caused by invalid syntax, duplicate policies or evaluated DNS-term limits, and from temperror due to temporary DNS evaluation failures. An unaligned SPF pass is a different result. Investigate each independently even when DKIM supplies DMARC pass. SPF result meanings.
If a direct message passes but a forwarded copy fails, investigate the forwarding path separately. Do not remove a working domain policy merely because a message changed after its original delivery.
Troubleshooting and frequently asked questions
Why does DNS remain unverified?
Check every row, especially duplicated SPF policies, omitted verification TXT values, doubled domain suffixes, and CNAME target mismatches. The official Cloud troubleshooting guide recommends matching records to the account and rerunning the checker. Unverified-record diagnosis
Why is the default sender still visible?
Confirm Active status, address availability for the correct app instance, and the app’s notification selection. For Confluence, allow the documented one-hour change interval and distinguish content-sharing messages, which retain the Atlassian sender by design. Test a newly generated ordinary activity notification, not one queued before the change.
Does this setup authenticate Statuspage or self-hosted Jira?
No. Those are separate routes. Use their specific configuration and repeat receiver-side verification rather than copying this organization’s generated records.
Can I delete the records after activation?
No routine cleanup should remove them while the sender remains in use. For retirement, first establish that the relevant notifications have moved, then plan a controlled removal with the DNS and application owners.
Does a passing test guarantee inbox placement?
No. It establishes authentication for the tested route and message. Filtering, reputation, recipient rules, and application delivery behavior need separate evidence.