Email Security: Setting Up SPF, DKIM, DMARC, and Encryption Correctly

TL;DR

Over 90% of all cyberattacks begin with an email. Phishing, spoofing, and business email compromise (BEC) are the most common methods.
SPF defines which servers may send emails for your domain. DKIM cryptographically signs emails. DMARC links both and defines what should happen with non-compliant messages.
Implementation proceeds in stages: first SPF, then DKIM, then DMARC in monitor mode (p=none), then gradually tighten to p=reject.
TLS encryption for transport is standard today. For end-to-end encryption, S/MIME and PGP are available but have practical limitations.
An email security gateway with spam filtering, malware scanning, and URL rewriting complements SPF/DKIM/DMARC by inspecting the content of incoming messages.

Why email is the most common attack vector

Email is the number-one communication tool in businesses. And that is exactly what makes it the preferred target for attackers. Over 90 percent of all cyberattacks begin with an email -- whether a phishing message with a forged sender, an attachment containing malware, or a deceptively authentic message urging the recipient to transfer money.

The reasons lie in the architecture of the email protocol itself. SMTP (Simple Mail Transfer Protocol), the protocol used to send emails, dates back to the early 1980s. It was designed for a trusted academic network, not an internet full of criminals. In its basic form, SMTP offers no authentication whatsoever: anyone can send an email using any sender address they choose. There is no built-in mechanism to verify whether the sender is actually who they claim to be.

This is as if anyone could mail a letter with any return address on the envelope, and the postal service would never check. That is exactly what happens with email, and that is exactly the problem SPF, DKIM, and DMARC address.

Phishing uses forged sender addresses to deceive recipients. The email appears to come from the house bank, the CEO, or Microsoft, but actually comes from an attacker. The goal: harvest login credentials, install malware, or induce an action.

Business Email Compromise (BEC) is the targeted variant: the attacker impersonates the CEO or a supplier and instructs the accounting department to wire funds to a changed account. BEC attacks cause billions in damages worldwide because they require no malware and are often not caught by technical defenses.

Email spoofing means an attacker sends emails using your company's domain as the sender without your knowledge. Your customers and partners then receive phishing emails that appear to come from you. This damages not only their security but also your reputation and trust.

SPF, DKIM, and DMARC are the three protocols that solve this fundamental problem. They are not optional nice-to-haves but essential email security hygiene. And they can be configured with manageable effort if you know how.

SPF: Who may send emails for your domain?

SPF (Sender Policy Framework) is the first line of defense against email spoofing. It answers a simple question: which servers are authorized to send emails on behalf of your domain?

How SPF works

SPF operates through a DNS TXT record. In this record, you list all IP addresses and servers authorized to send emails with your domain as the sender. When a receiving mail server gets an email that supposedly comes from your domain, it checks your domain's SPF record and compares the sending server's IP address against the list of authorized servers. If the IP matches, the SPF check passes. If it does not match, the check fails.

Creating an SPF record

An SPF record is a DNS TXT entry for your domain. It always starts with the version identifier v=spf1, followed by the authorized sources, and ends with an instruction on how to handle unauthorized senders.

A typical SPF record for a mid-market company looks like this:

v=spf1 mx a:mail.example.de ip4:203.0.113.10 include:_spf.google.com include:spf.protection.outlook.com -all

The individual components mean:

mx allows all servers listed in your domain's MX record to send emails. This is the most obvious entry since your mail server is an authorized sender by definition.

a:mail.example.de allows the server with hostname mail.example.de to send emails. Useful when you have a server that sends emails but is not in the MX record (e.g., an application server sending notifications).

ip4:203.0.113.10 allows a specific IPv4 address to send. Use this for servers without their own hostname or those you want to explicitly name.

include:_spf.google.com incorporates another service's SPF record. If you use Google Workspace for your emails, you must include Google's SPF record so their servers are recognized as authorized senders. The same applies to Microsoft 365, Mailchimp, HubSpot, or any other service sending emails on your behalf.

