Spoofability verdict for github.com
Maybe - github.com is partially protected.
See the math
GitHub has built a reasonable baseline for email authentication, but stopped short of full protection—a "good but not great" posture that leaves room for attack.
- DMARC at p=quarantine (100%): DMARC is configured to quarantine all mail that fails authentication checks. This is a meaningful enforcement step that catches many spoofing attempts before they land in inboxes, though quarantine is less strict than reject.
- SPF with softfail (~all): The SPF record uses softfail rather than hardfail (-all), meaning mail servers are only *suggested* to reject unauthenticated GitHub mail. This is notably lenient for an enterprise platform—softfail serves as a suggestion, not a mandate.
- DKIM at 6 active selectors: GitHub maintains multiple DKIM signing keys (k1, k2, s1, s2, google, selector1), allowing flexible key rotation and backup. This is mature infrastructure that makes spoofed mail harder to forge.
- MTA-STS missing: No MTA-STS policy means mail servers cannot authenticate GitHub's mail infrastructure by certificate. This leaves inbound connections vulnerable to downgrade and man-in-the-middle attacks on the transport layer.
What this means practically
An attacker can realistically impersonate GitHub mail if they control the receiving domain's DNS or mail server—SPF softfail won't stop them. Without MTA-STS, an attacker on the network path can also intercept or modify mail in transit without detection. In practice, Gmail and Microsoft 365 often spam-folder spoofed mail flagged by DMARC quarantine, but determined phishing attacks (especially those targeting non-cloud mail systems) will still get through. This is particularly concerning given GitHub's role in developer supply chains.
Bottom line: GitHub is halfway there: DMARC and DKIM are solid, but SPF softfail and missing MTA-STS leave meaningful gaps for sophisticated attackers.
What we measured
Partial
DMARC policy
p=quarantine
DMARC at p=quarantine. Spoofed mail goes to spam but is not rejected.
Partial
SPF posture
~all (softfail)
SPF ends in ~all (softfail). Receivers may accept but mark mail; not enforced.
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all
Enforced
DKIM presence
found at 6 selectors
DKIM key found at selectors: google, k2, s1, k1, selector1, s2.
Open
MTA-STS (transport)
missing
No MTA-STS policy. Inbound mail can be intercepted via DNS / MX downgrade.
How to make it un-spoofable
- Move DMARC to p=reject pct=100 once your rua reports show no legitimate-sender failures.
- Tighten SPF from ~all (softfail) to -all (hardfail) once you have the list of senders right.
- Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.