Spoofability verdict for meta.com
Maybe - meta.com is partially protected.
See the math
Meta has implemented DMARC reject at meta.com, which blocks the most common spoofing vector—but the foundation underneath is shakier than it appears. SPF redirect without explicit qualification, missing DKIM selectors, and no MTA-STS transport protection leave real gaps.
- DMARC policy=reject at 100%: DMARC reject is the strongest policy setting and applies to all outbound mail from meta.com. This prevents most receivers from accepting spoofed messages claiming to come from this domain, assuming SPF/DKIM alignment.
- SPF redirect to _spf.fb.com (no qualifiers): The SPF record uses a redirect mechanism without an explicit pass/fail qualifier. This is ambiguous—SPF evaluators interpret an unqualified redirect as a soft fail or neutral, which means SPF alignment for DMARC may not trigger as intended.
- DKIM: no selectors found: Despite probing 22 common selector patterns, no DKIM records were present at meta.com. This means outbound mail cannot be cryptographically signed by this domain, breaking DKIM alignment and forcing DMARC to fall back entirely on SPF.
- MTA-STS: missing: MTA-STS prevents downgrade attacks on the SMTP connection itself. Its absence means the transport between mail servers is not protected against interception, though this is a secondary concern if the primary authentication layer holds.
What this means practically
An attacker spoofing meta.com will likely be rejected if the SPF redirect resolves correctly and the receiving mail server strictly enforces DMARC alignment—which many do. However, if the redirect qualifier is misinterpreted by a receiver's parser, or if the attacker can control a server in _spf.fb.com's range, the check may pass. The absence of DKIM removes a second authentication lane: even a perfectly aligned SPF doesn't prevent the mail from being re-routed or modified in transit. MTA-STS omission allows man-in-the-middle attackers to downgrade the connection to plaintext SMTP, though this requires network-level access.
Context for Meta
Meta is a large technology company with complex mail infrastructure spanning multiple properties (Facebook, Instagram, WhatsApp). The redirect pattern suggests they may be intentionally centralizing SPF at _spf.fb.com; however, this choice trades clarity for opacity, and the lack of DKIM on the meta.com domain itself is unusual for an organization of this scale.
Bottom line: Meta.com's DMARC reject policy is strong on paper, but the SPF redirect ambiguity and missing DKIM coverage mean the policy depends on a single, fragile signal—and leaves mail in flight unprotected.
What we measured
Enforced
DMARC policy
p=reject
DMARC at p=reject (pct=100). Spoofed mail is rejected at SMTP.
Partial
SPF posture
?all (neutral)
SPF record present but has no terminal mechanism. Behaviour at receivers is unspecified.
v=spf1 redirect=_spf.fb.com
Open
DKIM presence
no key found at common selectors
No DKIM key found at any of the 22 common selectors. (Your domain may publish a DKIM key at a less-common selector - this is a heuristic, not exhaustive.)
Open
MTA-STS (transport)
missing
No MTA-STS policy. Inbound mail can be intercepted via DNS / MX downgrade.
How to make it un-spoofable
- Confirm DKIM is configured. We didn't find a key at the common selectors; if you do publish DKIM, the selector you use isn't in our probe list - that's fine, but worth verifying with your mail provider.
- Publish an MTA-STS policy in enforce mode + a TLS-RPT reporting endpoint.