-all is the closing statement and means: all servers not listed in this record are unauthorized, and emails from these servers should be rejected (hard fail). The softer variant ~all (soft fail) marks non-compliant messages as suspicious but does not reject them. For the introduction phase, ~all is sensible; for production operation, -all is recommended.

SPF limitations

SPF has an important technical limitation: it checks the envelope-from address (the technical sender), not the from address in the header (which the recipient sees). An attacker can send an email where the envelope-from address is their own domain (SPF check passes) but the displayed from address impersonates your domain. That is why SPF alone is insufficient. You also need DKIM and DMARC.

Additionally, there is a DNS lookup limit: an SPF record may trigger a maximum of ten DNS lookups. Each include, a, mx, and redirect counts as one lookup. For organizations using many external services (marketing platform, helpdesk, CRM, accounting software, newsletter tool), this limit is quickly reached. The solution is SPF flattening -- resolving include chains into direct IP addresses -- which must be regularly updated when service IP addresses change.

DKIM: Cryptographic signatures for emails

DKIM (DomainKeys Identified Mail) adds a cryptographic component to SPF. While SPF checks whether the sending server is authorized, DKIM verifies whether the email was tampered with in transit and whether it was actually authorized by the stated domain.

How DKIM works

DKIM is based on asymmetric cryptography. Your mail server signs every outgoing email with a private key. The corresponding public key is published as a DNS TXT record. The receiving mail server reads the signature from the email header, retrieves the public key from DNS, and verifies the signature. If the signature is valid, the recipient knows: this email was actually sent by a server possessing the domain's private key, and the content was not altered in transit.

The signature covers defined header fields (From, To, Subject, Date) and the email body. If any of these are changed after signing, the DKIM check fails.

Setting up DKIM

Setting up DKIM consists of two steps: generating a key pair and publishing the public key in DNS.

Step 1: Generate a key pair. Your mail server or email provider generates a key pair. In Microsoft 365, this happens automatically in the DKIM configuration in the Security portal. On your own mail server, you can generate the key pair with OpenSSL. Use a key length of at least 2048 bits.

Step 2: Create the DNS record. The public key is published as a TXT record under a special hostname. The format is: selector._domainkey.example.de. The selector is a freely chosen name identifying the key (e.g., "s1" or "mail2024"). The record contains the public key in Base64 format.

A DKIM DNS record looks like this:

s1._domainkey.example.de IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Step 3: Activate signing. Configure your mail server to sign outgoing emails with the private key. In Microsoft 365 and Google Workspace, this is a toggle in the administration interface. On Postfix or Exim, you configure OpenDKIM or rspamd as a milter.

DKIM key rotation

As with all cryptographic keys, it is recommended to rotate DKIM keys regularly. Your company's cryptography policy should also cover DKIM rotation. An annual rotation is common practice. You use the selector for this: generate a new key pair with a new selector (e.g., "s2"), publish the new public key in DNS, configure the mail server to use the new selector, and remove the old DNS record after a transition period. By using different selectors, old and new keys can coexist, enabling an interruption-free rotation.

DMARC: The interplay of SPF and DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the umbrella over SPF and DKIM. It solves two problems that SPF and DKIM alone do not address: what should happen to emails that fail the checks? And how does the domain owner learn whether their domain is being abused for spoofing?

How DMARC works

DMARC checks whether an incoming email has passed either the SPF check or the DKIM check, and whether the verified domain aligns with the from address in the header. This alignment is called alignment. SPF alignment means the domain in the envelope-from address matches the domain in the from header address. DKIM alignment means the domain in the DKIM signature (d=) matches the from header domain.

Alignment is the decisive advance over SPF and DKIM alone. SPF alone checks only the envelope-from domain, which the recipient never sees. DKIM alone checks only the signed domain, which is also not necessarily the displayed sender domain. DMARC links both checks to the domain the recipient actually sees in the from field.

