SPF, DKIM and DMARC Gaps: How Email Spoofing Starts on Your Own Domain

By ScruteXPublished 04-11-2026

Most forged emails carrying your domain never touch your mail servers. They are delivered because of a DNS record you published years ago, and that record tells the receiving server to let them through.

What are SPF, DKIM and DMARC gaps?

SPF, DKIM and DMARC gaps are the misconfigurations that let someone send mail as your exact domain even though all three records exist. The common ones are a DMARC policy left at p=none, a subdomain with no policy of its own, an SPF include: that points at a domain someone else can now register, and a DKIM key short enough to crack. Each protocol checks a different identity. Only DMARC ties those checks to the From address your customers actually see, and only an enforced DMARC policy (p=quarantine or p=reject) tells receivers to stop the forgery instead of delivering it.

This guide covers the seven gaps that most often let spoofing start on a domain the organisation owns, shows how attackers find each one from public DNS, and gives a staged path to p=reject that does not break legitimate mail.

What do SPF, DKIM and DMARC actually check?

The three controls are often described as one system. They are three separate checks against three different identities.

Control	What it checks	Identity it checks	What it does not do
SPF	Whether the sending IP address is authorised by the envelope sender's domain	Return-Path (SMTP `MAIL FROM`)	Protect the visible From address; survive most forwarding
DKIM	Whether a cryptographic signature over the message verifies against a public key published in DNS	The signing domain in the `d=` tag	Require the signing domain to match the From domain
DMARC	Whether SPF or DKIM passed for a domain aligned with the visible From domain, and what the receiver should do if not	Header From	Stop lookalike domains, display-name tricks, or compromised genuine mailboxes

The DMARC policy is the instruction to the receiver. p=none asks for no action. p=quarantine asks for the message to go to spam. p=reject asks for it to be refused. Without DMARC, a receiver can see that SPF and DKIM failed, but your domain has given it no instruction about what to do next.

The standard itself changed this year. In May 2026 the IETF published RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting), collectively known as DMARCbis. They replace RFC 7489 from 2015 and move DMARC from an Informational document to a Proposed Standard. The version tag stays v=DMARC1, so existing records keep working, but some tags have gone and others have arrived. Those changes matter for the gaps below.

Why can an email pass SPF and still spoof your brand?

The answer is alignment. SPF validates the Return-Path domain, which recipients never see. DKIM validates whichever domain signed the message. Neither one checks the From address on its own.

Here is how that fails in normal business. A company starts sending through an email service provider without configuring its own domain for SPF and DKIM, so both default to the provider's domain. SPF passes for the provider's Return-Path. DKIM passes for the provider's d= domain. Neither aligns with the company's From domain, so DMARC fails. Legitimate mail fails DMARC this way every day, which is exactly why teams hesitate to enforce, and that hesitation keeps the door open to forgers.

An attacker uses the same structure deliberately. They send from infrastructure they control, set the Return-Path on their own domain so SPF passes, and put your domain in the From header. The message passes SPF. It fails DMARC alignment. Whether it reaches the inbox then depends entirely on the policy you published.

What are the gaps that let spoofing start on your own domain?

These seven gaps appear most often in real incidents and public research. The first five can be read from public DNS, which means an attacker can read them too. The last two sit in mail flow, where DNS checks cannot see them.

Gap 1: DMARC parked at p=none

This is the most common gap by far. EasyDMARC's 2026 report, covering the top 1.8 million domains, found 52.1% with a valid DMARC record in early 2026, up from 29.1% in 2023. But 29.2% of the whole set, 525,996 domains, sat at p=none, and only 22.9% used quarantine or reject. Just 8.9% combined p=reject with a reporting address.

The high-traffic end looks similar. Palisade's scan of the Tranco top 100,000 on 13 August 2026 found DMARC on 57,691 domains. Of those, 36.0% were at p=none, and 20.5% had no aggregate reporting address at all.

Attackers use this deliberately. On 2 May 2024 the FBI, the US Department of State and the NSA issued a joint advisory on Kimsuky, a North Korean intelligence-linked group, exploiting weak DMARC policies in spearphishing. Headers from the reported emails showed dmarc=fail alongside p=none: the receiving servers saw the failure and took no action because the domain owner had asked for none. The agencies warned that the group looks for domains with non-enforced policies before launching social engineering.

