Unable to verify email dns settings

[Carsten Hülsmann]

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.

[Andy Heinzer · Accepted solution]

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. 

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

[Carsten Hülsmann]

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

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

[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]

@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

include:_spf.atlassian.net

value within the SPF. For example, you have the first two IP records of

"v=spf1 ip4:206.220.240.167 ip4:206.220.240.165

These could be cut down to a single record such as

ip4:206.220.240.164/30

Which would provide a single record lookup for the 4 IP addresses of 206.220.240.164 - 206.220.240.167

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.

[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]

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

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

[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? 

[Andy Heinzer]

My reply regarding the 60 TTL value was concerning Lucas' environment, not your environment, Gregory.

[Nathan Sturgess]

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. 

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

[Deleted user]

Hi

   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]

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

[Chris Dunne _Raledo_]

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

[Nathan Sturgess]

Same here. Everything but the TXT will confirm.

[Nathan Sturgess]

 ..

[LUIS ROLDAN]

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. 

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

[Michael Reiserer]

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

[Gregory Muir]

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