Digital Sovereignty Begins With Sender Identity: Who Sends Email in Your Name?

Digital sovereignty is usually discussed in terms of clouds, data centers, and jurisdictions. Yet one of the most exposed assets sits in plain sight: your sender identity. Any service authorized in your DNS can send email that passes authentication as your domain, and many organizations no longer know which ones those are. This practical guide shows how to regain control over your sender identity with SPF, DKIM, and DMARC in six steps and with a checklist.

Control over your domain means control over who speaks for you

Digital sovereignty is often framed as a question of where data is stored and under which jurisdiction. A less visible question is who is allowed to act in an organization's name. Your sender identity, the domain that appears in the From address of every email, is exactly that: a statement of authorship that customers, partners, and mailbox providers trust.

That trust can be shared without anyone noticing. Over the years, organizations connect newsletter tools, ticketing systems, CRM platforms, HR software, and invoicing services, each authorized through an entry in the domain's DNS. Contracts end and project teams move on, but the entry often stays. The result is a group of senders that can deliver authenticated email as your domain while no one in the company can name them all. Sovereignty over your sender identity means closing this gap: knowing who sends, deciding who may, and being able to withdraw that permission.

What SPF, DKIM, and DMARC do, and what they do not

Three standards form the technical basis. SPF (RFC 7208) lets a domain publish which servers may send on its behalf. DKIM adds a cryptographic signature, and the matching public key is published in DNS under a selector, so receivers can verify that a message was signed by an authorized system. DMARC ties both to the visible From domain, a check called alignment, and tells receivers what to do with failing mail: nothing (p=none), treat it as suspicious (p=quarantine), or reject it (p=reject). It also requests reports. DMARC is now specified in RFC 9989 (May 2026), which replaces RFC 7489, and aggregate reporting is covered in RFC 9990.

One limit matters here: authentication is not control. A forgotten but correctly configured service passes every check. Enforcement keeps out senders that were never authorized, but it cannot tell you whether an authorized sender should still be authorized. That judgment stays with the organization.

Why expectations around sender identity are rising

Mailbox providers have made authentication a precondition. Google requires SPF or DKIM from all senders to Gmail accounts, and SPF, DKIM, and DMARC from those sending more than 5,000 messages per day (support.google.com/mail/answer/81126). Yahoo expects bulk senders to implement SPF, DKIM, and at least a DMARC policy of p=none with a reporting address (senders.yahooinc.com/best-practices). In Germany, the Federal Office for Information Security (BSI) has published Technical Guideline TR-03182 on email authentication, with requirements for email service providers. Whether or not these rules apply directly, they show where expectations are heading.

A practical path to control over your sender identity

Six steps lead from observation to enforcement. The order matters, because tightening a policy before the inventory is complete is a common reason legitimate email gets blocked.

Step 1: Make every sender visible

Publish a DMARC record with p=none and a reporting address (rua). Receivers then send aggregate reports showing which systems send email using your domain and whether they pass SPF, DKIM, and alignment. Collect data for at least two to four weeks to catch monthly senders such as billing runs, and use a tool that parses the XML reports. Such tools are available from several providers, for example the DMARC Analyzer from LEMARIT, the author's company. Keep in mind that reports show infrastructure, such as IP addresses and sending services, not business purpose.

Step 2: Assign an owner to every sender

For each source, record a responsible person or team, the business purpose, and the contact for changes. A source without an owner is a finding, not an exception. Keep this inventory where procurement and onboarding processes can reach it.

Step 3: Retire what nobody claims

Ask owners to confirm or retire each source. Remove obsolete SPF includes and unused DKIM keys. This also protects against the most common technical failure: SPF allows at most ten DNS-querying terms (RFC 7208). Every additional service adds lookups, and once the limit is exceeded, SPF evaluation ends in a permanent error. Services that depend on SPF then fail authentication, and their email can no longer be delivered reliably.

Step 4: Fix authentication and alignment

Make sure every legitimate sender passes SPF or DKIM in alignment with your From domain. DKIM is usually the more robust choice, because it survives forwarding better than SPF, and signing with your own domain keeps alignment intact. Where possible, give external services their own subdomains, for example news.example.com, to keep their lookups and risks separate from your main domain.

Step 5: Enforce in stages

Move from p=none to p=quarantine and then to p=reject, with a monitoring period at each stage. Check the reports after every change and keep a rollback path. Allow more time where many systems and service providers are involved. Quiet reports, not the calendar, are the signal to move on.

Step 6: Keep control in daily operations

DMARC is operations, not a project. The second frequent cause of outages is change: a service that is added or retired without being reflected in your SPF, DKIM, and DMARC setup. A new tool starts sending before anyone authorized it, and a legitimate mailing is rejected. A retired tool leaves its entry behind and keeps an open door. Add a DNS check to the onboarding of every service that sends email and to its offboarding when the contract ends, review reports monthly, and define who may change DNS records and how changes are approved.

Checklist

☐  A DMARC record with a reporting address is live.

☐  All sending sources are listed, and each has an owner.

☐  Obsolete SPF includes and DKIM keys are removed.

☐  SPF stays within ten DNS-querying terms, with headroom for new services.

☐  Every legitimate sender passes with aligned SPF or DKIM.

☐  External services use their own subdomains or your own DKIM keys.

☐  The policy is at quarantine or reject, and reports are reviewed after each change.

☐  Onboarding and offboarding of sending services include a DNS check.

☐  Responsibilities for DNS changes are documented.

Sender identity as a trust anchor

Organizations that know who sends in their name can demonstrate it to customers, auditors, and mailbox providers. Those who do not are exposed twice: to outsiders who impersonate them and to their own forgotten integrations. Taking control of your sender identity is a small, concrete, and measurable step toward digital sovereignty, and it begins with a DNS record and an honest inventory.

Thomas Kuchenthal is Co-Founder, Co-Managing Director, and CTO of LEMARIT GmbH. He has more than 20 years of experience in the domain market, focusing on DNS, IT security, and digital identities. LEMARIT is a provider of corporate domain services and digital brand protection based in Harrislee, Germany.