github.com SPF TXT record is inconsistent across authoritative nameservers — causing SPF permerror on ~75% of DNS queries

[orenTalmorMH]

Summary

I've confirmed that the github.com SPF TXT record exists in three different, incompatible formats across GitHub's 8 authoritative nameservers. Approximately 6 out of 8 servers serve either a syntactically broken or completely missing SPF record, causing SPF permerror for any mail system that queries those servers. This is affecting delivery of GitHub notification emails in production environments.

---

Reproduction

Run this against all authoritative nameservers directly:

for ns in $(dig NS github.com +short); do
  echo "--- $ns ---"
  dig TXT github.com @"$ns" +short | grep -i spf
done

Actual output (github.dig.txt — attached):

--- dns4.p08.nsone.net. ---
"v=spf1" "ip4:192.30.252.0/22" "include:spf.protection.outlook.com" "include:_netblocks.google.com" "include:_netblocks2.google.com" "include:_netblocks3.google.com" "include:mail.zendesk.com" "include:_spf.salesforce.com" "include:servers.mcsv.net" "include:mktomail.com" "ip4:62.253.227.114" "ip4:166.78.69.169" "ip4:166.78.69.170" "ip4:166.78.71.131" "ip4:167.89.101.2" "ip4:167.89.101.192/28" "ip4:192.254.112.60" "ip4:192.254.112.98/31" "ip4:192.254.113.10" "ip4:192.254.113.101" "ip4:192.254.114.176" "~all"
--- ns-1707.awsdns-21.co.uk. ---

(no SPF record returned)
--- ns-1283.awsdns-32.org. ---

"v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com ip" "4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ip4:167.89.101.2 ip4:167.89.101.192/28 ip4:192.254.112.60 ip4:192.254.112.98/31 ip4:192.254.113.10 ip4:192.254.113.101 ip4:192.254.114.176 ~all"
--- dns1.p08.nsone.net. ---

(same broken format as dns4)
--- dns3.p08.nsone.net. ---

(same broken format as dns4)
--- ns-421.awsdns-52.com. ---

(no SPF record returned)
--- ns-520.awsdns-01.net. ---

(same valid format as ns-1283)
--- dns2.p08.nsone.net. ---

(same broken format as dns4)

---

Root Cause

GitHub's DNS is split across two providers: NSOne (dns1–4.p08.nsone.net) and AWS Route53 (ns-.awsdns-). The SPF record is in three distinct states:

❌ NSOne — 4/8 servers — BROKEN

Each SPF mechanism is a separate TXT character-string:

"v=spf1"  "ip4:192.30.252.0/22"  "include:spf.protection.outlook.com"  ...  "~all"

Per RFC 7208 §3.3, SPF evaluators concatenate multi-string TXT records directly, without any implicit separator. Concatenation yields:

v=spf1ip4:192.30.252.0/22include:spf.protection.outlook.com...

No whitespace between any tokens. No conforming SPF parser can evaluate this. Result: permerror.

✅ AWS Route53 (ns-1283, ns-520) — 2/8 servers — VALID

Record stored as two long strings properly split at ~255 bytes, with space delimiters preserved. Concatenation produces a valid SPF string.

❌ AWS Route53 (ns-1707, ns-421) — 2/8 servers — MISSING

No SPF TXT record returned at all. Result: permerror or neutral.

---

Impact

Servers	Count	SPF outcome for recipients
NSOne dns1–4	4/8	permerror — unparseable record
AWS Route53 ns-1283, ns-520	2/8	Pass
AWS Route53 ns-1707, ns-421	2/8	permerror / neutral — no record

~75% of resolvers will get a broken or missing record depending on which authoritative server they hit. Any organisation enforcing SPF will intermittently quarantine or reject GitHub notification emails (Actions, Dependabot, security alerts, PR comments).

---

Required Fix

1. Fix the NSOne zone: store the SPF record as properly spaced multi-string TXT, not as one string per mechanism
2. Populate the missing SPF record on ns-1707.awsdns-21.co.uk and ns-421.awsdns-52.com
3. Validate with an SPF linter and confirm all 8 authoritative servers return an identical, valid record

