Email security for GDPR: SPF, DKIM, and DMARC explained

Email security and GDPR compliance are more connected than most organizations realize. An attacker spoofs your domain, sends a phishing email to your customers, steals their credentials, and accesses personal data. You're now facing a data breach, and the chain started because your domain lacked three DNS records.

SPF, DKIM, and DMARC are email authentication protocols that prevent unauthorized parties from sending email as your domain. They're free to implement, built into DNS, and increasingly expected by regulators as baseline security measures.

The spoofing-to-breach chain

Without email authentication, anyone can send emails that appear to come from your domain. The receiving mail server has no way to verify the sender's identity. This enables a predictable attack chain.

1. Attacker sends a phishing email from your-domain.se to your customers or employees
2. Recipients trust the email because the sender address matches your real domain
3. They click a link, enter credentials on a fake login page, or open a malicious attachment
4. Attacker gains access to accounts containing personal data
5. You now have a data breach with GDPR notification obligations under Articles 33 and 34

GDPR Article 32 requires "appropriate technical measures" to protect personal data. Allowing your domain to be trivially spoofed, when free industry-standard countermeasures exist, is difficult to defend as "appropriate."

SPF: declaring who can send as your domain

Sender Policy Framework (SPF) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to verify the sending server is on the list.

• Published as a DNS TXT record on your domain (e.g., v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all)
• include: directives authorize third-party mail services (Google Workspace, Microsoft 365, Mailchimp)
• -all means reject emails from any server not listed — the strictest and recommended setting
• ~all (softfail) marks unauthorized emails as suspicious but still delivers them — weaker protection
• +all allows any server to send as your domain — never use this

A common misconfiguration is using +all or omitting the -all qualifier. This effectively disables SPF protection while giving the appearance of having it configured. Vakteye's email security scan specifically checks for this.

DKIM: cryptographic email signatures

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every email your server sends. The receiving server uses a public key published in your DNS to verify the signature, confirming that the email content hasn't been altered in transit and that it originated from an authorized sender.

• Your mail server signs each email with a private key
• The corresponding public key is published as a DNS TXT record (selector._domainkey.yourdomain.se)
• Receiving servers verify the signature against the public key
• If the email was modified in transit, even by a single character, verification fails
• DKIM selectors should be rotated periodically to limit the impact of key compromise

DKIM provides integrity verification that SPF cannot. SPF tells you the email came from an authorized server. DKIM tells you the email content is authentic and unaltered. Together, they cover both the sender and the message.

DMARC: the enforcement layer

Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together and tells receiving servers what to do when authentication fails. Without DMARC, SPF and DKIM failures are logged but emails are often delivered anyway.

DMARC also requires alignment: the domain in the visible From header must match the domain validated by SPF or DKIM. This closes the loophole where an attacker passes SPF with their own server but spoofs the From header.

• p=none — monitor only. Emails are delivered regardless of authentication results. Use this to start collecting data without blocking legitimate mail.
• p=quarantine — failed emails go to spam. A good intermediate step while verifying that all legitimate sending sources are configured.
• p=reject — failed emails are blocked entirely. The strongest protection, recommended as the end goal.
• rua= — aggregate report address. You receive daily reports showing who is sending email as your domain.
• ruf= — forensic report address. Detailed reports on individual authentication failures.

The recommended path: start with p=none and the rua tag to receive reports. Analyze the reports for two to four weeks to identify all legitimate sending services. Configure SPF and DKIM for each. Then move to p=quarantine, and finally p=reject.

Bonus: BIMI, your logo in the inbox

Brand Indicators for Message Identification (BIMI) displays your organization's logo next to authenticated emails in supported email clients (Gmail, Apple Mail, Yahoo Mail). It requires DMARC with p=quarantine or p=reject as a prerequisite.

BIMI is not a security protocol. It is a trust signal. When customers see your verified logo, they can distinguish your real emails from potential spoofs. It also creates a business incentive to maintain strong DMARC enforcement, since relaxing your policy means losing the logo.

• Requires DMARC policy of p=quarantine or p=reject
• Published as a DNS TXT record (default._bimi.yourdomain.se)
• Points to an SVG Tiny PS logo file hosted on your server
• Some providers require a Verified Mark Certificate (VMC) from a certificate authority

Why email security is a GDPR obligation

GDPR Article 32 requires "appropriate technical and organisational measures" for security of processing. Email authentication is industry-standard, free to implement, and directly prevents a known attack vector that leads to data breaches. Omitting it is hard to justify.

NIS2 Article 21(2)(e) requires security in the acquisition, development, and maintenance of network and information systems, including vulnerability handling. An unprotected email domain is a known vulnerability.

Beyond regulatory requirements, there's a practical chain of liability. If your domain is spoofed to phish your customers and a breach occurs, you face notification obligations under GDPR Articles 33 (to the supervisory authority within 72 hours) and 34 (to affected individuals). The fact that the initial spoofing was preventable with standard DNS records will factor into any assessment of your security measures.

What Vakteye checks

Vakteye's email security scanning task queries your domain's DNS records and evaluates the full authentication chain. The scan checks SPF, DKIM, DMARC, and BIMI configuration, and flags common misconfigurations that undermine protection.

• Missing SPF record or overly permissive qualifiers (+all, ~all instead of -all)
• DMARC missing entirely, or set to p=none without a plan to escalate
• DKIM records not published or using weak key lengths
• BIMI readiness assessment based on current DMARC policy
• Each finding mapped to GDPR Article 32 and NIS2 requirements with specific remediation steps

All findings include the exact DNS records you need to add or modify. You get the TXT record values ready to paste into your DNS provider.

Getting started

Email authentication takes an afternoon to set up and pays off immediately. Three DNS records protect your domain and your GDPR compliance position.

1. Check your current setup. Run a Vakteye scan or use free tools to inspect your DNS records
2. Add SPF if missing. List all services that send email as your domain, end with -all
3. Enable DKIM. Most email providers (Google Workspace, Microsoft 365) have built-in DKIM setup
4. Publish DMARC with p=none and rua= to start collecting reports immediately
5. Analyze reports for 2-4 weeks to identify all legitimate senders
6. Escalate to p=quarantine, then p=reject to complete the enforcement chain

Every week without DMARC enforcement is another week attackers can send emails as your domain. The implementation takes an afternoon.