Security Spot-Checks
Is a company's email domain protected against spoofing?
A domain is protected against spoofing only when it enforces DMARC. SPF and DKIM authenticate mail, but DMARC with p=quarantine or p=reject is what blocks a forged From address. Bassethound reads all three from DNS in one keyless call, inside the five-layer dossier.
Best move: read the DMARC policy, not just whether SPF and DKIM exist.
Why it works: SPF and DKIM authenticate the plumbing, but only an enforcing DMARC policy (p=quarantine or p=reject) tells receivers to drop mail that forges your From address. All three records live in public DNS, so one lookup answers the question.
Key takeaways
- SPF and DKIM alone do not stop From-address spoofing. DMARC alignment plus an enforcing policy does.
- DMARC at p=none is monitor-only. It reports abuse but blocks nothing.
- All three signals live in public DNS TXT records, so the check needs no mail sent and no key.
- A presence boolean (DMARC: yes) is necessary but not sufficient. The p= value decides real protection.
- Bassethound returns SPF/DKIM/DMARC presence in the infrastructure layer of the same dossier that carries the tech stack and AI readiness.
What does each of the three records stop?
Three records, three jobs. SPF (RFC 7208) publishes the IP addresses allowed to send mail for your domain in a TXT record. A receiver checks the connecting server against that list. SPF validates the envelope sender, the address used in the SMTP conversation, not the From line a human reads.
DKIM (RFC 6376) attaches a cryptographic signature to each message and publishes the public key in DNS. A receiver recomputes the signature and confirms the body and signed headers arrived unaltered. DKIM proves integrity and origin, but on its own it does not force the signing domain to match the visible From.
DMARC (RFC 7489) closes that gap. It requires that a passing SPF or DKIM result align with the From domain, and it publishes a policy telling receivers what to do when alignment fails. SPF stops an unauthorized server. DKIM stops a tampered message. DMARC stops a forged From address, the spoof a phishing target sees. Miss any one and you have a gap. Publish all three with alignment and enforcement and the forged-sender attack has nowhere to land.
Why does the DMARC policy word decide whether you are protected?
DMARC carries a policy tag, p=, with three settings, and the difference between them is the difference between protected and exposed. p=none is monitor mode. The domain owner receives aggregate reports about who sends mail as their domain, but receivers take no action on failures. A domain at p=none publishes DMARC and blocks nothing. p=quarantine tells receivers to treat failing mail as suspicious, usually routing it to spam. p=reject tells receivers to drop it at the door. Only quarantine and reject stop a spoofed message from reaching an inbox.
This is why a presence check misleads. A scanner that reports DMARC: yes counts a p=none record the same as a p=reject record, and the two do not protect a domain to the same degree. Reading the p= value, plus the alignment mode (strict or relaxed) and any subdomain policy (sp=), turns a yes/no into a real verdict. Many domains that publish DMARC sit at p=none for months, gathering reports and never enforcing. That is a domain in progress, not a domain protected. The word in the record, not the record’s existence, is the answer.
Can you check spoofing protection without sending a single email?
Yes. Every signal lives in public DNS. SPF is a TXT record on the domain apex starting v=spf1. DMARC is a TXT record at _dmarc.
So SPF and DMARC give you a clean read every time, and DKIM presence is inferable from a message header or a known selector, reported as such. The records are public and read-only, so the check is fast, keyless, and safe to run against any domain without touching its mail flow. That is the whole point of a spot-check. You want a verdict on a domain you do not control, and you want it without probing its servers. A DNS read gives you SPF and DMARC with certainty and flags DKIM as the one that may need a header sample to confirm.
What does a presence check miss?
A booleans-only read tells you the records exist. It does not tell you they enforce. Five things hide behind a green checkmark. The DMARC p= value, which separates monitoring from blocking. The subdomain policy sp=, since a strict apex can sit above wide-open subdomains an attacker forges instead. The alignment mode, relaxed or strict, which changes what counts as a pass. DKIM selector state and key length, since a live record can point at a weak or retired key. And the SPF lookup count, capped at ten DNS lookups by RFC 7208, past which SPF returns permerror and fails open.
Bassethound reports SPF, DKIM, and DMARC presence in the infrastructure layer as fast triage, and it says plainly that presence is the start of the check, not the end. For a real protection verdict you read the policy tags, and the dossier points you at them. This is the honest-limits posture across the whole tool. A static read is cheap and fast, and it tells you where it stops.
How do you spot-check spoofing protection across a whole list?
One call per domain, correlated with everything else. sniff_domain returns SPF, DKIM, and DMARC in the infrastructure layer of the same dossier that carries the tech stack, firmographics, AI readiness, and a security grade. So a spoofing spot-check is never a lone data point. A domain that publishes no DMARC and runs a live checkout is a different risk than the same gap on a parked page. A spoofable domain next to a shipping AI stack is a different lead than a spoofable domain on a dead site.
Because the call is keyless and stateless, you run it across a target list from an agent host without provisioning keys or storing state between requests. Each call is self-contained. For a security spot-check you take the email-auth booleans as a first pass, then escalate to the deep profile for the security header grade and TLS grade when a domain warrants a closer look. The correlation is the reason to read all five layers at once instead of stitching a mail-auth checker to four other tools.
Bassethound perspective
Most spoofing-protection checkers count records. They print a green checkmark next to DMARC and call the domain safe. That is a lie of omission, because the record that matters most so often sits at p=none, and p=none blocks nothing. A scanner that scores presence rewards the domain that started the project over the domain that finished it, and those are not the same risk. Read the policy or do not claim protection. That is the conviction.
The second one is about shape. A spoofable email domain is a fact, but a weak fact alone. It becomes a lead when you see it next to what the domain runs: whether it takes payments, whether it ships an AI stack, whether its TLS certificate expires next week. Bassethound returns the email-auth read inside the five-layer dossier, in one keyless call, so the spoofing gap arrives already correlated with the stack, the firmographics, and the security grade. An agent cannot cheaply reconstruct that correlation from a mail-auth tool plus four others. Fusion is the moat. The email check is one honest layer of it.
Sources
- SPF, RFC 7208: https://datatracker.ietf.org/doc/html/rfc7208
- DKIM, RFC 6376: https://datatracker.ietf.org/doc/html/rfc6376
- DMARC, RFC 7489: https://datatracker.ietf.org/doc/html/rfc7489
Frequently asked questions
Does having SPF and DKIM mean a domain is safe from spoofing?
No. SPF and DKIM authenticate the sending server and the message, but only DMARC with alignment and an enforcing policy stops a forged From address. A domain with SPF and DKIM but no DMARC is still spoofable in the From line.
What is the difference between DMARC p=none, p=quarantine, and p=reject?
p=none monitors and reports but blocks nothing. p=quarantine tells receivers to treat failing mail as suspicious, usually routing it to spam. p=reject tells them to drop it. Only quarantine and reject protect an inbox.
Can you check spoofing protection without access to the domain's mail servers?
Yes. SPF and DMARC are public TXT records read with a single DNS lookup each. No mail sent, no key, no access needed. DKIM presence may need a message header or a known selector to confirm.
Why does Bassethound report SPF, DKIM, and DMARC as booleans?
Booleans are the fast triage in the infrastructure layer. They answer whether each record exists in one call. For a real protection verdict you read the DMARC p= value, and the dossier flags presence as the start of that check, not the end.
Where does the email-auth check sit in the dossier?
In the infrastructure layer, alongside IP, ASN, CDN, nameservers, MX records, and the TLS certificate. It arrives correlated with the tech stack, firmographics, AI readiness, and security grade from the same keyless call.