You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I have an existing TXT record for SPF on my domain. How do I modify it to include the Atlassian domain verification token so both will still be valid?
E.g. current record looks like:
type: TXT
key: example.com
value: v=spf1 include:emailserver.com ~all
What should the new record value look like to include the "atlassian-domain-verification="?
***NOTE: The following answer would be correct if the TXT record was only required when first verifying a domain but this is not true, the TXT record is required in perpetuity***
It's probably not possible to combine both Jira verification and SPF in the same TXT record, and it's certainly not possible to have more than one TXT record at origin level in the same DNS zone.
Despite that, it's still possible to use a TXT record for Jira verification, because the TXT record for Jira verification is only needed during the actual verification; after that, it can be removed or replaced.
The way to proceed is to temporarily replace the TXT record for SPF with the TXT record for Jira verification, complete the Jira verification, and then re-instate the TXT record for SPF.
With direct access to the DNS zone configuration, and attention paid to the TTL of the TXT record, the whole process can take as little as a couple of minutes, so it shouldn't matter that the zone will not have an SPF record for that time.
If the TTL of the TXT record is fairly short (say, 300 seconds or less) it should be possible to proceed directly.
If the TTL is longer, it would be safer to first change the TTL to e.g. 300 and wait for a period of time equal to or longer than the original TTL before carrying out the procedure. Once the procedure is complete, the TTL can be increased back to the original value.
I was under the impression that the domain verification needed to remain in place permanently. If that's not the case than I can use the temporary TXT change as you suggest.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I stand corrected. I tried this and it worked, but it looks like it will break later because Atlassian periodically checks that the TXT record is still there. Thank you for pointing this out.
One would have thought that, instead of the origin, Atlassian would choose to use a name under the zone, to allow their record to co-exist with SPF.
I am now faced with either turning off SPF for my domain or using HTTPS verification.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for testing it out.
I think Atlassian needs to add another DNS verification method maybe similar to how DKIM is handled with subdomains.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.