DMARC DNS record checks continue to fail

[Werner van der Walt]

Hi,

I am trying to setup JSM to send replies using an email from my domain.  I followed the steps as descirbed in https://community.atlassian.com/t5/Jira-Service-Management-articles/Doing-Jira-Service-Management-Customer-Notifications-Right/ba-p/1877664 and other articles.

The DMARC records was added to our DNS.  I added an _dmarc TXT records as well, as it was originally missing.   As a starting point the _dmarc record action is set to none.

It is now more than 48h and the Atlassian Admin DNS record checks are continuing to fail.

Looking at MXToolbox I can confirm the _dmarc record is visible.  Can also see the TXT record added.  The CName records are not shown.

(DNS is hosted with GoDaddy)

How can I find out what the problem is and why the DNS record checks are failing and what to do to get it working?

[Paul Wiggers]

DNS is always hard to solve but let's give it a go

• Have you copy / pasted all the records from your JSM instance into GoDaddy?
• Is everything failing or just some checks?
• Do you mind sharing your domainname so I can compare those settings to our domain?
• DMARC is not required for the custom domain usage in Atlassian. However, it is still a good idea to set it up.

[Werner van der Walt]

Hi @Paul Wiggers,

1. Yes, I did.  Verified it a second time as well.

2. All items are marked as failed

3. mavensysworx.com

4. Noted.

I logged a similar query at GoDaddy as well to get feedback from there, should it be more an issue on their side.  Feedback that I got is that it might be related to JSD Notification were not sent out due to failed DMARC/Marked as SPAM. Add option to control the Reply-To: header in Jira Cloud.

This ticket is however closed, even though the request was to upvote it and watch it.

[Paul Wiggers]

Thanks for that, it currently looks like you are missing the atlassian entry for your SPF record.

Please add " include:_spf.atlassian.net" unto your current record. Right now it only allows secureservice.net

This would mean that your SPF record should look like:

 v=spf1 include:secureserver.net include:_spf.atlassian.net -all

[Werner van der Walt]

The record was updated. Sadly still having the same situation.

[Paul Wiggers]

To be honest, it looks like the information in your records is incorrect. I would suggest removing them and retry.

For example, the TXT record for your domain contains the value

atlassian-domain-verification=

My records, and the records given in the article, start with

atlassian-sending-domain-verification=

Please, double-check all the information. Don't try to manually type it but use the copy/paste function in the DNS settings window to get the information that you need.

[Werner van der Walt]

There is two TXT records.

The one

atlassian-domain-verification=

 is used for the domain verification for domain based account management.  The 2nd TXT records is also configured,  But what I have now realized is that using MXToolbox and dig I only see the TXT records that contains "@" as the name.

There are 3 TXT records, including the atlassian-sending-domain-verification TXT records that is either not propagated or not shown by the various DNS tools. Trying to work out why this is happening.

For the CNAME reocrds, the full domain name is added as part of the record name.   Based on some other messages it seems that GoDaddy might be adding the domain name onto the CNAME record name by default.  I have now removed the domain name from the record names.  Will see if this will make a difference.

[Keith Jones]

Did you ever get this resolved? We are having the same issues trying to set up DMARC.

[Werner van der Walt]

Hi Keith,

No, still have the issue from Atlassian side.  Reports I get from other suppliers, seems to suggest the basic setup is working as I get reports indicating dkim and spf pass or in some instances fail (depending on the email source and their configuration).

From Atlassian side I still get the errors indicating they cant confirm the DNS records