Domain, DNS and email security for a multi-brand group

Most security incidents at small companies are not clever. A domain expires because the card on file changed. A former contractor still has the registrar login. Somebody deletes a DNS record while "tidying up" and the checkout stops sending order emails. A stranger sends invoices that appear to come from the company, and customers pay them.

None of this requires a sophisticated attacker. It requires a gap. For a group like Oryvelon, which builds and runs several independent companies, those gaps multiply with every brand. Eight companies, each with a primary domain, a few defensive registrations, a handful of email services and a DNS zone, is a lot of surface to leave to memory.

This article describes our baseline for domain, DNS and email security: how we register and hold domains, how we keep DNS consistent, and how we set up SPF, DKIM and DMARC for each sending domain. None of it is exotic. The value is in doing all of it, for every brand.

Why domains are infrastructure, not admin

A domain feels like a one-off purchase. In practice it is the root of almost everything a digital company depends on. The website resolves through it. Email is delivered to and from it. Password resets for dozens of services go to addresses on it. Payment providers, app stores and ad platforms verify ownership through it. Search engines tie a site's reputation to it.

Lose control of a domain, even for a few hours, and you can lose all of those at once. Someone who controls your DNS can point your site elsewhere, receive your email, issue certificates for your name and reset passwords on accounts registered to your addresses.

That is why domain handling sits in our infrastructure standards alongside access control and secrets, not in a spreadsheet of subscriptions. We treat the registrar account as one of the most sensitive systems the group has. The naming and brand architecture work decides which domains a company needs. This article is about keeping them.

Registration and ownership

The first rule is simple: domains belong to the group, in a group-controlled account. Not in a founder's personal account, not in a freelancer's account, not in whichever account happened to be open when the name was bought.

This matters more than it sounds. When a domain sits in an individual's account, the company's most important asset is tied to one person's email, one person's phone for two-factor codes and one person's continued goodwill. When that person leaves, changes phone numbers or simply forgets which registrar they used, the company inherits a problem.

Our registration baseline looks like this:

• Group-controlled registrar account, with two-factor authentication on every login that can reach it.
• Named access. A small number of named people, each with their own login. No shared passwords. See least-privilege access for small teams.
• Registrant contact details that point to a role mailbox the group controls, not a personal inbox. If the registrar needs to reach us about a transfer or a dispute, the message must arrive.
• A domain register. One written list of every domain the group holds, which company it belongs to, what it is used for (primary, redirect, defensive, email only) and when it renews.

The register is a small thing that solves a surprising number of problems. When a company like KeşifAtlası needs to know whether it owns a regional variant of its name, the answer is one lookup. When we review costs, defensive domains that no longer earn their keep are visible. When a company is ever sold or spun out, the list of what goes with it already exists. That last point connects to a wider principle: every company should be able to stand alone, and its domains are part of what it takes with it.

Locks, auto-renew and expiry

Two settings prevent most domain disasters: the registrar lock and auto-renew.

Registrar lock (often called transfer lock, shown as clientTransferProhibited in WHOIS or RDAP data) stops the domain being transferred to another registrar unless the lock is first removed from inside the account. It is free and turns a common hijacking route into something that requires access to our account first. For the most important domains, some registries offer a stronger registry-level lock that requires manual verification before changes. For a primary brand domain, that extra step is often worth considering.

Auto-renew should be on for every domain we intend to keep. Renewal failures are rarely about money. They happen because a card expires, a billing email goes to someone who left, or a renewal notice lands in spam. To make auto-renew actually work, we also:

• keep a valid payment method on the account and review it when cards change;
• renew primary domains for multiple years where it makes sense, so a single failed charge is not a crisis;
• send registrar notifications to a monitored role address;
• check upcoming renewals as part of our regular operating cadence.

The quarterly review is where defensive domains get a decision. If a typo domain has sat unused for two years and nothing points to it, we may let it lapse on purpose. The important word is on purpose. An expiry should be a choice written in the register, never a surprise.

One DNS standard for every brand

Each company has its own DNS zone. What they share is a standard: the same structure, the same naming conventions, the same baseline records and the same rules about who can change what.

A shared DNS standard is not about uniformity for its own sake. It is about making anomalies visible. When every zone follows the same pattern, a record that does not belong stands out immediately. When every zone is different, nobody can tell whether an odd CNAME is a forgotten experiment, a legitimate service or something worse.

Our DNS standard covers:

Two items on that list deserve a note.

Dangling records are the quiet risk. A subdomain points to a hosting service or storage bucket that was later deleted. If someone else can claim that resource name on the same service, they can serve content on your subdomain. The fix is housekeeping: when a service is decommissioned, its DNS records go with it, and periodic reviews look for records pointing at things that no longer exist.

