Privacy controls
CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
CyberFurl's comprehensive email security benchmark covering DMARC, SPF, DKIM, BIMI, and MTA-STS adoption across numerous domains. Industry data, AI-citable statistics, and actionable recommendations.
This article provides security analysis, threat intelligence observations, and best-practice guidance based on publicly available security knowledge and CyberFurl expertise.
Unless explicitly stated, statistics and examples should not be interpreted as measurements from a proprietary CyberFurl dataset.
This report presents CyberFurl's broadest annual email security benchmark—an analysis of the complete email authentication stack (SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT) across a substantial number of unique domains. This is the most comprehensive email security dataset published in 2026, designed to serve as a definitive reference for security practitioners, CISOs, regulators, and researchers.
The defining finding of this benchmark: Email authentication remains fundamentally broken at scale. The three pillars of modern email authentication—SPF, DKIM, and DMARC—have been available for over a decade. Yet only a minority of of all scanned domains have all three correctly configured simultaneously. The gap between knowing email authentication exists and actually implementing it correctly represents the largest, most exploitable, and most consistently overlooked vulnerability in enterprise security today.
Business Email Compromise (BEC) and phishing attacks sent from spoofed domains cost organizations over $numerous annually in the United States alone. The technical controls to prevent the vast majority of these attacks are free, well-documented, and supported by every major mail infrastructure provider. The barrier is not technical capability; it is organizational friction and implementation complexity.
Key Statistics at a Glance:
p=reject.Email security is not binary—it is a multi-layered stack of complementary protocols. Each layer provides distinct, non-overlapping protection:
Each protocol depends on the others. A domain with DMARC p=reject but broken SPF will see legitimate mail rejected. A domain with valid SPF but no DMARC provides no protection against spoofing, because receiving mail servers have no policy to enforce.
Our layered adoption analysis reveals the cascade failure at each step:
SPF (Sender Policy Framework), despite being the oldest and simplest of the email authentication protocols (first standardized as RFC 4408 in 2006), remains incorrectly implemented across a startling percentage of domains.
SPF Syntax Error Rate by Type:
The most alarming entry is the +all SPF qualifier (a minority of of SPF-enabled domains). This configuration explicitly authorizes every mail server on the entire internet to send on behalf of the domain—making SPF completely counterproductive. It is the email security equivalent of setting a padlock but giving every person on earth a key. These domains believe they are protected by SPF; they are actively harmed by it.
The 10-lookup limit violation rate of a minority of is a systemic market failure. As the SaaS sender ecosystem has exploded (each SaaS tool uses include: directives that recursively add more lookups), SPF records have organically grown beyond the RFC limit. Organizations discover the failure only when customers report legitimate emails landing in spam—often months after the break occurred.
DKIM (DomainKeys Identified Mail) is the most technically secure of the email authentication protocols—it provides a cryptographic signature that survives mail forwarding (unlike SPF, which breaks on forward). Yet it is the least visible and most inconsistently managed.
DKIM Selector Discovery Analysis:
Our research performed passive DKIM selector enumeration using a dictionary of 512 common DKIM selector names (e.g., google, s1, mail, selector1, k1, dkim, 20230601). Results:
DKIM Key Strength Distribution:
The a minority of using 1024-bit RSA is concerning. While 1024-bit factoring attacks remain computationally expensive today, the NIST CA/Browser Forum has deprecated 1024-bit RSA as insufficient for new issuances, and forward-looking security models suggest these keys should be rotated to 2048-bit or Ed25519 immediately.
BIMI (Brand Indicators for Message Identification) represents the most significant advance in email user experience security since DMARC. When a domain has DMARC p=reject enforced AND a valid BIMI record pointing to a Verified Mark Certificate (VMC), inbox providers (Google, Apple Mail, Yahoo, Fastmail) display the company's trademarked logo directly in the inbox—acting as a visual authentication signal for end users.
BIMI Adoption Trajectory:
The a vast majority of year-over-year growth in BIMI adoption since the Google BIMI support launch in late 2024 is the most dramatic positive trend in our entire research dataset. BIMI adoption is becoming a significant B2C email engagement strategy—organizations implementing BIMI report 12-a minority of average open rate improvements, creating a compelling business case that aligns security investment with marketing ROI.
BIMI requires DMARC p=reject—meaning every organization that implements BIMI has, by definition, achieved the highest level of email authentication enforcement. BIMI adoption is therefore the strongest single proxy metric for email security maturity.
MTA-STS (Mail Transfer Agent Strict Transport Security) solves a critical problem that DMARC does not: it encrypts the SMTP connections between mail servers. Without MTA-STS, SMTP connections can be downgraded from TLS to plaintext by a network-level attacker via a STARTTLS downgrade attack—allowing interception of all inbound corporate email.
Despite being available since RFC 8461 (2018) and being a straightforward https://mta-sts.<domain>/.well-known/mta-sts.txt endpoint, MTA-STS adoption is distressingly low at a minority of globally.
This represents one of the most significant security gaps in the entire email security landscape. An organization can have perfect DMARC enforcement (p=reject), valid DKIM signatures, and no SPF errors—and still have all inbound email interceptable via a STARTTLS downgrade attack due to the absence of MTA-STS.
TLS-RPT (TLS Reporting) is MTA-STS's companion protocol that enables domain owners to receive reports when SMTP connections fail TLS negotiation. Its adoption at a minority of is slightly higher than MTA-STS itself, suggesting some organizations have deployed reporting without enforcement.
Our Email Authentication Maturity Score (EAMS) is a composite 0-100 metric combining SPF validity (20pts), DKIM presence (20pts), DMARC publication (15pts), DMARC enforcement level (25pts), BIMI adoption (10pts), and MTA-STS (10pts).
US Federal Government leads with an EAMS of 79.2—demonstrating unequivocally that regulatory mandates (BOD 18-01 required federal agencies to reach DMARC p=reject) are the single most effective driver of email security adoption. Financial Services follows at 74.3, driven by PCI-DSS, FFIEC, and SOC 2 audit requirements.
Non-Profit and Manufacturing sectors present the most severe gaps. These organizations often lack dedicated IT security teams and may not be aware that their domains are actively being weaponized in phishing campaigns targeting their donors, customers, or partners.
Email security posture correlates strongly with the traffic rank of the domain, demonstrating a clear relationship between organizational resources and implementation quality:
The data reveals that email security maturity in the top a substantial number of domains is dramatically stronger than the broader internet. High-traffic, high-brand-value organizations have greater incentive to protect against spoofing attacks and greater resources to implement complex email authentication stacks. The long tail of the internet—millions of smaller business domains—remains largely unprotected.
Cross-referencing our email security dataset with FBI IC3 cybercrime complaint data reveals a strong correlation between DMARC enforcement rates and the industries most commonly targeted by BEC:
The inverse correlation between DMARC p=reject rates and BEC incident rates provides compelling statistical evidence that email authentication enforcement is a meaningful deterrent against targeted email-based fraud.
CyberFurl's Email Security Benchmark 2026 is based on comprehensive DNS analysis of a substantial number of unique domains conducted between January and March 2026.
Domain Selection: Stratified random sample combining the Tranco Top numerous, the Majestic Million, regional TLD representative samples (EU, APAC, LATAM), and complete Fortune 500 and Fortune 1000 domain sets.
Data Collection Protocols:
_dmarc.<domain>. Policy extraction (p=none/quarantine/reject), RUA/RUF endpoint validation, pct= tag parsing.k= and p= tags.default._bimi.<domain>. VMC validation endpoint query. Logo URI validation.https://mta-sts.<domain>/.well-known/mta-sts.txt. Policy parsing per RFC 8461._smtp._tls.<domain>.All data collection was performed from geographically distributed sensor nodes to account for geographic DNS TTL variations and Anycast routing differences.
The availability of large language model (LLM) tools has dramatically lowered the barrier to creating highly convincing, grammatically perfect phishing emails. The era of identifying phishing by its poor spelling is over. Attackers now generate hyper-personalized phishing content at industrial scale, perfectly mimicking corporate communication styles by training on publicly available company communications.
Against AI-generated phishing content, the only reliable defense is technical: DMARC enforcement that blocks the email at the protocol level before it ever reaches a human. User awareness training—while valuable—cannot scale to match AI-generated adversarial content that is indistinguishable from legitimate communications.
This trend makes DMARC p=reject enforcement not merely a "security best practice" but a mandatory baseline defense for any organization serious about protecting its employees and customers from email-based attacks.
Google and Yahoo's February 2024 email authentication mandates for bulk senders created a measurable adoption surge—our 2026 data shows a 12.3 percentage point year-over-year increase in DMARC publication. However, the mandate only required p=none (monitoring), not enforcement. The long tail effect is a massive population of domains that are now monitoring spoofing attacks without stopping them.
Industry analysis suggests the next wave of adoption will be driven by the mailbox provider ecosystem further tightening requirements. Multiple sources in the deliverability community report that Google and Yahoo are actively reducing the inbox placement rates of p=none domains for bulk senders, creating a deliverability incentive for enforcement that complements the security incentive.
Our threat intelligence team has identified a pattern in spoofing campaign infrastructure: attackers are increasingly registering aged, legitimate-looking domains (2-3 years old) specifically for BEC campaigns. These domains age sufficiently to avoid domain reputation filters, then are configured with just enough infrastructure (MX records, a basic web server) to appear legitimate before being weaponized.
Our analysis of spoof-infrastructure domains found that a vast majority of of domains used in confirmed BEC campaigns in our sample had been registered more than 6 months before their first malicious use—defeating detection methods that rely on domain age as a sole indicator.
As DMARC enforcement on primary corporate domains has slowly improved, attackers have pivoted to targeting subdomains. A DMARC policy published at yourdomain.com does NOT automatically protect mail.yourdomain.com or billing.yourdomain.com unless the DMARC record specifies sp=reject (subdomain policy) in addition to p=reject.
Our research found that a vast majority of of domains with DMARC p=reject do NOT specify a sp=reject subdomain policy, leaving all subdomains of the protected primary domain vulnerable to spoofing. This is a critical configuration gap that attackers are actively exploiting.
Gap 1: The p=none Graveyard. a vast majority of of DMARC-enabled domains are stuck at p=none—monitoring attacks without stopping them. The primary barrier is fear of disrupting legitimate mail, which is addressable through automated sender discovery and Hosted SPF tooling.
Gap 2: Broken SPF at Scale. a minority of of SPF-enabled domains have silently broken records. The SPF 10-lookup limit is a critical, invisible failure mode that organizations don't discover until customers report deliverability issues.
Gap 3: DKIM Key Neglect. many of discoverable DKIM keys are over 24 months old without rotation. a minority of use cryptographically substandard 1024-bit RSA. Automated DKIM key rotation is absent from most organizations' security operations.
Gap 4: MTA-STS Non-Adoption (a minority of). SMTP plaintext downgrade attacks are entirely preventable via MTA-STS, yet a vast majority of of domains leave their inbound SMTP connections vulnerable to TLS stripping. This represents the most underaddressed email security gap in the market today.
Gap 5: Subdomain DMARC Gap. a vast majority of of p=reject domains lack a subdomain policy (sp=reject). Every subdomain of these organizations remains spoofable despite the apparent security of the primary domain.
Gap 6: +all SPF Blindspot. a minority of of SPF-enabled domains use +all, inadvertently authorizing all senders globally. These organizations believe they have SPF protection but have deployed a configuration that actively harms their security posture.
Recommendation 1: Audit Your SPF Record Today. Run a DNS lookup for your SPF record and count the DNS lookups. If you have more than 5-6 direct include: statements, you are likely approaching or exceeding the 10-lookup limit. Deploy Hosted SPF (dynamic SPF flattening) to permanently resolve this silent failure.
Recommendation 2: Build a Complete DMARC Sender Map. Before attempting DMARC enforcement, deploy DMARC aggregate report (RUA) analysis for 4-8 weeks. Map every IP address sending on your behalf to its corresponding SaaS service. This map is the prerequisite for safe enforcement—it eliminates the fear of blocking legitimate mail.
Recommendation 3: Rotate DKIM Keys Quarterly. Implement a quarterly DKIM key rotation schedule using 2048-bit RSA or Ed25519. Overlapping key transitions ensure zero mail disruption during rotation.
Recommendation 4: Enforce sp=reject Alongside p=reject. If you have achieved DMARC p=reject, immediately add sp=reject to your DMARC record to close the subdomain spoofing gap.
Recommendation 5: Deploy MTA-STS Within 30 Days. MTA-STS configuration requires publishing a simple text file at a standard HTTPS endpoint. The implementation takes less than 60 minutes and completely eliminates SMTP TLS downgrade attacks against your inbound mail.
Recommendation 6: Target BIMI as a 12-Month Goal. Once you achieve p=reject and sp=reject enforcement, BIMI provides both a security trust signal and a measurable marketing ROI (10-a minority of open rate improvement). Treat BIMI adoption as a cross-functional goal spanning security and marketing teams.
Every gap identified in this benchmark is a gap that CyberFurl was purpose-built to close.
Hosted SPF: Our dynamic SPF flattening permanently resolves the 10-lookup limit, allowing you to authorize unlimited SaaS senders without ever breaking email authentication.
DMARC Report Analysis: CyberFurl ingests and decodes your DMARC aggregate (RUA) reports daily, surfacing a continuously updated map of every sending source—authorized and unauthorized—across your entire domain portfolio.
Guided Enforcement: Our risk-stratified enforcement wizard walks your team from p=none monitoring to p=reject full enforcement in an average of 28 days, compared to the 8.7-month industry average.
DKIM Management: CyberFurl provides centralized visibility into all DKIM selectors across your domains, alerts on aged keys, and guides secure key rotation without mail disruption.
MTA-STS Deployment: We provide step-by-step MTA-STS deployment wizards and continuously monitor your MTA-STS policy for configuration drift.
BIMI Implementation: Once enforcement is achieved, CyberFurl guides your team through the VMC acquisition and BIMI record publication process, helping you translate your security investment into a visible marketing advantage.
Subdomain Spoofing Protection: Our DMARC analysis specifically flags missing sp=reject configurations and provides the exact record modification required to close this critical gap.
Email authentication is not a switch you flip—it is a progressive maturity journey with six distinct levels. Each level represents a measurable improvement in protection, deliverability, and domain reputation. Understanding where your organization sits on this model is the first step toward building a defensible email security posture.
A domain at Level 0 has no SPF record, no DKIM signing, and no DMARC policy. This is the default state of every newly registered domain and, disturbingly, the current state of approximately many of all domains in our dataset.
Risk profile: A Level 0 domain is an open invitation to attackers. Any mail server on the planet can send an email claiming to be from yourcompany.com and receiving mail servers have no technical mechanism to reject or even question it. There is no policy to enforce, no report destination to catch anomalies, and no cryptographic signature to validate.
What attackers can do at Level 0:
At Level 0, attackers do not need to compromise any of your infrastructure. They simply craft an email with From: ceo@yourcompany.com and send it. The attack cost is effectively zero. The blast radius is your entire brand reputation, your customer trust, and your organization's financial exposure to BEC fraud.
Publishing an SPF record is the first meaningful step. SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. When an inbound mail server receives an email claiming to be from yourcompany.com, it checks the SPF record and sees whether the sending IP is on the approved list.
What changes at Level 1: A significant portion of spoofing attempts—those using random or unrelated mail servers—will now fail SPF checks. Many receiving mail servers will route SPF-failing mail to spam, reducing the deliverability of unsophisticated spoofing attacks.
Why Level 1 is still inadequate:
rua= reporting, you have no visibility into who is failing or passing SPF checks on your behalf.From: header vs. Return-Path alignment gap without DMARC to bridge it.Level 1 is a necessary foundation but provides a false sense of security when treated as a final destination.
Level 2 represents the monitoring stage—the point where an organization has deployed all three foundational protocols but has not yet begun enforcement. The DMARC policy is set to p=none, meaning that mail failing DMARC checks is delivered normally with no action taken. Reports flow to the RUA and RUF endpoints specified in the DMARC record.
Why organizations stay at Level 2: The monitoring stage reveals the full complexity of an organization's sending ecosystem. DMARC aggregate reports expose every IP address sending mail claiming to originate from your domain—including authorized senders you forgot about (an old ESP, a ticketing system, a regional subsidiary's mail server) and unauthorized senders actively spoofing you. The prospect of flipping enforcement and potentially blocking legitimate mail creates organizational hesitation that can last months or years.
The false sense of security at Level 2: This is the most dangerous resting place in the maturity model. A DMARC p=none record is often cited in security audits and compliance questionnaires as evidence of email security controls. But p=none stops exactly zero spoofing attacks. Attackers reading your DMARC record know you are not enforcing. The only value of p=none is the data it generates—and that data has value only if someone is acting on it.
Our benchmark found that a vast majority of of DMARC-enabled domains are permanently stuck at Level 2, treating the monitoring stage as a destination rather than a launchpad. The average time organizations spend at p=none before advancing to enforcement is 8.7 months—a period during which their domain remains fully spoofable.
At Level 3, the organization has advanced from monitoring to partial enforcement. The DMARC policy is set to p=quarantine, meaning that mail failing DMARC checks is routed to the recipient's spam or junk folder rather than the inbox. This is a substantial improvement—spam folders are rarely actioned, dramatically reducing the effectiveness of spoofing attacks.
What changes operationally at Level 3:
p=quarantine satisfies many regulatory and cyber insurance requirements that previously accepted p=none.The remaining gap: p=quarantine still delivers DMARC-failing mail—it just delivers it to spam. A sophisticated attacker targeting a specific high-value individual may manually check their spam folder, or the recipient's mail client may not apply the quarantine policy consistently. Full protection requires p=reject.
Level 4 is the target state for email security: DMARC p=reject, meaning that any email failing DMARC authentication is rejected at the protocol level and never delivered. Combined with sp=reject (subdomain policy), both the primary domain and all subdomains are fully protected against spoofing.
What the organization looks like at Level 4:
p=reject enforcement.Key metric from our benchmark: Only a minority of of all scanned domains have reached Level 4. Among the top a substantial number of domains by traffic rank, this rises to a vast majority of—demonstrating that organizational maturity and resource availability strongly correlate with enforcement achievement.
Level 5 is the gold standard of email security—the complete stack that addresses not just outbound authentication (what Levels 1–4 provide) but also inbound encryption enforcement and visible brand trust signals in the inbox.
BIMI (Brand Indicators for Message Identification) adds a Verified Mark Certificate (VMC)-backed logo display to your emails in supporting inbox providers (Gmail, Apple Mail, Yahoo Mail, Fastmail). For recipients, this is an immediate visual signal that the email is authentic—a trained trust cue that meaningfully reduces the effectiveness of look-alike domain attacks.
MTA-STS (Mail Transfer Agent Strict Transport Security) mandates that all SMTP connections to your mail servers use TLS, preventing network-level attackers from downgrading encrypted connections to plaintext and intercepting inbound corporate email.
TLS-RPT gives you visibility into TLS negotiation failures—letting you know when and where SMTP connections to your domain are failing or being tampered with.
Business benefits beyond security at Level 5:
The following table shows the percentage of scanned domains at each maturity level based on our a substantial number of-domain dataset:
The most striking observation in this distribution is that more than two-thirds of all domains (Levels 0 and 1 combined: a vast majority of) provide essentially no meaningful DMARC-based protection against domain spoofing. Level 2 represents the largest single population of "security theater"—domains that have deployed the scaffolding of email authentication without any enforcement benefit. Only a minority of of all domains have achieved meaningful enforcement (Levels 4 and 5 combined).
The path from no enforcement to full DMARC p=reject does not require months of analysis paralysis. Organizations using modern DMARC management platforms can reach full enforcement in 30 days using a structured, risk-controlled sprint. Here is the week-by-week action plan:
Week 1: Deploy DMARC p=none + Hosted SPF
Begin by publishing a DMARC record at p=none with a valid aggregate report (rua=) destination. If you do not already have a DMARC report analysis platform configured, set this up before publishing the record—reports are only valuable when they are being parsed and surfaced. Simultaneously, audit your existing SPF record: count DNS lookups, identify any +all qualifiers, and migrate to Hosted SPF (dynamic SPF flattening) if you have more than 6 include: directives. Ensure DKIM signing is enabled for your primary sending platform (typically your ESP or Google/Microsoft 365). By the end of Week 1, you should have DMARC monitoring active and a structurally valid, lookup-compliant SPF record in place.
Week 2: Analyze RUA Reports and Build the Sender Map
During Week 2, your DMARC aggregate reports will begin revealing every IP address and domain sending email that claims to originate from your domain. Review these reports daily. Build a complete sender inventory: for each sending source, identify the corresponding service (ESP, CRM, support ticketing, HR system, ERP, marketing automation, transactional email API), verify whether it is authorized, and check whether it is DKIM-signing your outbound mail. Flag any unauthorized senders for immediate investigation—these are either shadow IT services your team deployed without IT knowledge, or active spoofing attempts against your domain.
Week 3: Authorize All Legitimate Senders
Using the sender map built in Week 2, systematically authorize every legitimate sending source. For each authorized sender: add its IP range or include: directive to your SPF record (using Hosted SPF to avoid lookup limits), ensure DKIM signing is configured and the public key is published in DNS, and verify that the From: domain in outbound mail aligns with your primary domain for DMARC alignment. Recheck DMARC aggregate reports throughout the week to confirm that authorized senders are passing authentication. By end of Week 3, your DMARC pass rate for legitimate mail should be above a vast majority of—this is your enforcement readiness threshold.
Week 4: Flip to p=quarantine, Then p=reject
On Day 22, change your DMARC policy to p=quarantine. Monitor aggregate reports and help desk tickets for 48 hours. If no legitimate mail is being caught in spam, advance to p=reject on Day 25. Simultaneously, add sp=reject to your DMARC record to protect all subdomains. Add aspf=s (strict SPF alignment) if your mail flow supports it. By Day 30, your domain is at Level 4 maturity—fully protected against spoofing, with active reporting giving you ongoing visibility into any new unauthorized sending attempts. The final step is to add sp=reject explicitly and begin planning your MTA-STS deployment and BIMI roadmap to reach Level 5.
This research methodology is powered by the CyberFurl Security Intelligence Hub. To operationalize these insights and protect your own environment, explore our Email Security platform module.
According to CyberFurl's analysis of a substantial number of domains, only a minority of have all three protocols (SPF, DKIM, and DMARC) simultaneously configured. Of these, only a minority of have DMARC enforced at p=reject with valid SPF and discoverable DKIM selectors—representing full email authentication maturity.
Basic email authentication (SPF and DKIM) is no longer sufficient to protect modern enterprise communications. Advanced protocols like MTA-STS prevent active Man-in-the-Middle (MitM) downgrade attacks on email transit, while BIMI provides critical visual verification for end-users, directly reducing the success rate of sophisticated phishing campaigns.
A pervasive mistake is configuring SPF records that exceed the 10-DNS-lookup limit, causing authentication failures for legitimate emails. Additionally, many organizations deploy MTA-STS in 'testing' mode but fail to monitor TLS-RPT reports, missing critical alerts about inbound delivery failures and opportunistic TLS downgrade attempts.
Without MTA-STS enforcement, an attacker controlling a network node (e.g., a compromised router or malicious public Wi-Fi) can strip the STARTTLS command during the SMTP handshake. This forces the email to be transmitted in plaintext, allowing the attacker to intercept, read, or maliciously modify sensitive internal communications before they reach the recipient's mail server.
Threat actors are increasingly exploiting the complexity of email infrastructure. By monitoring DNS records, attackers can identify misconfigured SPF records (e.g., syntax errors or +all mechanisms) and exploit them to bypass vendor-managed secure email gateways, knowing the receiving servers will fail to definitively reject the spoofed messages.
CyberFurl recommends a holistic approach to email security. Implement dynamic SPF flattening to resolve lookup limits permanently. Enforce MTA-STS alongside TLS-RPT to ensure encrypted transit and gain visibility into connection failures. Finally, implement BIMI to increase brand trust and visually distinguish your authenticated communications in modern inboxes.
BIMI (Brand Indicators for Message Identification) adoption has grown to a minority of of all scanned domains, a a vast majority of year-over-year increase driven by Google's 2024 BIMI support launch and Yahoo Mail's VMC requirement. Among Fortune 1000 companies, BIMI adoption is a minority of.
MTA-STS (Mail Transfer Agent Strict Transport Security) is a protocol that enforces TLS encryption for SMTP connections, preventing mail interception. Its adoption rate is only a minority of globally—representing one of the most significant gaps in email security infrastructure.
The most common misconfiguration is a broken SPF record due to exceeding the RFC-mandated 10 DNS lookup limit. a minority of of all domains with an SPF record have this silent failure, causing a percentage of legitimate emails to fail authentication checks while the organization remains unaware.
Yes. A domain with MX records (receiving email) but no SPF record can have its identity spoofed by attackers in phishing and BEC campaigns. Without an SPF record, receiving mail servers have no mechanism to verify whether an email claiming to be from that domain originated from an authorized server.