A p=none record with no rua address is the worst version of this gap. It gives no protection and no visibility.

Gap 2: Subdomains and parked domains with no policy

Organisations enforce DMARC on the main domain and forget the rest: marketing subdomains, regional domains, domains bought for a product launch, domains acquired with a company. Each one is a valid From address an attacker can use.

DMARCbis targets this directly. RFC 9989 adds three optional tags: np (policy for non-existent subdomains), psd (a Public Suffix Domain flag) and t (explicit test mode). The np tag closes a gap RFC 7489 left open: mail claiming to come from subdomains that do not exist in DNS at all.

Policy discovery has changed too. RFC 9989 drops reliance on the Public Suffix List in favour of a DNS Tree Walk, in which the receiver walks up through the DNS labels looking for a DMARC record, capped at eight queries. Because the two methods can resolve the organisational domain differently, a receiver on RFC 9989 may reach a different result from one still on RFC 7489. The practical fix is to stop relying on inheritance. Publish an explicit policy at every domain and subdomain that sends mail.

Parked domains that never send mail need a different set: an SPF record of v=spf1 -all, a DMARC record at p=reject, and a null MX record (MX 0 .). Together, these tell receivers that any mail claiming to come from that domain is forged.

Gap 3: SPF includes and CNAMEs that point at domains you no longer control

An SPF include: mechanism hands part of your sending authority to another domain. That works while the vendor exists. If the included domain expires, whoever registers it next decides which servers can send as you.

That is what happened at scale in SubdoMailing, documented by Guardio Labs in February 2024. More than 8,000 domains and 13,000 subdomains belonging to brands and institutions such as eBay, MSN, McAfee, PwC, UNICEF and The Economist were hijacked to send spam and phishing by the millions each day, and the activity had run since at least September 2022. Guardio attributed it to an actor it calls ResurrecAds.

The campaign used two methods, and neither needed a password or a software flaw.

SPF include takeover. Guardio found SPF records of well-known domains that still included abandoned domains from defunct email and marketing services. The attackers registered those domains and published their own IP addresses in them, which made the attackers' servers authorised senders for the victim brand.
CNAME takeover. A subdomain still pointed at a domain nobody owned. In Guardio's lead example, a subdomain of msn.com pointed at a sweepstakes domain abandoned for about 21 years; once the attackers registered it, the subdomain inherited whatever SPF policy they chose to publish.

The forged mail passed SPF, DKIM and DMARC, because by then the attackers genuinely controlled the records receivers were checking. Both methods start with a DNS record nobody removed.

Gap 4: SPF records that are too permissive or silently broken

SPF fails in two opposite directions.

Too permissive. +all authorises the entire internet. ?all states no opinion. Wide IP ranges and includes for shared sending platforms can authorise thousands of servers you do not operate. Academic researchers named this class of weakness BreakSPF in a paper presented at NDSS 2024: if any tenant of a shared platform can send through an IP address your SPF record authorises, SPF passes for that tenant too.

Silently broken. RFC 7208 caps SPF evaluation at 10 DNS lookups. Every new SaaS tool that asks for one more include moves you closer to the cap. Past it, receivers return a PermError and SPF stops counting towards DMARC. Under an enforced policy, any mail stream without an aligned DKIM signature is then rejected, and that failure often pushes teams back to p=none, which reopens Gap 1.

Gap 5: Weak or forgotten DKIM keys

A DKIM signature is only as strong as the private key behind it. A key short enough to factor lets an attacker sign forged mail as you.

This risk has been measured. In mid-2024, a research team led by Andreas Wulf examined about one million popular domains and found DKIM keys for roughly 475,000 of them. Almost half of those keys were 1,024 bits or shorter. At the end of 2024 the team cracked a 512-bit RSA key on a rented cloud server for about 8 euros and used it to sign a forged email. Keys under 1,024 bits should not have been accepted since 2018, yet Yahoo, Tuta and Mailfence still delivered the message. RFC 8301 sets 1,024 bits as the minimum and recommends 2,048.

The quieter version of this gap is the stale selector. When you leave an email vendor, its DKIM public key often stays in your DNS for years. If that vendor's key storage is ever compromised, the old selector still verifies signatures for your domain.

Gap 6: Trusted relays that sign whatever they receive

A secure email gateway or outbound relay often sits between your mail platform and the internet and signs everything that leaves. If the relay accepts mail from more sources than it should, attackers can route forged mail through it and collect valid authentication.

