Can Someone Spoof Emails From My Domain? (A Practical Guide)
If you send email from your own domain, "can someone spoof me?" is the single most important question to answer honestly — and most security checkers fudge it. This guide explains why a flat average of SPF, DKIM, and DMARC grades hides the real risk, what a true spoofability score looks like, and how to measure yours without the hand-waving. Start free on EdgeDNS — 200 requests/month, no credit card required.
First: what email spoofing actually is
Email spoofing is the act of sending an email that claims — in the visible `From:` header — to come from a domain you don't actually control. Because the original email protocol from 1982 has zero built-in sender verification, this has been trivially possible since before most of the internet existed. A mail server can put anything it wants in the `From:` line. The receiving server has no automatic way to verify the claim.
Modern email relies on three authentication layers bolted on top of the original protocol:
SPF (Sender Policy Framework) — a DNS record listing which servers are allowed to send email as your domain.
DKIM (DomainKeys Identified Mail) — a cryptographic signature on each message proving it was signed by a server that controls your domain's DKIM key.
DMARC — a policy that tells receiving servers what to do when SPF or DKIM fail, and that requires the authenticated domain to align with the visible `From:` domain.
When all three are configured correctly and at enforcement, spoofing your domain becomes very hard. When any of them is misconfigured, misaligned, or absent, spoofing becomes progressively easier — and the relationships between them are non-linear. That non-linearity is the entire subject of this guide.
Spoofability, in one paragraph
Spoofability is a single number — usually 0 to 100 — that estimates how easy it would be for an attacker to send an email that claims to be from your domain and actually lands in somebody's inbox. It's not a protocol grade. It's an outcome grade. A domain with passing SPF, passing DKIM, and DMARC at `p=none` has pretty good protocol grades but extremely high spoofability, because the `p=none` policy tells receivers to deliver failing messages anyway. A flat average of the three grades would call this domain "OK"; an honest spoofability score calls it "nearly defenseless."
A spoofability score is what a threat-modelling exercise produces. A protocol grade is what an individual checker produces. They answer different questions, and conflating them is the single most common mistake in email-security audits.
Why averaging protocol grades hides the truth
Most email-security checkers work like this: grade SPF against its own rules (A through F), grade DKIM against its own rules, grade DMARC against its own rules, then average the three into an overall score. The output is tidy. It's also misleading — because the protocols don't operate independently, and a score that treats them as independent produces the wrong answer.
Concrete example 1: DMARC `p=none` dominates everything. Consider a domain with strict SPF (`v=spf1 include:_spf.google.com -all`), properly-signed DKIM with 2048-bit keys, and DMARC set to `v=DMARC1; p=none; rua=mailto:dmarc@example.com`. A flat-average checker gives this domain A for SPF, A for DKIM, and maybe C for DMARC (because the policy is monitoring-only), averaging to a B. In reality, this domain is nearly as spoofable as a domain with no email authentication at all. Why? Because `p=none` explicitly tells receivers: "even if a message fails SPF alignment and DKIM alignment, deliver it anyway." A spoofed message from a completely unauthorized server reaches the inbox. The B grade is dishonest.
Concrete example 2: permissive SPF + DMARC `p=none` compounds. A domain with `v=spf1 include:*.example-mail-provider.com ~all` (soft-fail) and DMARC `p=none` is compounding-weaker than either alone. The `~all` tells receivers "probably not authentic but maybe deliver anyway," and `p=none` reinforces "and don't reject on DMARC failure either." Two individually-mediocre policies combine into a near-zero defense. A flat average would call it "two Cs so a C overall." The real answer is F.
Concrete example 3: missing DKIM under permissive DMARC. No DKIM signature + DMARC at `p=none` is much worse than no DKIM signature + DMARC at `p=reject`. Under `p=reject`, missing DKIM is survivable (SPF can carry the authentication alone if aligned). Under `p=none`, missing DKIM means a forgery only has to spoof SPF alignment to succeed — and that's often trivially possible through bug-bounty-style infrastructure abuse. Same "missing DKIM" finding, dramatically different spoofability consequences.
The pattern: the interactions between protocols change the meaning of each individual grade. A scoring system that doesn't model the interactions produces false reassurance on about half the domains it audits.
The five interactions that actually matter
A real spoofability score applies interaction multipliers — rules that look at pairs or triples of protocol states and adjust the composite score accordingly. Below are the five that matter most, each borrowed from observed real-world spoofing success patterns and corroborated by academic work including the Princeton DMARC research paper.
Interaction 1: DMARC `p=none` is the dominant signal. When DMARC is in monitoring mode, the strictness of SPF and the presence of DKIM matter less than they would under enforcement. A domain in `p=none` gets a large spoofability penalty regardless of how good SPF and DKIM look in isolation.
Interaction 2: DMARC alignment trumps raw protocol passes. A message can pass SPF and still fail DMARC if the `Return-Path` domain (what SPF authenticates) doesn't align with the visible `From:` domain (what DMARC requires to match). Spoofability scores factor in alignment mode — strict vs relaxed, per-protocol. Domains with `aspf=s` (strict SPF alignment) enforced are meaningfully harder to spoof than domains with the default `aspf=r`.
Interaction 3: DKIM presence amplifies DMARC. A domain with both SPF and DKIM and DMARC at enforcement is categorically harder to spoof than a domain with only SPF and DMARC at enforcement — because the attacker has to pass either SPF or DKIM alignment, and compromising DKIM requires access to a signing key, which is much harder than abusing SPF infrastructure.
Interaction 4: SPF PermError disables SPF entirely. If your SPF record exceeds the RFC 7208 10-DNS-lookup limit, receiving servers produce a PermError — which most of them treat as "SPF not configured." A domain with a well-written SPF record that has crept over 10 lookups has effectively zero SPF protection and is dramatically more spoofable than a domain with a simpler SPF record that stays under the limit.
Interaction 5: subdomain policy matters. Even a domain with `p=reject` on the apex is spoofable at `mail.example.com` unless `sp=reject` is also set. Attackers target the subdomain when the apex is protected. A spoofability score that considers only the apex policy misses this entirely.
Why spoofability beats protocol-by-protocol checks
The case for measuring spoofability instead of individual protocol grades comes down to a simple question: what does the score tell you to do next?
A protocol-by-protocol check produces a grade for each of SPF, DKIM, and DMARC. Somebody looking at the output has to mentally combine the grades into an overall picture — which is exactly the step the flat-average checkers get wrong. The output is informative but not decision-ready.
A spoofability score produces a single number and a ranked list of the fixes that would reduce that number most. "DMARC is at `p=none` — moving to `p=quarantine` drops your spoofability score from 78 to 34" is actionable. "SPF is B+, DKIM is A, DMARC is C, average B" is not.
Picture this in real life. A security lead at a mid-sized B2B SaaS company runs a quarterly email-security review. The old process produced a spreadsheet with 18 domains and three protocol grades each — 54 cells of data that nobody on the leadership team could parse. The new process produces 18 spoofability scores with one recommended fix each. The output of the review is an 18-line executive summary: "These 3 domains are at high risk; each needs DMARC moved to `p=quarantine`; ETA two weeks; expected score improvement 40 points each." Same data, dramatically better decision-making.
Three questions a spoofability score answers. If you care about email security, these are the questions you actually have:
If an attacker tried to send email as my domain right now, how likely is it they'd succeed?
Which single change would reduce my spoofability most?
Across my whole portfolio, which domains are highest-risk?
For any of these, the raw protocol grades are inputs. The score is the answer.
How to measure your spoofability honestly
There are three ways to get a real spoofability score for your domain.
Fastest (recommended): run the EdgeDNS spoofability endpoint against your domain. It computes a composite score using the interaction rules from the previous section, returns per-protocol sub-scores, and flags the single biggest contributor to your score so you know what to fix first.
Easier still (if you're using AI): ask your AI assistant, connected via the EdgeDNS MCP server: "Compute the email spoofability score for example.com and tell me the single biggest fix I could make to reduce it." The AI runs the analysis and explains the findings conversationally.
Nerdy way (command line): fetch the score via the REST API and feed the JSON into whatever dashboard or alerting system you use.
# Get the spoofability score for a domain
curl -s "https://api.edgedns.dev/v1/security/spoofability?domain=example.com" \
-H "Authorization: Bearer YOUR_API_KEY" | jq '.data'
# Example output (abbreviated):
# {
# "score": 42,
# "classification": "moderate",
# "subscores": { "spf": 75, "dkim": 80, "dmarc": 20 },
# "biggest_contributor": "dmarc_policy_none",
# "recommended_fix": "Move DMARC from p=none to p=quarantine"
# }Scoring spoofability from Python
If you're tracking spoofability across a portfolio of domains — quarterly compliance reviews, M&A diligence, or a recurring board-level email-security report — here's a minimal Python example that scores a list of domains and returns the ones above a threshold.
import os
import requests
API_KEY = os.environ['EDGEDNS_API_KEY']
def spoofability(domain: str) -> dict:
r = requests.get(
'https://api.edgedns.dev/v1/security/spoofability',
params={'domain': domain},
headers={'Authorization': f'Bearer {API_KEY}'},
timeout=15,
)
r.raise_for_status()
return r.json()['data']
def report(domains: list[str], threshold: int = 50) -> list[dict]:
rows = []
for d in domains:
s = spoofability(d)
if s['score'] >= threshold:
rows.append({
'domain': d,
'score': s['score'],
'fix': s.get('recommended_fix'),
})
return rows
at_risk = report(['acme.com', 'acme.io', 'acme-marketing.com'])
for r in sorted(at_risk, key=lambda x: -x['score']):
print(f"{r['domain']:30s} {r['score']:>3} {r['fix']}")The highest-impact fixes, in order
If your spoofability score is high and you want to reduce it, work through the following list in order. The order is based on score impact — the highest-impact fix is first.
Fix 1: Move DMARC to `p=quarantine` or `p=reject`. This is usually the single biggest score improvement available. Going from `p=none` to `p=quarantine` typically drops the spoofability score by 30–50 points. The DMARC rollout guide walks through the safe phased deployment — start at `p=none` for two weeks, read the reports, fix any legitimate senders that fail, then move to `p=quarantine` with `pct=10` and ramp up.
Fix 2: Set `sp=reject` (or `sp=quarantine`). If you're already at apex `p=reject`, subdomain policy closes the subdomain-spoofing gap. This is usually a one-line change and drops the score by another 10–15 points.
Fix 3: Tighten SPF to `-all`. If you're at `~all`, moving to `-all` under DMARC enforcement tightens the receiver behavior. Do this only after confirming every legitimate sender is in your SPF record; otherwise you risk blocking real mail.
Fix 4: Add DKIM if missing. If your domain has no DKIM signature configured, adding one adds a second authentication path that attackers have to defeat. Most email service providers have one-click DKIM setup; the DKIM concept explainer covers what the records look like.
Fix 5: Audit your SPF `include:` chain for the 10-lookup limit. Run the SPF trust-surface check to see the full expanded list of authorized senders. If you're close to or over the limit, prune stale includes. Going into PermError silently disables SPF and spikes your spoofability score.
Each fix is independent — you don't have to do them all at once. Picking the first one and executing it cleanly usually produces the biggest visible result and builds momentum for the rest.
Monitoring spoofability over time
Spoofability is not a set-and-forget number. Your score can get worse without anybody meaning to change it: a new SaaS vendor gets added to SPF and pushes you over the lookup limit; a DKIM key rotation gets deployed incorrectly; a DMARC record gets edited during a migration and the `sp=` tag disappears. Each of these is a real scenario that has produced real regressions in real portfolios.
Monthly or continuous monitoring catches these regressions before attackers do. Subscribe your domain to continuous email-security monitoring, or schedule a cron job that runs the spoofability endpoint weekly and alerts on any score drop greater than five points. The configuration is trivial and the payoff is catching self-inflicted regressions within days rather than during the next quarterly audit.
Or — if you've connected the EdgeDNS MCP server to your AI assistant — ask once a month: "Run the spoofability check on example.com and compare to last month's result. Tell me if anything has regressed." The AI runs the check, diffs it against stored history, and tells you what changed in plain English.
Words you might be wondering about
Spoofability — the outcome metric this guide is about: how easy it is for an attacker to send email that claims to be from your domain and actually reaches the inbox.
SPF (Sender Policy Framework) — a DNS record listing which servers are authorized to send mail as your domain.
DKIM (DomainKeys Identified Mail) — cryptographic signatures on outbound messages that prove they came from a server controlling your domain's DKIM key.
DMARC — the policy layer on top of SPF and DKIM that tells receivers what to do with failing messages.
Alignment — the DMARC requirement that the authenticated domain (from SPF or DKIM) match the visible `From:` domain.
`p=none` / `p=quarantine` / `p=reject` — DMARC policy levels, from monitoring-only to full enforcement.
`sp=` — DMARC subdomain policy. Without it, subdomains inherit the apex policy — which isn't always what you want.
PermError — an SPF failure that happens when the record exceeds 10 DNS lookups or has invalid syntax. Most receivers treat PermError as "SPF not configured."
MCP (Model Context Protocol) — the open standard that lets AI assistants call EdgeDNS tools directly and answer email-security questions in plain English.
Related Guides
How to Check Your DMARC Record
If you have ever wondered why some emails land in the inbox and others end up in spam, you have run into the world of email authentication. DMARC is the rulebook that ties it all together. This guide explains it without jargon, shows you how to check yours, and walks you through rolling it out safely.
SPF Record Setup Guide: From Zero to Protected
If you send any email at all from a domain you own, you should have an SPF record. This guide explains what SPF is in plain language, walks you through setting one up step by step, and warns you about the gotchas before you hit them.
MCP for DNS: How to Talk to Your Domains
Imagine asking Claude, "hey, is my email setup working correctly?" — and getting a real, accurate answer back, instantly. That's what the EdgeDNS MCP server does. This guide explains what MCP is, why it's a big deal, and how to connect it in about a minute.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.