One of your customers receives an email. It carries the name of your latest marketing campaign, it looks clean, it announces new bank details. The customer calls. You have your mailbox access checked: no compromised account, no suspicious sign-in. Relief. And yet the address displayed in that message belongs to a domain your company owns. Fictional example, ordinary scenario.
The relief is a mistake. Nobody broke in, because nobody needed to: anyone can borrow a domain you own but have never protected to write to your customers in your name. A forgotten domain is not a housekeeping detail, it is a blank signature.
I wrote dns-posture, a tool published on npm with public source code on GitHub, because I kept finding this problem in almost every domain portfolio I looked at. It helps a technical team review its OVHcloud and Cloudflare domains, spot missing protections and lock down the names that should never send a message. But the tool comes second. First, you need to understand why the leader asked the wrong question.
Owning a name tells nobody who is allowed to use it
The leader checked his passwords because that is the only picture he has of an attack: someone forcing a door. But an email needs no door. The sender writes whatever address they like in the “From” field. The receiving server cannot infer from that field alone that the message is legitimate. Rules published by the domain owner give it ways to check. You hold the title deed; you never fitted a lock.
Who leaves a domain without a lock? Everyone. The name reserved for a launch that never happened. The domain of the acquired brand, kept “just in case”. The one the agency registered for a campaign and nobody took back when the contract ended. And, more awkwardly, the main domain itself, which management assumes is protected because it works. That a domain receives its email properly says nothing about what it has declared on who may send it. The reverse exists too: some providers already configure part of the protections. You only find out by looking at the actual configuration, not at the registrar’s invoice.
In our story, the customer recognised the campaign’s name. That recognition is what the forged message came to borrow. Your reputation works for the attacker as long as your domains are not working for you.
SPF, DKIM, DMARC: three lines in DNS to say no
DNS is your domain’s technical directory. It is also where you publish, for every mail server in the world, the rules that let them judge an email claiming to come from you. Three mechanisms, one sentence each. SPF lists the servers authorised to send in your name. DKIM attaches a signature to the message that the recipient can verify. DMARC ties those two checks to the domain shown in the sender’s address, and tells the recipient what to do when they do not match: nothing, quarantine, or reject.
ANSSI, France’s national cybersecurity agency, describes these mechanisms in chapter 5.4 of its Internet interconnection guide. For a live email service, its recommendation R48 calls for an observation phase before a strict DMARC policy: first see who sends legitimately, then reject. That is wise. Reject too early and it is your own invoices that recipients turn away.
But for our small company’s campaign domain, it is far simpler, and it is what most teams forget to look at. That domain must never send an email. Ever. So there is nothing to observe: you publish an SPF rule that authorises no server, and a DMARC policy asking for the rejection of any message that fails. Three lines. From then on, recipients who apply those rules finally have grounds to bin the forged message. The domain that sends the real invoices calls for more patient work with the email provider and every application that legitimately sends. But the silent domains, you can close this month.
What those three lines do not stop
The impersonation we have just closed serves every purpose: spam, a fake sign-in page, a payment request made credible. A targeted attack adds the name of one of your employees, a real order number and the right moment in a commercial relationship. The care taken over the staging changes nothing about the substance: the sender has to be verified.
DNS rules close one door, not all of them. They do not protect against a genuinely compromised account sending from your authorised servers. They do not protect against a lookalike domain, one letter different, that the attacker buys for a few euros. They do not filter the spam arriving in your inboxes. Account security, message filtering and, above all, checking a change of bank details through another channel, a call to the number you already had, remain operational security subjects in their own right.
In our story, then, it is the payment process that must save the customer, not the look of the email. Domain protection gives him one more signal. It does not excuse him from picking up the phone.
Close the silent domains, watch the one that speaks
Two decisions, not ten. Explicitly close sending on every domain that should send nothing. Have the authorised senders on the live email domain reviewed, with the observation phase ANSSI recommends. From there, every name you own has a known protection perimeter, whatever its commercial use, or lack of one.
The first decision is what dns-posture exists for. It draws up the inventory, assesses each domain’s configuration and produces a report readable by someone who does not read DNS: which names were reviewed, which controls fail, which corrections the team proposes. You can then assign an owner and a deadline, as for any other technical governance matter. For a domain with no legitimate sending, the tool prepares the changes, keeps a backup, writes only on explicit request and reads the result back from the provider. If it detects email activity, it refuses to harden by default: breaking your invoices is not a fix. It does not configure DKIM signing for a live email service, and a report on DNS remains a report on one part of your security. The project is independent; citing ANSSI provides a frame of reference, not a stamp.
In our scenario, borrowing the campaign’s name required no compromised account. That trust in the displayed name is what I want examined, before the next change of bank details.
The logical next step is not to lose that visibility when suppliers and projects change. I describe it in auditing domain names, from inventory to monitoring report. The team will find the npm package and its documentation on GitHub to reproduce the approach.