Evaluating DMARC Adoption in Ukrainian Corporate Domains
An empirical analysis of 146 commercial .com.ua domains sourced from Certificate Transparency logs indicates that 88.36% remain vulnerable to email spoofing.
Protection Gap: Effective Protection vs. Vulnerable Pool
When evaluated for DMARC adoption, Ukrainian corporate domains present a misleading picture of security. On paper, 37.67% of evaluated domains have a published DMARC record. However, merely having a record provides a false sense of security while leaving domain identity exposed.
When these domains are measured against the standard of an “Effective Reject”—a policy configuration instructing receiving servers to reject unauthenticated emails across both the main domain and all subdomains with 100% filtering—only 11.64% of the total sample achieved full protection.
What DMARC Protects—And What It Does Not
What it is: DMARC is an email security protocol that builds directly on SPF and DKIM checks. Domain owners implement DMARC by publishing a policy in their domain’s DNS. This policy tells receiving servers what to do with emails that fail validation: reject them, filter them as spam, or deliver them as usual. Crucially, DMARC also requests regular reports from these servers, showing which servers are sending mail using the domain.
What it protects: DMARC only affects outbound emails—specifically, fake messages sent by scammers using the organization’s domain name to target partners, customers, vendors, or employees.
What it does NOT protect: It has no effect on incoming emails targeting the organization’s employees—whether they are spoofed messages, emails from lookalike domains (e.g., exarnple.com), emails from compromised legitimate accounts, or standard spam.
A detailed breakdown of the DMARC configurations across the analyzed domains illustrates this protection gap:
DMARC Configuration Breakdown (.com.ua domains)
The Zero-Adoption Gap: Complete Lack of Authentication vs. Monitoring
The single largest driver of overall email spoofing vulnerability Ukrainian businesses face is the complete absence of DMARC records. In the analyzed sample, 62.33% of domains (91 out of 146) publish no DMARC policy whatsoever. A further 16.44% (24 domains) publish a monitoring-only policy (p=none).
Both configurations result in unauthenticated spoofed emails being delivered straight to the recipient’s Inbox. However, a critical distinction exists between them:
- No DMARC Record (62.33%): Receiving servers perform no DMARC checks and generate zero feedback. The domain owner has no visibility into ongoing spoofing campaigns.
- Monitoring Policy (
p=none) (16.44%): Receiving servers perform DMARC checks on incoming mail and dispatch aggregate XML feedback reports (rua=mailto:dmarcreports@example.com) to the domain owner. While spoofed emails still land in inboxes, the domain owner receives telemetry to detect impersonation attacks.
Threat Scenario: Direct Spoofing (No DMARC or p=none)
An attacker dispatches emails forged with From: ceo@example.com. Under both missing DMARC and p=none, receiving servers pass spoofed messages directly to the target Inbox. With p=none, aggregate reports alert the owner; with no DMARC, the owner remains completely blind.
Why ‘Quarantine’ Is Not Complete Protection
Global cybersecurity reporting often groups p=quarantine and p=reject policies together as “effective protection.” In practice, while quarantine moves spoofed mail out of the primary inbox, it still leaves an active attack vector. The critical difference between reject and quarantine lies in whether the spoofed message is still delivered to the recipient.
A quarantine policy instructs receiving mail servers to treat spoofed messages as suspicious, which in most cases results in delivery to a recipient’s Spam or Junk folder. Because legitimate business correspondence is frequently misclassified by aggressive spam filters, many employees have developed a habit of checking their spam folders and ignoring system warnings.
Even if employees do not check their spam folders, attackers in Business Email Compromise campaigns can use multi-channel social engineering—such as a follow-up phone call or message—to provide a plausible explanation for the filtering decision, persuading the victim to retrieve the email.
Threat Scenario: Quarantine Retrieval (p=quarantine)
An attacker sends a spoofed request with From: billing@example.com lands in the recipient’s Spam folder under the quarantine policy. The victim retrieves and opens the message due to routine spam checking habits or follow-up social engineering calls.
Subdomain and Partial Enforcement Vulnerabilities
Organizations that mandate a strict reject policy on their primary domain can still undermine their security through subtle configuration gaps. When organizations need different policy rules for subdomains, they set the sp tag directly inside the primary domain record (e.g., v=DMARC1; p=reject; sp=none;). Setting the subdomain policy to monitor only (sp=none) or quarantine (sp=quarantine) is often a planned transition setting, or a deliberate operational exception in complex enterprise environments. However, if left indefinitely, these configurations leave subdomains vulnerable.
Threat actors do not need to spoof the main domain; they can bypass primary defenses by forging subdomains—whether existing or non-existent—such as billing@nonexistent-subdomain.example.com. Because no explicit DMARC record exists for nonexistent-subdomain.example.com, receiving servers fall back to the primary domain’s sp=none policy, allowing spoofed emails sent on behalf of subdomains to pass straight into the Inbox.
Threat Scenario: Subdomain Spoofing (p=reject; sp=none)
While spoofed mail sent from the primary domain is blocked, an attacker can forge mail from billing@nonexistent-subdomain.example.com which falls back to the none policy and reaches the Inbox.
Similarly, the DMARC pct tag is a fractional filtering parameter designed to safely phase in enforcement. For example, pct=20 instructs receiving mail servers to apply the DMARC policy to only 20% of messages that fail DMARC checks. The remaining 80% are processed under the next most lenient policy—reducing reject to quarantine, or quarantine to none. Leaving the pct tag below 100% indefinitely creates a permanent security gap, mathematically ensuring that a predictable percentage of spoofed emails will bypass enforcement and reach recipients.
Threat Scenario: Exploiting Partial Enforcement (p=quarantine; pct=20)
An attacker dispatches multiple spoofed emails: only 20% are quarantined, while the remaining 80% fall back to the none policy and reach the Inbox.
Benchmarking: Ukrainian Corporate Domains vs. Global Top 1 Million
To evaluate whether these findings are unique to the local domain pool or reflect broader global patterns, we benchmarked our empirical data against the data from the global “SPF, DKIM, and DMARC in 2024: Analyzing the Top 1 Million Domains” report.
To compare the data fairly, we must account for two key differences in how the datasets are collected and measured:
Comparative Benchmarking: Ukrainian .com.ua vs. the Global Top 1 Million
Mapping our findings against the global dataset yields the following results:
- Nominal DMARC Adoption (Any Record Published): Ukrainian
.com.uadomains reached 37.67%, outpacing the global average of 33.40% by 4.27 percentage points. - Passive Monitoring (
p=none): At 16.44%, the Ukrainian segment has 2.66 percentage points fewer domains configured with a monitoring-only policy than the global average of 19.10%. - Effective Protection per Global Report Criteria (
p=quarantineorp=reject): Under the global study’s loose standard (which groupsquarantineandrejecttogether), Ukraine’s nominal protection rate of 21.23% outpaces the global average of 14.30% by 6.93 percentage points. - Effective Reject Protection (
p=reject; sp=reject; pct=100): Under the strict “Effective Reject” standard established in this study, Ukraine’s actual protection rate drops to 11.64%. Because the global study did not analyze subdomain (sp) or percentage-based filtering (pct) tags, a direct comparison is impossible.
In summary, the analysis of the Ukrainian .com.ua segment shows that although it outperforms global averages across all baseline metrics, overall DMARC adoption remains low. Furthermore, most published policies do not meet the “Effective Reject” standard. As a result, only 11.64% of the analyzed domains achieve Effective Reject protection, leaving 88.36% vulnerable to email spoofing.
What This Data Does Not Cover
A few methodological boundaries define the scope of these findings, indicating that the actual rate of Effective Reject protection in practice is likely lower than the measured 11.64%.
- Certificate Transparency Dataset: The dataset relies exclusively on commercial domains with issued TLS certificates in the
.com.uazone, excluding isolated domains absent from Certificate Transparency logs. - Explicit Subdomain Policies: The study evaluated DMARC policies at the organizational domain level but did not check whether individual subdomains published explicit, independent DMARC records with weaker policies.
- SPF and DKIM Implementation Quality: The analysis focused strictly on published DMARC policy parameters without inspecting underlying SPF or DKIM configurations. Proper SPF and DKIM configurations are essential, as weak or misconfigured records can negate DMARC protection even under a
rejectpolicy. Auditing the implementation of these underlying protocols remains an open area for future research.
Check Your Domain for DMARC in Under a Minute
To check if your domain implements DMARC and evaluate the strictness of its policy, run the following command in a terminal (Linux/macOS), replacing example.com with your domain:
dig TXT _dmarc.example.com +short(Alternatively, use any public DNS lookup tool to query _dmarc.example.com.)
A DMARC record that meets the strict “Effective Reject” criteria looks like this:
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Or like this (explicit version):
"v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc@example.com"Both configurations provide the exact same level of protection. Additional reporting or alignment tags (such as ruf=, adkim=, or aspf=) may also be present in your record without weakening this policy.
Key Policy Parameters
p=: Base policy for the primary domain (none,quarantine, orreject).sp=: Policy for subdomains (inheritsp=value if omitted).pct=: Percentage of unauthenticated mail subjected to the policy (defaults to100).
Spotting Hidden Vulnerabilities
- Missing DMARC Record (Empty Output): Spoofed mail lands directly in the recipient’s inbox without restriction, and no feedback reports are generated. Primary domains and subdomains remain completely unprotected and blind.
p=none(Monitoring Only): Spoofed mail lands directly in the recipient’s inbox. Ifruais configured, aggregate reports are sent so domain owners can monitor authentication failures.p=quarantine(Spam Folder Delivery): Spoofed mail is delivered to the recipient’s spam folder instead of being blocked. Attackers can still exploit this through social engineering or by relying on employees’ routine spam-checking habits.sp=noneorsp=quarantine(Downgraded Subdomain Policy): Spoofed mail sent from subdomains (including nonexistent ones) bypasses primary domain protection and lands in the inbox or spam folder based on the weaker subdomain policy.pct=below100(Partial Enforcement): Spoofed mail is subject to the policy only for the configured percentage. Remaining mail falls back to the next less restrictive policy level.- Missing
ruaTag (No Reporting Address): Spoofed mail is processed under the specified policy, but no aggregate feedback reports are sent. Domain owners receive zero visibility into ongoing attacks or delivery failures.
DMARC Implementation Roadmap to Effective Reject
The following three-stage roadmap outlines the standard deployment path to DMARC enforcement. For complex enterprise environments, all email sources should be fully verified prior to applying restrictive policies.
WARNING: Because DMARC relies directly on SPF and DKIM evaluation results, weak configurations negate DMARC protection, while misconfigurations can cause legitimate mail to be blocked or filtered. To catch and resolve authentication issues early, deploy DMARC sequentially from Phase 1 through Phase 3, monitoring aggregate reports at each stage.
DMARC policies are published as DNS TXT records under the _dmarc subdomain (for example, for the domain example.com, the record is published at _dmarc.example.com).
Practical Deployment Path
Phase 1: Monitoring (p=none)
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Publish this TXT record to collect feedback reports and verify all services sending email for your company. If reports show authentication failures, correct your SPF and DKIM settings before escalating enforcement.
Phase 2: Quarantine (p=quarantine)
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"Update the record to this configuration. Confirm that corporate correspondence reaches recipient inboxes at major email providers and key partners. If legitimate mail is filtered to spam, check DMARC aggregate reports for SPF/DKIM failures, verify IP and domain reputation on blocklists, or use online deliverability testing tools.
Phase 3: Effective Reject Enforcement (p=reject)
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"Once legitimate mail consistently reaches recipient inboxes during Phase 2, update the record to achieve Effective Reject protection across the primary domain and subdomains. Continue monitoring aggregate reports to detect ongoing spoofing campaigns and catch any new delivery issues.