CAA records limit which certificate authorities can issue certificates for a domain. They do not stop every attack, but they narrow the ways someone could obtain a valid certificate for one of our names, and they cost nothing to publish.

Where the registry and DNS host support it, DNSSEC adds signatures that protect against forged DNS answers. It needs care, because a misconfigured DNSSEC setup can take a domain offline, so we enable it deliberately and check it after any change of DNS host.

Email authentication: SPF, DKIM and DMARC

Email was designed without any built-in proof of who sent a message. Anyone can put any address in the From line. SPF, DKIM and DMARC are the three standards that, together, let receiving mail servers check whether a message claiming to come from a domain really did.

For a group with several brands, this matters twice. It protects customers from convincing phishing in our names. And it protects deliverability: mailbox providers increasingly expect bulk senders to authenticate properly, and messages that fail these checks are more likely to be filtered or rejected.

SPF: which servers may send

Sender Policy Framework is a TXT record on the domain listing the servers and services allowed to send mail for it. A typical record looks like this:

v=spf1 include:_spf.example-mailservice.com include:mail.example-helpdesk.com -all

The includes name each legitimate sending service. The final -all tells receivers that anything else is not authorised.

SPF has practical limits worth knowing. It checks the envelope sender (the technical return path), not the visible From address that people actually read. It breaks when mail is forwarded. And a record may trigger at most ten DNS lookups; stack too many includes and the record fails for everyone. That limit is one reason we keep a separate list of every service that sends as each domain, so the SPF record reflects reality rather than history.

DKIM: signing each message

DomainKeys Identified Mail adds a cryptographic signature to each outgoing message. The sending service holds a private key; the domain publishes the matching public key in DNS under a selector, for example s1._domainkey.brand.com. Receivers use it to verify that the message was signed by someone authorised and was not altered in transit.

Each sending service should sign with the brand's own domain, not only with the service's default domain. That detail is what makes DMARC alignment possible. We also prefer keys of adequate length and rotate them when a service changes or on a periodic schedule.

DMARC: the policy that ties them together

Domain-based Message Authentication, Reporting and Conformance is the layer that tells receivers what to do when a message fails, and asks them to send reports. A DMARC record lives at _dmarc.brand.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@brand.com; adkim=s; aspf=r

DMARC introduces alignment: the domain in the visible From address must match the domain that passed SPF or DKIM. This closes the gap SPF leaves on its own. A message can pass SPF for some unrelated domain and still fail DMARC because it does not align with the brand it claims to be from.

The policy (p=) has three values:

• none — monitor only; deliver as normal but send reports.
• quarantine — treat failing mail as suspicious, usually sending it to spam.
• reject — refuse failing mail outright.

Rolling DMARC out without breaking your own email

The common mistake is jumping straight to p=reject and discovering, a week later, that the helpdesk's replies, the invoicing tool and the review-request service were all sending unaligned mail. Customers stop getting messages and nobody notices until someone complains.

We move each sending domain through stages:

1. Inventory. List every service that sends as the domain: the mailbox provider, the store platform, transactional email, marketing email, helpdesk, invoicing, form notifications. This is the step people skip, and it is the one that matters most.
2. Authenticate. Add each service to SPF and set up DKIM signing with the brand's domain.
3. Monitor. Publish DMARC at p=none with aggregate reporting. Read the reports for a few weeks. They show every source sending as the domain, legitimate or not.
4. Fix. Anything legitimate that fails alignment gets fixed. Anything unexpected gets investigated.
5. Enforce gradually. Move to p=quarantine, optionally with pct= to apply it to a fraction of mail first, then to p=reject once reports are clean.
6. Keep watching. New services get added over time. Reports keep telling us when something new starts sending.

The pace depends on the company. A brand that sends little email can reach enforcement quickly. A commerce company like Noveniq, where order confirmations, shipping updates and marketing all come from different systems, takes longer, because every one of those systems needs to align before we enforce.

Domains that never send email

A frequent gap in multi-brand groups is the domain nobody thinks of as an email domain. Redirect domains, defensive typos, regional variants and retired brand names all have one thing in common: if they publish no email records, anyone can try to send mail in their name, and some receivers will accept it.

For every domain that should never send mail, we publish:

v=spf1 -all

v=DMARC1; p=reject;

and, where appropriate, a null MX record signalling that the domain accepts no mail. Three records, a few minutes of work, and a whole class of lookalike phishing becomes harder. In a group where a customer could plausibly receive mail from several related brands, this closes an easy gap.

Separate sending domains, separate reputations

Our principle of shared infrastructure, separate data has a direct email equivalent: shared standards, separate sending identities.