DMARC policy and DNS record

The DMARC record is published as a DNS TXT entry under _dmarc.example.de. It defines the policy (what should happen to non-compliant messages) and the reporting address (where reports are sent).

A DMARC record looks like this:

_dmarc.example.de IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.de; ruf=mailto:dmarc-forensic@example.de; pct=100; adkim=s; aspf=s"

The parameters mean:

p=reject is the policy. Three levels are available: none (observe only, no action), quarantine (move suspicious messages to the spam folder), reject (reject non-compliant messages). Introduction proceeds step by step from none through quarantine to reject.

rua=mailto:dmarc-reports@example.de defines the address for aggregate reports. Receiving mail servers send daily or weekly summaries showing which servers sent emails with your domain and whether they passed SPF/DKIM. These reports are invaluable for analysis.

ruf=mailto:dmarc-forensic@example.de defines the address for forensic reports. These contain details about individual failed emails. Not all mail servers send forensic reports, and they can contain sensitive information.

pct=100 indicates what percentage of emails the policy applies to. During the introduction phase, you can start with pct=10 and increase gradually to minimize risk.

adkim=s and aspf=s set alignment to strict. In strict mode, domains must match exactly (example.de = example.de). In relaxed mode (adkim=r), it suffices if the organizational domain matches (sub.example.de matches example.de). For the beginning, relaxed is sensible; for maximum security, switch to strict.

Introducing DMARC step by step

DMARC introduction should never start with p=reject. The reason: you may not know all servers that legitimately send emails with your domain. If you go straight to reject, legitimate emails (newsletters, invoices from the accounting system, notifications from the helpdesk) could suddenly be rejected.

The recommended roadmap:

Weeks 1-2: Set up SPF and DKIM. Ensure all legitimate sending servers are listed in the SPF record and DKIM is activated.

Week 3: Activate DMARC with p=none. In this mode, no emails are blocked, but you receive reports. Analyze the DMARC reports over two to four weeks and identify all servers sending emails with your domain. Add missing servers to the SPF record and activate DKIM where it is still missing.

Weeks 5-6: Switch to p=quarantine. Non-compliant messages now land in the spam folder instead of the inbox. Continue monitoring reports and respond to complaints (e.g., "my invoice emails are no longer arriving"). Start with pct=25 and increase step by step to 100.

From week 8: Switch to p=reject. Non-compliant messages are now rejected. The receiving server does not accept them at all. Start here too with pct=25 and increase step by step. If no issues arise after several weeks at pct=100, you have achieved a complete DMARC implementation.

Reading and analyzing DMARC reports

Aggregate DMARC reports (rua) arrive as XML files by email. In raw format, they are hard to read, but there are free and paid tools that process them: DMARC Analyzer, Postmark DMARC, dmarcian, Valimail, or the open-source tool parsedmarc.

The reports show you for each sending server: IP address, number of emails sent, SPF result (pass/fail), DKIM result (pass/fail), DMARC result (pass/fail), and applied policy. This is the foundation for analysis: which servers send legitimately? Which servers are unauthorized? Are there spoofing attempts?

Set up a weekly review to go through the DMARC reports. During the introduction phase, this is especially important because it helps you identify missing SPF entries and DKIM configurations. In ongoing operations, reports reveal spoofing attempts and configuration changes (e.g., a new service provider wanting to send emails with your domain).

TLS encryption: Securing transport

SPF, DKIM, and DMARC address authenticity and integrity. The confidentiality of email transport is ensured by TLS (Transport Layer Security).

Opportunistic TLS

Most mail servers today support STARTTLS, an SMTP extension that encrypts the connection between two mail servers. The problem: STARTTLS is opportunistic. If the receiving server does not support TLS or the TLS negotiation fails, the email is transmitted unencrypted. An attacker who controls the connection (man-in-the-middle) can deliberately disrupt the TLS negotiation and prevent encryption.

MTA-STS: Enforcing TLS