References:

• RFC 7208 §3.3 (SPF TXT record encoding): https://www.rfc-editor.org/rfc/rfc7208#section-3.3
• RFC 1035 §3.3 (255-byte TXT string limit): https://www.rfc-editor.org/rfc/rfc1035#section-3.3
• MXToolbox SPF check: https://mxtoolbox.com/SuperTool.aspx?action=spf%3agithub.com&run=toolpage

Attachment: github.dig.txt

# GitHub Community Forum Post

Category: Infrastructure / Email & Notifications
Title: Bug: github.com SPF TXT record is inconsistent across authoritative nameservers — causing SPF permerror on ~75% of DNS queries

---

Summary

I've confirmed that the github.com SPF TXT record exists in three different, incompatible formats across GitHub's 8 authoritative nameservers. Approximately 6 out of 8 servers serve either a syntactically broken or completely missing SPF record, causing SPF permerror for any mail system that queries those servers. This is affecting delivery of GitHub notification emails in production environments.

---

Reproduction

Run this against all authoritative nameservers directly:

for ns in $(dig NS github.com +short); do
  echo "--- $ns ---"
  dig TXT github.com @"$ns" +short | grep -i spf
done

Actual output (github.dig.txt — attached):

--- dns4.p08.nsone.net. ---
"v=spf1" "ip4:192.30.252.0/22" "include:spf.protection.outlook.com" "include:_netblocks.google.com" "include:_netblocks2.google.com" "include:_netblocks3.google.com" "include:mail.zendesk.com" "include:_spf.salesforce.com" "include:servers.mcsv.net" "include:mktomail.com" "ip4:62.253.227.114" "ip4:166.78.69.169" "ip4:166.78.69.170" "ip4:166.78.71.131" "ip4:167.89.101.2" "ip4:167.89.101.192/28" "ip4:192.254.112.60" "ip4:192.254.112.98/31" "ip4:192.254.113.10" "ip4:192.254.113.101" "ip4:192.254.114.176" "~all"

--- ns-1707.awsdns-21.co.uk. ---
(no SPF record returned)

--- ns-1283.awsdns-32.org. ---
"v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com ip" "4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ip4:167.89.101.2 ip4:167.89.101.192/28 ip4:192.254.112.60 ip4:192.254.112.98/31 ip4:192.254.113.10 ip4:192.254.113.101 ip4:192.254.114.176 ~all"

--- dns1.p08.nsone.net. ---
(same broken format as dns4)

--- dns3.p08.nsone.net. ---
(same broken format as dns4)

--- ns-421.awsdns-52.com. ---
(no SPF record returned)

--- ns-520.awsdns-01.net. ---
(same valid format as ns-1283)

--- dns2.p08.nsone.net. ---
(same broken format as dns4)

---

Root Cause

GitHub's DNS is split across two providers: NSOne (dns1–4.p08.nsone.net) and AWS Route53 (ns-.awsdns-). The SPF record is in three distinct states:

❌ NSOne — 4/8 servers — BROKEN

Each SPF mechanism is a separate TXT character-string:

"v=spf1"  "ip4:192.30.252.0/22"  "include:spf.protection.outlook.com"  ...  "~all"