EchoSpoofing showed how far that goes. From January 2024, attackers sent mail from rogue Microsoft 365 tenants through Proofpoint relay servers belonging to real customers, spoofing brands such as Disney, IBM, Nike and Best Buy. The customers' relay settings allowed Microsoft 365 as a source without naming which tenants, so the servers accepted the messages, signed them with the customers' DKIM keys and sent them on with passing SPF. Guardio Labs measured an average of about 3 million spoofed emails a day, peaking at 14 million in a day in early June 2024. Proofpoint has since added a setting that denies every tenant not explicitly listed.

In this case DMARC passed and every DNS record was correct. The gap sat in the mail-flow configuration.

Gap 7: Internal paths that skip authentication entirely

Some mail routes treat messages as internal and skip external checks. Microsoft 365 Direct Send exists so printers and scanners can email staff through the tenant's smart host without credentials. Attackers found it. Varonis reported a campaign that began in May 2025 and targeted more than 70 organisations, most of them in the United States, by sending internal-looking messages from external IP addresses straight to the smart host. The messages failed SPF, DKIM and DMARC and were still delivered as trusted internal mail.

Microsoft added a Reject Direct Send setting to the Exchange admin centre in April 2025. Turning it on can break devices that still depend on Direct Send, so test before you enforce.

This gap targets staff rather than customers. A message that appears to come from a colleague, inside your own tenant, gets less scrutiny than almost anything else in the inbox.

How do attackers find these gaps?

Every record that matters here is public. Anyone can query your DMARC record, read your SPF includes, check whether each included domain is still registered, and look up the key length of any DKIM selector they can find. No scanning of your infrastructure is needed, and nothing in your logs will show it happened.

MITRE ATT&CK v20 lists Email Spoofing as T1684.002, a sub-technique of Social Engineering (the older T1672 entry now redirects there). The technique description names the policy gap directly: with a policy such as p=none, no filtering action takes place even when a message fails authentication.

Attacker step	What they look for	Defender control
Reconnaissance from public DNS	`p=none`, missing `rua`, subdomains without policy, SPF lookup count, DKIM key lengths	Continuous external monitoring of your own DNS posture
Acquire infrastructure	Expired domains named in your SPF includes or CNAME targets	Remove dead includes and dangling CNAMEs; alert on vendor domain expiry
Abuse trusted paths	Permissive relays, Direct Send, shared-platform IP ranges	Restrict relays to your own tenant; reject Direct Send; narrow SPF
Deliver	Mail that receivers do not reject	`p=reject` with aligned SPF and DKIM on every stream

What does a spoofed email cost, and who pays?

The direct financial line runs through business email compromise. The FBI's Internet Crime Complaint Center recorded a record 1,008,597 complaints in 2025, with reported losses of nearly $21 billion, up 26% on 2024. Business email compromise accounted for about $3.05 billion of that, and phishing and spoofing was the most reported complaint category. Not every BEC case uses exact-domain spoofing; many use lookalike domains or compromised accounts. But exact-domain spoofing removes the one cue a careful finance team checks first: the sender's address.

The cost reaches trade relationships too. In January 2021, India's Directorate General of Foreign Trade issued a trade advisory after the Ministry of External Affairs warned that email spoofing and phishing frauds were driving bilateral trade disputes. Indian exporters were shipping goods and never receiving payment, after buyers paid into accounts named in forged emails. The advisory told exporters to implement all three of SPF, DKIM and DMARC.

The people who pay most are often outside the company. A customer who receives a refund notice or changed bank details from your exact domain has no lookalike to spot. When the domain is enforced, that customer is protected without having to do anything. That is the most concrete public benefit of getting email authentication right.

Mailbox providers have also made authentication a delivery requirement. Since February 2024, any sender delivering 5,000 or more messages a day to Gmail or Yahoo must publish DMARC and pass alignment, and Gmail moved from warnings to temporary and permanent rejections of non-compliant mail in November 2025. Microsoft applies similar rules to high-volume senders to Outlook.com. These rules require only p=none. Passing them proves your legitimate mail is authenticated. It does not stop anyone forging your domain.

Why do so many domains stay stuck at p=none?

The reasons are usually operational. Few teams choose to leave the domain open.