Each company sends as its own domain. MerchNivo sends product and account email as MerchNivo. EduRelia sends as EduRelia. WeAreMedia sends as WeAreMedia. No company sends customer email from an Oryvelon address, and no company sends on behalf of another.

This does three useful things:

• Reputation stays separate. If one brand's marketing email draws complaints, it does not drag down another brand's transactional delivery.
• Customers are not confused. A parent who signed up for EduRelia should never receive a message about a Shopify tool. Separate sending domains reinforce the house-of-brands structure and our rule of no cross-product user data.
• Each company can stand alone. If a company is ever separated from the group, its email identity goes with it intact.

Within a single company, we often go one step further and separate marketing from transactional mail, for example by sending newsletters from a subdomain such as news.brand.com. That keeps password resets and order confirmations flowing even if a campaign performs badly. It also makes consent management cleaner, which we cover in marketing consent vs product consent.

Access, credentials and change control

All of the above can be undone by one weak login. The registrar account, the DNS account and the mailbox administration console are among the systems we protect most tightly:

• Two-factor authentication on every account, preferably with an authenticator app or hardware key rather than SMS.
• Named, individual access. No shared logins. When someone's role changes, their access changes the same day.
• Least privilege. Most people who need to update a website never need registrar access at all.
• API tokens scoped narrowly, stored as secrets and rotated. A token that can only edit one zone is far safer than one that can edit every zone. See secrets management basics.
• Recovery paths checked. Recovery email addresses and phone numbers on these accounts belong to the group, not to former team members.

Changes to DNS follow the same discipline as code changes, on a smaller scale. We write down what is changing and why before we change it, keep a record of the previous value, and check the result afterwards. For planned migrations, TTLs are lowered in advance so a rollback propagates quickly.

A checklist for a new company

When we start a new company, the domain and email baseline is part of the launch checklist. It usually takes less than a day, and it is far easier to do before launch than to retrofit later.

1. Register the primary domain and any defensive variants in the group registrar account.
2. Turn on registrar lock and auto-renew. Record the domains in the register with their owner company and purpose.
3. Create the DNS zone following the standard: canonical host, redirects, CAA, HTTPS everywhere.
4. List every service that will send email as the domain.
5. Publish SPF covering exactly those services, and set up DKIM on each.
6. Publish DMARC at p=none with reporting to a monitored address.
7. Publish v=spf1 -all and p=reject DMARC on every domain that will not send mail.
8. Schedule the DMARC review: read reports, fix alignment, move towards enforcement.
9. Confirm two-factor authentication and named access on the registrar, DNS and mail admin accounts.
10. Add the domain's renewal date and DMARC status to the portfolio review.

The phase-zero site usually goes live on top of this baseline, so the very first page a visitor sees already sits on a locked, authenticated domain.

Common mistakes we design against

A short list of the failures we have seen elsewhere and built our process to avoid:

• Domains bought on a personal card in a personal account, then stranded when that person leaves.
• Auto-renew on, payment method expired. The setting is only as good as the card behind it.
• Two SPF records on one domain. Only one is allowed; two means both are invalid.
• SPF records that grow forever, still listing services dropped years ago and edging past the ten-lookup limit.
• DMARC stuck at p=none. Monitoring is a stage, not a destination. A policy of none protects nobody.
• Forgotten verification and CNAME records that outlive the services they were created for.
• Everyone has admin. Convenience today, incident tomorrow.

Summary

Domain, DNS and email security is unglamorous work that prevents some of the most damaging and most avoidable incidents a small company can face. Our baseline for every Oryvelon company is consistent: domains owned by the group, locked and set to auto-renew, recorded in one register; DNS zones that follow one written standard so anomalies stand out; SPF, DKIM and DMARC on every sending domain, rolled out from monitoring to enforcement based on what the reports show; locked-down records on every domain that should never send mail; and separate sending identities so each brand keeps its own reputation and can stand alone. It takes little time per brand and removes a whole category of risk across the group.

Questions and answers

What is the minimum email security a small brand should set up?

An SPF record listing its real senders, DKIM signing for each sending service, and a DMARC record that starts at p=none with reporting and moves towards quarantine or reject once legitimate mail is aligned.

Should domains that never send email have SPF and DMARC records?

Yes. A domain that sends no mail should publish an SPF record of v=spf1 -all and a DMARC policy of p=reject so nobody can easily send email that appears to come from it.

Who should own the domains in a group of companies?

A group-controlled registrar account protected by two-factor authentication, with named people holding access and a clear record of which company each domain belongs to.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Data, Privacy & Security

NextWhat an AI e-commerce employee is, and what it is not →