Per [RFC 7208 §3.3](https://www.rfc-editor.org/rfc/rfc7208#section-3.3), SPF evaluators concatenate multi-string TXT records directly, without any implicit separator. Concatenation yields:

v=spf1ip4:192.30.252.0/22include:spf.protection.outlook.com...

No whitespace between any tokens. No conforming SPF parser can evaluate this. Result: permerror.

✅ AWS Route53 (ns-1283, ns-520) — 2/8 servers — VALID

Record stored as two long strings properly split at ~255 bytes, with space delimiters preserved. Concatenation produces a valid SPF string.

❌ AWS Route53 (ns-1707, ns-421) — 2/8 servers — MISSING

No SPF TXT record returned at all. Result: permerror or neutral.

---

Impact

Servers	Count	SPF outcome for recipients
NSOne dns1–4	4/8	permerror — unparseable record
AWS Route53 ns-1283, ns-520	2/8	Pass
AWS Route53 ns-1707, ns-421	2/8	permerror / neutral — no record

~75% of resolvers will get a broken or missing record depending on which authoritative server they hit. Any organisation enforcing SPF will intermittently quarantine or reject GitHub notification emails (Actions, Dependabot, security alerts, PR comments).

---

Required Fix

1. Fix the NSOne zone: store the SPF record as properly spaced multi-string TXT, not as one string per mechanism
2. Populate the missing SPF record on ns-1707.awsdns-21.co.uk and ns-421.awsdns-52.com
3. Validate with an SPF linter and confirm all 8 authoritative servers return an identical, valid record

References:

• RFC 7208 §3.3 (SPF TXT record encoding): https://www.rfc-editor.org/rfc/rfc7208#section-3.3
• RFC 1035 §3.3 (255-byte TXT string limit): https://www.rfc-editor.org/rfc/rfc1035#section-3.3
• MXToolbox SPF check: https://mxtoolbox.com/SuperTool.aspx?action=spf%3agithub.com&run=toolpage

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[M677871]

This looks like a real GitHub-side DNS issue.
If the authoritative nameservers are returning different or malformed SPF TXT records, SPF checks will fail intermittently depending on which server gets queried.

The fix has to be on GitHub’s side: make all authoritative nameservers return the same valid SPF record.

[PhilSym]

Fully agree.
All is correct on route53. On NS1, the SPF does not have any white space between the fields

[M677871]

Thanks for confirming.
If Route53 is correct and NS1 is missing the spaces, then the problem is clearly on GitHub’s authoritative DNS side, not on the client side.
GitHub will need to make the SPF record identical across all authoritative nameservers.

[PhilSym]

We opened a ticket but it seems they don't really care

[PhilSym]

Hi,
we experience the exact same issue. This has a huge disruption on our e2e workflow.
As per our logs, it started last Firday (20th of March) at 6pm NY time.
Do we have any ETA?
Thx for your support
Rgds
Phil

[itxashancode]

Your diagnosis is correct. I ran into this exact issue with another provider when their API auto-split a long TXT record. The DNS provider wrapped each mechanism in quotes but dropped the spaces. RFC 7208 requires direct concatenation, which breaks SPF syntax and triggers a permerror.

This is a provisioning bug on GitHub's side for the NSOne zone. Community Discussions cannot update authoritative DNS. Open a ticket with GitHub Support or email security@github.com. Include your dig output and explicitly mention the NSOne multi-string concatenation failure. If you run GitHub Enterprise, use the enterprise support portal.

For immediate mitigation, configure your inbound mail gateway to downgrade SPF permerrors for github.com to neutral. I am not sure how strict your DMARC policy is, so verify that change does not break your alignment checks. The fix will only happen when GitHub corrects the TXT record format in their NSOne dashboard.

[orenTalmorMH]

Final update - March 26, 2026

GitHub Security confirmed the fix and our SPF failures are resolved. The NSOne servers are fully corrected and our email security is back to normal.

For completeness, the 4 AWS Route53 authoritative servers are still returning no SPF record - so the fix isn't fully deployed across all nameservers. That said, this is now GitHub's operational concern to finish, not a blocker for us.

Thanks to Josh and the GitHub Security team for responding and moving on it. And thanks to everyone who engaged on this thread - hopefully it saved a few teams from chasing a mysterious SPF failure.

If you're still seeing issues, run:

for ns in $(dig NS github.com +short); do
  echo "--- $ns ---"
  dig TXT github.com @"$ns" +short | grep -i spf
done

If your resolver is hitting a Route53 server, you may still see permerror until GitHub completes the fix on that side. Worth checking which NS your resolver queries.

Marking this as resolved from my end. 🙏