nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unable to verify email dns settings

Carsten Hülsmann_27sugt

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.

Accepted answers

Andy Heinzer

Hi @Carsten Hülsmann

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.

Screen Shot 2022-01-20 at 12.25.30 PM.png

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.

Andy

All comments

Brant Schroeder

@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.

Carsten Hülsmann_27sugt

@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.

Brant Schroeder

@Carsten Hülsmann Let me see if I can get someone from Atlassian to take a look.

Andy Heinzer

Hi @Carsten Hülsmann

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.

You can force a recheck by going to admin.atlassian.com > select the site/organization in question > Settings > Emails > email domains > See DNS records.

Screen Shot 2022-01-20 at 12.25.30 PM.png

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.

Andy

Carsten Hülsmann_27sugt

@Andy Heinzer thanks a lot for your feedback and help. I was now able to check the records properly. No further investigation or remove/re-add required

Appreciate your support!

Michael Reiserer_comhmi

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

LUIS ROLDAN_ljv7ak

Hi guys,

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.

include:_spf.atlassian.net

Does anyone has a route couse to solve this?

Thanks in advance.

Chris Dunne _Raledo_

I am having the exact same problem as described by Luis Roldan. Has anyone found a solution?

samuelmurphy-pw

Hi Luis--did you ever get a resolution (no pun intended) to this? I'm having the same issue.

G. Maciolek

On the above issue (specifically the TXT / SPF record), there's further documentation, but, you need to either:

Integrate the record with your existing SPF record (which will start with e.g. `v=spf1` OR
Create a new TXT record, as below

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`)

unknown

Did anyone get any resolution out of this? All the Txt and Cname records are in my domain provider as given by Atlassian and no matter what non of them show verified.

Looking for suggestions.

Thank you
Vamshi

Gregory Muir

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.

Gregory Muir

How long did it take to get resolved for you, if ever? I'm here for the same problem.

Gregory Muir

This just hit us today. Did you get a resolution?

Gregory Muir

Hey, do you know if we have another known outage? Just encountered it here, did the manual request for a check again and it's still failing. I do have a support ticket in.

Nathan Sturgess_r7m0sp

Same here. Everything but the TXT will confirm.

Nathan Sturgess_r7m0sp

Ok so I found that I had 2 TXT records:

TXT @ atlassian-sending..etc

TXT domain_name atlassian-sending..etc

Deleting the one with @ resulted in it working for the TXT entry.

lucas_dias

Same thing happening here, all the four records are not being checked. @Andy Heinzer , do you know if there's anything happening to the service?

Gregory Muir

We are still waiting for a resolution from them. Everything is set correctly on our end and the service is working so it appears to be a false alarm but they've still not managed to track down why it's triggering incorrectly.

Gregory Muir

@Andy Heinzer This has been an ongoing issue for us. Have an open ticket with no resolution. Been going on since October. Any idea what the issue is?

Andy Heinzer

@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.

Gregory Muir

The record was adjusted. Are you saying it's still showing the lower 60 value? This was confirmed last week.

Is it possible that it's not polling accurately?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

atl-rvw

jira-service-management