Nobody owns the full sender list. Marketing platforms, HR systems, ticketing tools and invoicing software all send as the company, and many were set up outside IT.
Fear of blocking real mail. One rejected payroll or invoice run costs a team more internal credibility than a hundred forged messages it never sees.
Reports go unread. Aggregate reports arrive as XML. Without tooling, they pile up unread, and the opposite failure exists too: domains enforced with no reporting address, blind to what fails.
Compliance stops at p=none. Some guidelines, including the mailbox provider rules above, only require p=none. Once they are met, the project closes.

Specialist DMARC platforms do well at exactly this stage of the work. They parse reports, identify senders and guide each one into alignment, and for a team with many sending services that tooling shortens the path to enforcement. What a dedicated DMARC tool usually sees less of is everything around the record: the dangling subdomain that feeds an SPF takeover, the lookalike domain registered last week, the credentials of the finance user who approves wire transfers. Large, mature teams often run best-of-breed tools for each layer. Smaller teams usually get further with one connected view of the external surface.

How do you move from p=none to p=reject without breaking mail?

This staged path works for most organisations. A single-brand company with a handful of senders can often finish it in weeks. Groups with many business units and acquired domains should plan for months, because finding every sender takes longer than fixing any one record.

Inventory every domain you own. Include subdomains, regional, acquired and parked domains. Lock down non-sending domains immediately with v=spf1 -all, DMARC p=reject and a null MX record.
Publish p=none with a reporting address on everything that sends. Collect aggregate reports across a few full business cycles, including month-end and quarter-end runs.
Align every legitimate sender. Configure a custom DKIM signature with d= set to your domain on every email service provider. Where the provider supports it, set a custom Return-Path on your domain so SPF aligns too.
Clean SPF. Remove includes for vendors you no longer use. Resolve every remaining include and confirm the domain is registered and belongs to a vendor you still pay. Stay under 10 DNS lookups, and never use +all or ?all.
Rotate DKIM keys. Move to 2,048-bit RSA keys and delete selectors left by past vendors.
Enforce in stages. Move to p=quarantine, then p=reject. RFC 9989 removed pct, rf and ri, so use t=y for a testing phase instead of a pct value below 100, and drop the tag for full enforcement. Expect older receivers to ignore the new tags during the transition.
Set subdomain policy. Add sp=reject and np=reject once you have confirmed no subdomain sends unaligned mail.
Close the paths DNS cannot see. Restrict outbound relays and gateways to accept mail only from your own tenant. Enable Reject Direct Send in Microsoft 365 once you have migrated the devices that depend on it.
Monitor continuously. Enforcement is a state you have to keep. New SaaS tools, new subdomains and expiring vendor domains reopen these gaps without anyone editing the DMARC record.

What does DMARC not protect you from?

DMARC at p=reject protects one thing very well: your exact domain in the From header. It leaves several common attacks untouched.

Lookalike domains. A forger who registers a typosquat of your domain controls that domain's SPF, DKIM and DMARC records and can pass all three.
Display-name spoofing. A freemail account with your CEO's name in the display field fails nothing, because it never claims your domain.
Compromised genuine mailboxes. Mail sent from a real account with stolen credentials is authenticated, because it really is your mail.
Your suppliers' domains. If a vendor's domain sits at p=none, attackers can impersonate that vendor to your finance team, and your DMARC record has no bearing on it.

So the honest answer to "are we protected from spoofing?" covers more than one control. Email authentication closes the exact-domain gap. Lookalike monitoring, credential exposure monitoring and supplier posture checks cover the attacks DMARC was never designed to stop.

Where does email authentication fit in a CTEM programme?

Email authentication maps onto each of the five stages of Continuous Threat Exposure Management.

Scoping: every owned domain counts, including the ones that send no mail.
Discovery: continuously find new subdomains, SPF includes and DKIM selectors as they appear.
Prioritisation: rank gaps by how easily they can be used. A p=none record on a payments subdomain outranks a soft-fail SPF on a parked domain.
Validation: confirm whether a forged message would actually be delivered.
Mobilisation: put the fix in front of whoever owns the DNS zone or the sending platform, which is often not the security team.

Treating email posture as a one-time project is how organisations end up with an enforced main domain and a dozen forgotten subdomains. Treating it as continuous exposure management keeps those subdomains watched.

Key takeaways

