Organisations have invested heavily in email authentication. Primary domains are increasingly protected by SPF, DKIM and DMARC, while security teams monitor authentication failures and work toward stronger enforcement. Yet another part of the domain portfolio often receives far less attention: the domains nobody remembers owning.
Somewhere in an organisation's domain portfolio, there may be a domain purchased for a marketing campaign years ago, inherited through an acquisition or registered by someone who has since moved teams. It may have no website, send no email and appear in no asset register, yet continue to renew every year.
Because it sends no email, nobody may have configured DMARC on it. That can leave the domain without the same protections applied to the organisation's primary email domain, creating an opportunity for an attacker to send messages claiming to represent the organisation.
We did the homework. We may not have learned the lesson.
The industry has made significant progress on email authentication. Requirements introduced by major mailbox providers, including Google, Yahoo and Microsoft, have accelerated DMARC adoption, particularly among organisations sending email at scale. However, adoption is not the same as enforcement.
A domain publishing DMARC with p=none is monitoring authentication activity; it is not instructing receiving systems to quarantine or reject messages that fail DMARC. Enforcement begins with policies such as p=quarantine or p=reject. There is a reason organisations can hesitate to make that transition. Moving a live sending domain to enforcement can expose an incomplete understanding of who is authorised to send email on the organisation's behalf. There may be an undocumented marketing platform, an invoicing system inherited through an acquisition, a regional business using a third-party provider or an application that has quietly been sending mail for years. For that reason, p=none can be a valuable diagnostic stage. The problem arises when that diagnostic stage becomes the permanent state of the domain.
This highlights a broader issue with enterprise DMARC programmes: the biggest obstacle is often not DNS configuration or technology, but ownership. Marketing may own some senders, HR others, regional business units may operate systems headquarters does not know about and security may own the authentication policy without owning the underlying senders.
DMARC is an ownership problem wearing a DNS costume
Ask an organisation about its DMARC posture and the conversation usually begins with its primary production domain. Ask how many domains the organisation actually owns and the answer may be considerably less certain. Large enterprises typically own substantially more domains than they use for email. There are defensive registrations, country variants, former campaign domains, legacy brands and domains inherited through acquisitions. Some exist primarily to protect trademarks or prevent obvious lookalikes. A DMARC programme focused only on domains that send email can therefore leave part of the portfolio exposed.
An attacker can examine SPF, DKIM and DMARC information through public DNS and identify where authentication is enforced and where it is absent. A primary production domain with strong authentication can simply be skipped. A legacy regional domain with no DMARC record may present an easier opportunity. There is nothing particularly sophisticated about this approach. An attacker does not need to overcome the organisation's strongest defences if another part of the same brand portfolio remains unprotected.
The easiest domains to fix are often the ones nobody is looking at
Not every domain presents the same challenge. Moving a heavily used domain to DMARC enforcement can require significant investigation into legitimate senders, third-party services, forwarding behaviour and business dependencies. A genuinely parked or non-sending domain is different.
If the domain has been verified as inactive, there may be no legitimate sender inventory to reconcile and no business application that could be disrupted. Strong email controls can therefore often be introduced with minimal business impact. Depending on the domain's intended purpose and architecture, controls may include:
- SPF: Publish a policy that authorises no senders, where appropriate.
- DMARC: Apply an enforcement policy such as p=reject, including appropriate subdomain controls.
- DKIM: Ensure there is no active signing configuration that could be misused.
- MX: Use a null MX configuration where the domain should not receive email.
The exact configuration should always be validated against the domain's intended use. The larger lesson is more important than the DNS configuration itself: organisations cannot protect what they do not know they own. That makes the domain registrar an important starting point for an enterprise DMARC programme. It may reveal domains that have disappeared from asset registers, security inventories and business processes but have never disappeared from the internet.
The ceiling: DMARC cannot protect your brand from everything
An organisation can secure every domain it owns and still be impersonated. DMARC helps establish whether an email claiming to come from a domain is authenticated according to that domain's published policies. It does not establish whether the domain itself is legitimate. An attacker can register a lookalike domain using a subtle character substitution, a different top-level domain or a visually similar domain designed to deceive a recipient. The attacker can then configure SPF, DKIM and DMARC correctly. The resulting message can pass authentication because, technically, it is authentic email from that domain. The problem is that the domain itself is fraudulent.
DMARC also does not establish the intent of the person operating a legitimate account. Consider a compromised supplier mailbox: an attacker can reply inside an existing invoice conversation using the correct message history, signature and tone. SPF, DKIM and DMARC may all pass because the sending domain is legitimate. The email is authentic, but the transaction is not. GenAI adds another dimension. The grammatical errors and awkward phrasing that once helped employees identify suspicious messages are becoming less dependable indicators. Authentication remains essential, but it cannot be treated as proof that an email is safe.
Read your own list first
A mature email-security programme should begin with a deceptively simple question: what domains does the organisation actually own?
From there, security leaders can focus on five priorities:
- Measure enforcement, not adoption. A p=none policy provides visibility but does not actively protect against unauthenticated email.
- Count domains, not just sending domains. Coverage should be measured across the entire domain portfolio.
- Lock down genuinely parked domains. Verified non-sending domains can often be secured with minimal business impact.
- Find the owner before finding the tool. Establish who owns each domain and sender inventory and who has authority over email authentication.
- Treat authentication as the floor, not the ceiling. Lookalike domains, compromised accounts, thread hijacking, supplier compromise and AI-enabled attacks require additional controls.
Technology can identify the problem, but clear accountability is what enables the organisation to resolve it.
The list is the attack surface
The domain an organisation forgot it owned still carries its name. An attacker does not care that nobody internally remembers it; what matters is whether customers, employees and partners might recognise it and trust a message sent from it. The production domain is protected because everyone knows it matters. The forgotten domain can remain exposed because nobody remembers that it exists. Yet both belong to the same organisation and both can be discovered through the same public infrastructure. The organisation and the attacker are therefore working from the same list. The difference is that the attacker may have already read it to the end. A resilient email-security strategy does not stop at the domain everyone knows. It starts by finding the domains nobody remembers.
