Spoofability verdict for aldi.com
Yes - aldi.com is spoofable today.
See the math
Aldi.com has an unusual and dangerous configuration: SPF explicitly rejects all mail (v=spf1 -all), yet there's no DMARC policy to enforce this rule or tell receivers what to do when it's broken.
- SPF with -all hardfail: The domain correctly rejects all unauthenticated mail—no legitimate email should claim to come from aldi.com unless it passes SPF. This is the strongest possible SPF stance.
- DMARC policy missing: Without a DMARC policy, receivers don't know whether to trust the SPF rule. Many email providers (Gmail, Outlook, some corporate filters) default to permissive behaviour when DMARC is absent, even if SPF would reject the mail.
- DKIM not present: No DKIM selectors found in probing 22 common selector names. This removes a second authentication path that could reinforce the SPF block. Aldi relies entirely on SPF alone.
- MTA-STS missing: No MTA-STS policy found. This doesn't directly enable spoofing, but it means incoming mail servers can't be forced to use TLS—a secondary hardening measure.
What this means practically
An attacker can send email claiming to be from aldi.com and it will reach inboxes—despite SPF being set to -all. Here's why: Gmail, Outlook, and many corporate mail filters often ignore SPF in the absence of DMARC. The attacker's server doesn't need to pass SPF authentication; it simply delivers a message with a forged From: header. The receiver's mail filter sees no DMARC policy directing it to reject the message, so it lands in the inbox or spam folder depending on other content signals. Employees and customers will see "aldi.com" as the sender and may click malicious links or divulge information.
Bottom line: Aldi has the right SPF rule but no DMARC policy to enforce it—the spoofability door remains wide open in practice.
What we measured
Open
DMARC policy
missing
No DMARC record found. Receivers have no policy to apply.
Enforced
SPF posture
-all (hardfail)
SPF ends in -all (hardfail). Receivers reject mail from IPs not in the policy.
v=spf1 -all
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
- Publish a DMARC record. Start at p=none with a rua= report destination to gather data, then progress to p=quarantine and p=reject.
- 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.