Good, with 2 things to fix

atlassian.net scored 84/100 (grade B). The main issues are DKIM key shorter than 2048 bits and MX: mail relies on implicit A record. Detected senders: Amazon SES.

Checked 2026-10-04 02:11 UTC · fresh check

2 passed2 need attention0 failing4 for informationDetected senders: Amazon SES

All checks

MXCan servers find your inbox?Mail relies on implicit A recordNeeds attention

Warning: Mail relies on implicit A record
atlassian.net has no MX records, so senders fall back to its A/AAAA address (RFC 5321 implicit MX). Publish an explicit MX record, or a null MX ("0 .") if the domain should not receive mail.

SPFWho may send as you?No issues foundPass

Nothing to report.

DKIMAre your emails signed?DKIM key shorter than 2048 bitsNeeds attention

Warning: DKIM key shorter than 2048 bits
s2 (1024-bit) uses an RSA key below 2048 bits. Short keys can be factored and some receivers treat them as weak. Rotate to a 2048-bit key at your sending provider.
Pass: DKIM key published
atlassian.net publishes a DKIM key under s1, s2.

DMARCWhat happens to fakes?No issues foundPass

Nothing to report.

AlignmentDoes it match your From?SPF alignment depends on a custom Return-PathInfo

Info: SPF alignment depends on a custom Return-Path
This is a heuristic. Your SPF record only authorizes third-party senders (amazonses.com). By default they bounce from their own Return-Path domain, and SPF then passes for that domain, not atlassian.net. Even relaxed alignment needs the Return-Path's organizational domain to be atlassian.net, so set up a custom Return-Path (bounce) domain under atlassian.net with each provider, and sign with DKIM as atlassian.net.

BIMICan inboxes show your logo?No BIMI recordInfo

Info: No BIMI record
No BIMI record at default._bimi.atlassian.net. BIMI is optional: it shows your logo next to your mail in supporting inboxes once DMARC is enforced.
How to fix this

MTA-STSIs mail to you encrypted?No MTA-STS recordInfo

Info: No MTA-STS record
No MTA-STS record at _mta-sts.atlassian.net. MTA-STS (RFC 8461) makes sending servers require TLS and a valid certificate when delivering to you, which blocks downgrade attacks.

TLS-RPTWill you hear about failures?No TLS-RPT recordInfo

Info: No TLS-RPT record
No TLS reporting record at _smtp._tls.atlassian.net. TLS-RPT (RFC 8460) tells senders where to send daily reports about failed encrypted deliveries to you.
How to fix this

How to fix it

Set up a TLS report addressinstruction

Sending servers will report TLS failures when delivering to atlassian.net, which you need before enforcing MTA-STS. The address must accept TLS reports; a DMARC report address does not necessarily do so.

Applies to: _smtp._tls.atlassian.net

Pick an address that will receive TLS reports: a mailbox you read (for example tls-reports@atlassian.net, created first) or a TLS reporting service. 2. Publish a TXT record at _smtp._tls.atlassian.net with the value v=TLSRPTv1; rua=mailto:<that address>.

Prepare BIMIinstruction

BIMI shows your logo next to messages in supporting inboxes, but only for mail that passes DMARC under an enforced policy.

Applies to: default._bimi.atlassian.net

Enforce DMARC first: p=quarantine or p=reject at 100% (no pct below 100). 2. Convert your logo to an SVG Tiny PS file and host it over HTTPS, for example https://atlassian.net/bimi/logo.svg. 3. For Gmail and Apple Mail, obtain a VMC or CMC certificate for the logo. 4. Publish a TXT record at default._bimi.atlassian.net with v=BIMI1, l= set to the logo URL and a= set to the certificate URL.