SPF and DKIM can both pass on a forged message. Only DMARC alignment with an enforced policy stops exact-domain spoofing.
p=none is a monitoring setting, not a defence, and state-backed actors actively look for it.
Spoofing often starts with DNS clean-up debt: expired SPF include domains, dangling CNAMEs, stale DKIM selectors and unprotected subdomains.
RFC 9989 (May 2026) removes pct and adds np and t. Publish an explicit policy at every sending domain instead of relying on inheritance.
DMARC does not cover lookalike domains, compromised mailboxes or supplier domains. Plan a separate control for each.

Am I exposed?

You can run these checks today without any vendor tool:

☐ DMARC policy. Query TXT _dmarc.yourdomain.com. Is p= set to quarantine or reject, is there a rua= reporting address, and is sp= set?
☐ Every sending subdomain and parked domain. Does each publish its own DMARC record, or rely on inheritance? Do parked domains publish v=spf1 -all and p=reject?
☐ SPF includes. Resolve every include: in your SPF record. Is each domain registered and owned by a vendor you still use? Is the total under 10 lookups, with no +all or ?all?
☐ DKIM key length. For each selector you know, look at the length of the p= value. A 1,024-bit RSA public key encodes to about 216 Base64 characters and a 2,048-bit key to about 392, so anything near 216 or shorter needs replacing.
☐ Relay and internal paths. Is Reject Direct Send enabled in Microsoft 365, and does your outbound gateway accept relay only from your own tenant?

What ScruteX finds here

ScruteX validates each domain's SPF record for syntax, authorised senders and enforcement policy, checks that DKIM signing is present and valid, and reads the DMARC enforcement level and reporting configuration. It combines the three into a spoofability rating per domain, so a payments subdomain inheriting p=none stands out from a parked domain with a soft-fail SPF. It finds subdomains whose CNAME records point at decommissioned services, the entry point SubdoMailing used. Separately, it detects lookalike and typosquat domains registered against your brand, the attack DMARC cannot stop.

ScruteX works from outside your network and reads what is publicly visible in DNS. It does not see your internal mail flow, so it will not detect a permissive gateway relay or Direct Send left enabled inside your tenant. Those checks stay with your mail administrators.

What that looks like

An illustrative finding, with domain names redacted, structured like a real one:

Check whether your domains can be spoofed

Find out whether your main domain, and the subdomains you forgot, would let a forged email through. Enter a domain and findings begin returning immediately. No agent, no credit card.

Check my domain

Where to go next

If you want to see how spoofability is rated alongside your other external exposures: start with Vulnerability Insights, which covers email security posture and dangling subdomains.
If lookalike domains worry you more than your own records: start with Brand Insights, which covers typosquats, phishing kits and takedown coordination.
If SubdoMailing-style takeovers are the concern: read How typosquatting campaigns evolved in 2025 for the brand-abuse side of the same infrastructure.
If you are building a continuous programme rather than fixing one record: read CTEM vs traditional vulnerability management.

Frequently asked questions

Is DMARC p=none safe to leave in place? No. p=none tells receivers to take no action on mail that fails DMARC, so forged messages are delivered as normal. It is useful only as a short monitoring phase, with a rua reporting address, while you align legitimate senders before moving to quarantine and reject.

Can my domain be spoofed if SPF and DKIM are both set up? Yes. SPF checks the hidden Return-Path domain and DKIM checks the signing domain, and neither has to match the From address recipients see. Only DMARC requires that alignment, and only an enforced DMARC policy tells receivers to quarantine or reject messages that fail it.

What is the SPF 10 lookup limit? RFC 7208 caps SPF evaluation at 10 DNS lookups, counting include, a, mx, ptr, exists and redirect, including nested ones. A record that exceeds the cap returns a PermError, SPF then stops contributing to DMARC, and legitimate mail can fail once you enforce.

Does DMARC stop lookalike domain phishing? No. DMARC protects only the exact domain that publishes the record. An attacker who registers a typosquat controls that domain's own authentication records, so lookalike domains need separate detection and takedown.

What changed in DMARC with RFC 9989? Published in May 2026, RFC 9989 makes DMARC a Proposed Standard, replaces Public Suffix List lookups with a DNS Tree Walk, removes the pct, rf and ri tags, and adds np, psd and t. Existing v=DMARC1 records keep working. The recommended clean-up is to drop pct and publish explicit policies at every sending subdomain.