MTA-STS (SMTP MTA Strict Transport Security) solves this problem. It tells sending mail servers that your domain mandates TLS. If TLS negotiation fails, the email is not sent unencrypted -- delivery fails instead. This is a significantly higher security level.

Setting up MTA-STS consists of two parts: a policy file that must be accessible at https://mta-sts.example.de/.well-known/mta-sts.txt, and a DNS TXT record under _mta-sts.example.de that points to the policy. The policy file defines the mode (testing or enforce), the authorized mail servers, and the maximum cache duration.

DANE and TLSA

DANE (DNS-Based Authentication of Named Entities) is an alternative method for TLS protection built on DNSSEC. Via TLSA records in DNS, the mail server's TLS certificate is verified directly without needing to trust a certificate authority (CA). DANE offers a higher security level than MTA-STS but requires DNSSEC, which makes setup more complex. For mid-market companies, MTA-STS is the more pragmatic path in most cases.

End-to-end encryption: S/MIME vs. PGP

TLS encrypts the transport, not the content. On the mail server, the email sits in plaintext. For situations where the email itself must be encrypted (e.g., confidential contracts, personal data, trade secrets), you need end-to-end encryption. The two established methods are S/MIME and PGP.

S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) uses X.509 certificates issued by a certificate authority. Each employee receives a personal certificate installed in their email client. Outgoing emails are signed with the sender's certificate and encrypted with the recipient's public key.

The advantage of S/MIME: it is integrated into common email clients (Outlook, Apple Mail, Thunderbird) and widely supported in enterprise environments. Certificates can be managed centrally through an internal CA or a commercial provider.

The disadvantage: every communication partner needs their own certificate. Setup and management are complex, especially when communicating with many external partners who do not use S/MIME themselves. Additionally, the recipient's public key must be known in advance, which complicates initial contact.

PGP / OpenPGP

PGP (Pretty Good Privacy) and its open standard OpenPGP work on the same principle as S/MIME but use a decentralized trust model (web of trust) instead of central certificate authorities. Keys are created by users themselves and distributed via key servers or direct exchange.

PGP is used less frequently in enterprise environments than S/MIME because key management is decentralized and therefore harder to control. In the open-source community and among technically proficient users, PGP is widespread. For enterprise use with centralized management, S/MIME is generally the better choice.

Pragmatic recommendation

