Almost every security control you operate is invisible from the outside. Email authentication is the exception. Your SPF, DKIM and DMARC records sit in public DNS, and anyone assessing you (a prospective customer, an insurer, a counterparty's due-diligence team) can check them in seconds, before they send you a questionnaire and without asking your permission. That asymmetry is why this subject is worth more attention than its technical weight suggests.
Email is also the channel through which most attacks begin, and through which, in many organisations, the largest share of personal data leaves the perimeter. From a compliance angle the topic splits into two questions that are frequently conflated: how do you protect your own mailbox from harmful messages, and how do you stop third parties writing in your domain's name? SPF, DKIM and DMARC answer only the second.
The three mechanisms
| Mechanism | What it establishes | Where it lives |
|---|---|---|
| SPF | Which sending systems are permitted for a domain | A record in the domain's DNS |
| DKIM | A cryptographic signature over headers and content that evidences origin and makes alteration detectable | Public key in DNS, signature in the message |
| DMARC | How recipients should treat messages that fail the check, and where reports go | A record in the domain's DNS |
The mechanisms build on one another. SPF and DKIM each produce a check result but say nothing on their own about the sender address visible in the mailbox. Only DMARC ties the check result to the visible sender domain and determines what happens on failure: no action, delivery to quarantine, or rejection.
Hence the point that matters most: a DMARC record without an enforcing policy is an observation post, not a protective measure. It produces reports and prevents nothing.
Report the record as an implemented measure without having reached enforcement and you have an explanation problem in an audit: the records are publicly queryable and can be checked against your claim on the spot.
Getting to an enforcing policy
The move from monitoring to rejection is a project, not a switch. It requires cataloguing every system that sends in the domain's name: business applications, newsletter platforms, ticket systems, HR systems, service providers. That inventory is the real gain: it reliably surfaces sending paths nobody was still counting on. The DMARC reports serve as a source of discovery until the inventory is complete.
The reports themselves deserve a data protection look. Aggregate reports contain information about sending systems and check results; detailed forensic reports can include headers of individual messages. Whether and to what extent the latter are requested should be a deliberate decision rather than left to a default.
What these mechanisms do not do
SPF, DKIM and DMARC protect your own domain from misuse by third parties. They do not protect against messages from lookalike domains, against compromised mailboxes belonging to genuine business partners, or against attachments. Protecting the inbox is a separate task and rests on filtering, inspection of attachments and links, and awareness among staff.
Nor do they replace encryption. Transport encryption between servers is widespread today but not guaranteed, and it does not protect content from the systems involved. Anyone sending confidential or particularly sensitive data needs content encryption or a different transmission route. That determination belongs in the cryptography concept and in the data classification rules, not in a sender's case-by-case judgement.
Where this sits in regulation
Art. 32 GDPR requires measures appropriate to the risk; for a channel over which personal data is regularly transmitted, that covers both protection of the transmission and precautions against misdirected mail and identity misuse.
For entities within the scope of the German BSI Act, the catalogue of measures in § 30(2) sentence 2 BSIG names in no. 1 policies relating to risk analysis and to security in information technology, and in no. 10, among other things, secured voice, video and text communication within the entity. Securing the outward-facing side through SPF, DKIM and DMARC is therefore not an expressly named individual measure but part of the general security concept, though it is one of the few whose implementation an assessor can establish from outside and without any cooperation from the organisation.
Evidence
What serves as evidence: the current DNS records for every domain in use, including those not used for sending; a register of authorised sending systems with an owner for each; an evaluation of DMARC reports over a period; the determination on encryption by data class; proof of filtering for inbound messages; and the results of awareness measures. The unused domains are the ones regularly forgotten. They are particularly well suited to misuse, precisely because nobody expects mail from them.
Where the domain sits in the inventory
Email security has a peculiarity that makes it invisible in registers: part of what needs protecting is not a system but a name. Your own domain appears on no server list, which is why the question of who owns its DNS records often has no quick answer.
In Rizzqo that object is carried too. The mail service, the DNS operator and a security gateway are supporting assets with a category, a named owner and links to the business processes running through them. The ISO/IEC 27002 requirements on protecting communication appear on those objects and are answered and evidenced there. The side effect is the real gain: when three providers are authorised to send in the name of the same domain, that sits in the model rather than in one administrator's recollection.