huggingface.co
DMARC is monitoring only, so spoofed mail still reaches inboxes. The reports are the path forward.
4 of 8 checks pass · 4 tools visible in DNS · nothing urgent
1 · Authentication and transport
SPF
PassValid, soft failAnything not on the list is accepted but marked. Google recommends ~all; with DMARC enforced it is as strong as -all.
v=spf1 include:spf.mailjet.com include:_spf.google.com include:amazonses.com include:mail.zendesk.com ~all
DKIM
Pass3 keys foundSelectors google, k2, k3 publish a public key. 2 of them point at a vendor by CNAME.
google._domainkey, k2._domainkey, k3._domainkey
DMARC
ReviewMonitoring only (p=none)Failing mail is delivered as normal. You get reports, receivers get no instruction.
v=DMARC1; p=none; sp=none;rua=mailto:dmarc@huggingface.co; pct=100; adkim=r; aspf=s
- Policy is p=none (monitoring only). Spoofed mail can still reach inboxes.
MX
Pass5 hostsMore than one receiving server, so a single outage does not bounce mail.
10 aspmx.l.google.com 20 alt1.aspmx.l.google.com 30 alt2.aspmx.l.google.com 40 alt3.aspmx.l.google.com 50 alt4.aspmx.l.google.com
MTA-STS
ReviewNot publishedSending servers cannot tell that this domain requires TLS, so inbound mail can be downgraded to plain text by anyone on the path.
TLS-RPT
OptionalNot publishedNobody is told when TLS to this domain fails. Cheap to add once MTA-STS is in place.
BIMI
OptionalNot publishedOptional, and it requires DMARC at quarantine or reject first.
DNSSEC
PassValidatedThe resolver validated the zone, so the records above cannot be silently swapped in transit.
2 · Tools visible in DNS
| Layer | Tool | Evidence |
|---|---|---|
| Mailbox | Google Workspace | MX aspmx.l.google.com |
| Transactional | Amazon SES | SPF include:amazonses.com |
| Transactional | Mailjet | SPF include:spf.mailjet.com |
| Support | Zendesk | SPF include:mail.zendesk.com |
Only tools that leave a DNS trace appear. A shared DKIM selector is attributed only when its CNAME target names the vendor.
3 · Sender requirements (Google, Yahoo, Microsoft)
| Requirement | Applies to | Status | Note |
|---|---|---|---|
| Authenticate with SPF or DKIM | GoogleYahooMicrosoft | Verified | At least one method is in place. |
| Bulk senders: both SPF and DKIM | GoogleYahoo | Verified | Both are present. |
| Publish a DMARC record (p=none is enough) | GoogleYahooMicrosoft | Verified | Policy is p=none. |
| From: domain aligns with SPF or DKIM | GoogleYahooMicrosoft | Not checkable here | Needs a real message. The Send-a-Test report will check this. |
| Valid forward and reverse DNS for sending IPs | GoogleYahoo | Not checkable here | Depends on the sending server, not the domain. |
| Encrypt in transit (TLS) | GoogleYahoo | Not checkable here | Outbound TLS depends on your sending tool; MTA-STS would cover inbound. |
| One-click unsubscribe (RFC 8058) for marketing mail | GoogleYahoo | Not checkable here | A message header, not a DNS record. Microsoft recommends it rather than requiring it. |
| Spam complaint rate under 0.1% (0.3% is the hard limit) | GoogleYahoo | Not checkable here | Read it in Google Postmaster Tools and Yahoo Sender Hub. Google’s target is 0.1%; 0.3% is where enforcement starts. |
4 · What to fix, in order
-
P2
Move DMARC from monitoring to enforcement
p=none protects nothing. Once your legitimate senders pass, step up gradually.
Publish at_dmarc.huggingface.cov=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@huggingface.co; fo=1
-
P3
Publish MTA-STS (record and policy file)
Tells sending servers to require TLS to your MX hosts, which prevents downgrade attacks. The TXT record alone does nothing: the policy file must be served over HTTPS at mta-sts.huggingface.co. Start in testing mode, watch TLS-RPT, then switch to enforce.
Publish at_mta-sts.huggingface.co and https://mta-sts.huggingface.co/.well-known/mta-sts.txtTXT v=STSv1; id=2026100401 mta-sts.txt: version: STSv1 mode: testing mx: aspmx.l.google.com mx: alt1.aspmx.l.google.com mx: alt2.aspmx.l.google.com mx: alt3.aspmx.l.google.com mx: alt4.aspmx.l.google.com max_age: 86400
-
P3
Publish TLS-RPT
You get a report when TLS delivery to your domain fails; this is what notices a downgrade that MTA-STS is meant to prevent. The address must exist.
Publish at_smtp._tls.huggingface.cov=TLSRPTv1; rua=mailto:tls-rpt@huggingface.co
Appendix · Raw DNS answers
| Name | Type | Answer |
|---|---|---|
| huggingface.co | MX | 10 aspmx.l.google.com 20 alt1.aspmx.l.google.com 30 alt2.aspmx.l.google.com 40 alt3.aspmx.l.google.com 50 alt4.aspmx.l.google.com |
| huggingface.co | A | 99.86.147.94 99.86.147.108 99.86.147.32 99.86.147.65 |
| huggingface.co | TXT | v=spf1 include:spf.mailjet.com include:_spf.google.com include:amazonses.com include:mail.zendesk.com ~all (+ 20 other TXT records: site-verification tokens and the like, omitted) |
| _dmarc.huggingface.co | TXT | v=DMARC1; p=none; sp=none;rua=mailto:dmarc@huggingface.co; pct=100; adkim=r; aspf=s |
| <selector>._domainkey.huggingface.co | TXT | google → key published k2 → CNAME dkim2.mcsv.net k3 → CNAME dkim3.mcsv.net |
| _mta-sts.huggingface.co | TXT | no record |
| _smtp._tls.huggingface.co | TXT | no record |
| default._bimi.huggingface.co | TXT | no record |