For most mid-market companies, end-to-end email encryption is not practical for the entire email flow. The overhead for key management and the requirement that both sides must support the same technology make broad deployment difficult. A pragmatic approach: set up S/MIME for communication with defined partners where confidential data is regularly exchanged (your company's encryption strategy should cover this), such as tax advisors, lawyers, and business partners with NDAs. For general email traffic, the combination of TLS transport encryption and SPF/DKIM/DMARC is sufficient.

Email gateway and filtering

SPF, DKIM, and DMARC protect against sender forgery. They do not protect against the content of an email: a phishing URL, a malware attachment, or a social engineering message. For that, you need an email security gateway.

What an email gateway does

An email security gateway (also called a Secure Email Gateway, SEG) sits between the internet and your mail server. It inspects every inbound and outbound email for various threats:

Spam filtering: The basic function. The gateway classifies emails based on sender reputation, content analysis, Bayesian filters, and blacklists as spam or ham.

Malware scanning: Attachments are checked for malware, ideally in a sandbox that executes the attachment in an isolated environment and analyzes its behavior.

URL rewriting and time-of-click protection: URLs in emails are rewritten so they are routed through the gateway. When the recipient clicks the link, the gateway checks in real time whether the target site has since been classified as a phishing site.

Impersonation detection: The gateway detects attempts to impersonate internal employees or known contacts, even when the domain is not exactly spoofed (e.g., example-de.com instead of example.de).

DLP (Data Loss Prevention): Outbound emails are checked for confidential content (credit card numbers, social security numbers, documents classified as confidential). Emails violating the DLP policy are held back.

Gateway solutions for mid-market companies

For organizations using Microsoft 365, Microsoft Defender for Office 365 offers an integrated email security gateway with Safe Attachments, Safe Links, and anti-phishing policies. Google Workspace offers comparable features in its Enterprise license.

Standalone solutions like Barracuda Email Security Gateway, Proofpoint Essentials, Mimecast, or NoSpamProxy offer extended functionality and can be used independently of the email provider. For SMEs with an on-premises mail server, NoSpamProxy is a widely used solution in the German-speaking market.

Costs typically range from 2 to 5 euros per mailbox per month. Given the damage a successful phishing attack can cause, this is an investment that pays for itself many times over.

Testing and monitoring

Configuring SPF, DKIM, and DMARC is not a one-time act but requires regular verification and maintenance.

Testing SPF, DKIM, and DMARC

After setup, verify the configuration using dedicated testing tools. MXToolbox, Mail Tester (mail-tester.com), DMARC Analyzer, and Google Admin Toolbox offer free online tests that check your SPF record for syntax errors, verify DKIM signatures, and validate the DMARC record.

A simple practical test: send an email to a Gmail address and check the email header (in Gmail under "Show original"). There you can see the results of the SPF, DKIM, and DMARC checks. All three should show "PASS."

Also test the negative cases: what happens when someone sends an email with your domain from an unauthorized server? With a correctly configured DMARC policy of p=reject, this email should be rejected.

Ongoing monitoring

DMARC reports: As described, you receive regular aggregate reports. Set up a weekly review and watch for new unauthorized senders, rising failure rates, and changes in mail volume.

SPF record maintenance: Every time you introduce a new service that sends emails with your domain (new marketing tool, new ticketing system, new external service provider), the SPF record must be updated. If you forget, SPF checks for those emails will fail, and with p=reject they will be rejected.

DKIM key rotation: Plan an annual rotation of DKIM keys. Document the process and the timing so you can demonstrate in an audit that keys are regularly rotated.

Certificates for TLS and MTA-STS: TLS certificates on the mail server and the MTA-STS policy have expiration dates. Monitor these deadlines -- an expired certificate can bring all email delivery to a halt.

Documenting email security in the ISMS

For ISO 27001 and NIS2, you need traceable documentation of your email security measures. In ISMS Lite, the DMARC rollout can be created as a measure with a timeline and responsible party, so progress is traceable for the auditor at any time. The following elements belong in the ISMS:

Email security policy: Defines the requirements for SPF, DKIM, DMARC, TLS, encryption, and the email gateway. Specifies which services may send emails with the company domain and who must approve changes to the SPF record.

Technical documentation: Current SPF record with an explanation of each entry, DKIM configuration with selector and key rotation plan, DMARC policy with rationale for the chosen level, MTA-STS configuration, and email gateway settings.

DMARC rollout plan: Document the step-by-step rollout from p=none through p=quarantine to p=reject with timeline, responsibilities, and criteria for escalation to the next level.

Regular reviews: Log the weekly DMARC report evaluations and the actions that result from them. This demonstrates to the auditor that you are not only maintaining the process but actively operating it.

Email security is a team effort

SPF, DKIM, and DMARC are not isolated measures but an interplay. SPF alone has gaps, DKIM alone has gaps, but together with DMARC they form a robust defense against sender forgery. Complemented by TLS encryption for transport and an email security gateway for content inspection, the result is a multi-layered defense that brings your organization's email security to a contemporary level.

Setup is not rocket science. SPF and DKIM can be configured in a few hours. DMARC requires an introduction phase of several weeks to identify all legitimate senders. The greatest effort lies not in technical configuration but in analyzing the DMARC reports and maintaining the SPF record when the service provider landscape changes.

Start today. Check whether your domain already has an SPF record and whether it is correct. Check whether DKIM is activated. Set a DMARC record with p=none and analyze the reports. With each step, your organization's email security improves and the likelihood that your domain will be abused for spoofing decreases.