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
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.
Join now to unlock these features and more
We setup a domain which has been verified for account management (worked as expected).
However we also want to add the same domain as email sender, which causes some trouble now.
We have setup all entries as requested (doublechecked everything twice) and all well known DNS propagation tools are showing the proper entries for our Domain.
However Atlassian is unable to confirm one of the entries.
Does someone have any experience that could be shared?
I've seen similar entries but mostly there were only missing one (bounce) record that was not confirmed - none of our entries gets confirmed by Atlassian.
We're currently for testing/demo on the free plan but like to switch to a paid plan (from another product) to Jira Software & Jira Service management but sending emails from a proper domain would be essential for branding reasons.
Sorry for the inconvenience here. There was a known outage that was causing certain domains to fail to verify:
We have identified a temporary failure on our email service providers side where attempts to create new domains between 23:00:00 AEST January 12th to 03:30:00 AEST January 14th failed to create the Bounce CNAME record. We have applied a fix on our end to mitigate the issue. Please refresh the DNS check in the UI and report back if you are still experiencing any issues.
I did a lookup of that issue and found that your domain was one of these affected by this outage. At this point though, we believe this problem to be fixed on our service side. That said, you might have to force it to recheck the domain now, as opposed to several days ago when our service was not functioning as expected.
You can force a recheck by going to admin.atlassian.com > select the site/organization in question > Settings > Emails > email domains > See DNS records.
You could also try to remove those records, but note if you do this and then try to add that domain back to this page, the record values are going to change and in turn you then need to update the DNS TXT records on your site to match what we have on this page. It usually takes some time after a DNS record like this is updated before that change is propagated to other DNS servers, which is part of the reason we only check this by default on a 24 hour interval.
If you're still having this problem, then I would want to get you into our main support channel under https://support.atlassian.com/contact/ I can see that your Jira products are on the free plan which will prevent you from opening a support case on those products. But your Confluence on that same site is a paid subscription. So you should be able to choose that product in order to get into our support channel here so that we can investigate this further if need be.
Please let me know if you have any problems with creating such a request, as I can help to create one on your behalf if need be.
@Gregory Muir I can see you have a support ticket with us. But it looks like it is currently pending your consent for data access so that our support team can investigate further. Please approve that request so our support team can continue to help here.
I'm not sure which record is failing in your case, I can't see that far into the details of your site. But from what I can see from looking up your domain with a terminal command such as
dig [yourdomain] TXT
I can see that you appear to have 10 records within the SPF record (v=spf1) already, and none of the values in that specific record are for Atlassian. I'm unclear if you're trying to use this Sender Policy Framework record here or some other TXT record. If this is about the SPF record, then you should be aware that there is a limit of 10 such values for that record type, see also SPF: Don't Exceed Ten DNS Lookups!
If that is the failing record here, then you might need to consolidate some of the other individual ipv4 records in a single CIDR notation ranged address to make room for the
value within the SPF. For example, you have the first two IP records of
"v=spf1 ip4:22.214.171.124 ip4:126.96.36.199
These could be cut down to a single record such as
Which would provide a single record lookup for the 4 IP addresses of 188.8.131.52 - 184.108.40.206
If some other record is failing within the check, then we would need to examine specifically which one is failing here to better understand the next steps. In which case, it's probably better to respond to the support for additional help here.
@Carsten Hülsmann Welcome to the Atlassian community
I am wondering if you are having the same issue as described here: https://community.atlassian.com/t5/Jira-Service-Management/Unable-to-verify-sending-email-domain-via-DNS/qaq-p/1911085
Atlassian was having an issue but it has been fixed. Can you follow the steps described by Andy and see if this resolves your issue.
@Brant Schroeder thanks for your reply.
To make sure that this is not the case I removed the domain and re-added it in Jira (and used the latest DNS records jira gave me).
This might be related but the entries Jira gives me are setup (all of them). None gets confirmed unfortunately.
And I'm not sure what he means with "Please refresh the DNS check". Is this just to check the entries again? This always results in the email that it couldn't be validated.
@lucas_dias The service is operational. I can see that you now have a support ticket created for this problem. That is the best place to address this concern.
From a quick look at your domain, it appears that your TTL (time-to-live) values are extremely short (60). This can be a problem as the record that our service will obtain will likely expire before we can use it. This is why we recommend setting the TTL to a value such as 86400. Our service is only expected to check these records once every 24 hours unless triggered manually.
Try adjusting that value and then wait for the records to propagate. I'd recommend following up in your support case for additional help specific to your environment/domain.
Same problem just popped up for us. Last good check was yesterday, failing today, manually triggered the check, failed. Got a ticket in to our IT to be sure they didn't change anything on the DNS settings. Wonder if this is an Atlassian outage as described above. I have a support ticket in with Atlassian.
I am facing similar problem. The difference is tha 4 of 5 DNS records values were verified by Atlassian server.
Only TXT (SFP) value is missing, the remaining 4 were verified. I retried to entry, reboot, and run the DNS check several times with the same result.
This is the value of the record.
Does anyone has a route couse to solve this?
Thanks in advance.
On the above issue (specifically the TXT / SPF record), there's further documentation, but, you need to either:
v=spf1 include:_spf.atlassian.net -all
If you already have one of these, just make sure the `include:_spf.atlassian.net` is in the middle of it (before the `-all`)
We are having the same problem where initially all records verified and then all of a sudden two of the 5 no longer verified (including our SPF record) and now we can't get them to verify anymore. Absolutely ridiculous. Atlassian is garbage when it comes to issues like that. Support is completely useless