Practical email security: Implementing DMARC, DKIM and SPF with Postfix and a testing workflow

When you introduce DMARC DKIM SPF, it is more than DNS changes: it is an operational project that requires inventory, MTA design, signing strategy, report handling and secure rollbacks. This runbook is aimed at administrators, system engineers and operators: pragmatic procedures, verification commands, common pitfalls and a clear rollback strategy.

Introducing DMARC DKIM SPF: Brief clarification of terms: SPF, DKIM, DMARC in practice

SPF (Sender Policy Framework) is a DNS TXT record that specifies which servers are permitted to send for the Envelope‑From domain; it primarily protects against direct spoofing of the Return‑Path. DKIM (DomainKeys Identified Mail) cryptographically signs messages; the recipient verifies the signature against a public key in DNS. DMARC (Domain‑based Message Authentication, Reporting & Conformance) links SPF and DKIM and additionally checks Alignment, i.e. whether the verified domains match the visible From: domain. Without alignment, the protection against display spoofing is limited.

Prerequisites and organizational preparation

Before you change records, create a complete inventory of all mail senders: central Postfix relays, applications (e.g. Zammad instances), cloud services (M365, Google, marketing tools), monitoring, backup alerts and external providers. Clarify DNS write permissions, TTL policy (temporarily lower TTL before changes) as well as any split‑horizon DNS setups that may return different answers internally/externally.

Recommended rollout order

1. Activate DMARC with p=none and RUA enabled to make real senders visible.
2. Consolidate SPF: one clean record per domain, observe the lookup limit.
3. Enable DKIM across the board, ideally sign centrally at the relay (OpenDKIM).
4. Monitor and then progressively harden DMARC: quarantine (optionally with pct) → reject.

SPF: practical rules and common mistakes

SPF is technically simple, but in large environments it quickly becomes complex. Important rules:

• Only one SPF‑TXT‑record per domain (multiple records lead to PermError).
• Limit DNS lookups (maximum 10); avoid deep include chains.
• Document every include and verify third‑party senders (newsletters, scanners).

SPF‑example

; SPF für example.tld
example.tld. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailerprovider.net ~all"

Checking SPF

dig +short TXT example.tld
# oder für vollständige Ausgabe
dig TXT example.tld +noall +answer

If you have many includes, consider SPF flattening only with caution or create sending subdomains (e.g. mailer.example.tld) with their own SPF records.

DKIM with Postfix: OpenDKIM as a milter

In Postfix, DKIM is typically implemented via a milter. OpenDKIM is a widely used, stable tool. Decide: central signing at the relay (standardises keys/rotation) or decentralized per host (better assignment of responsibility).

Key strategy

Recommendation: RSA 2048 as a minimum; 1024 is considered obsolete. Use a selector scheme with a time component (e.g. s2026q3) for rotation. Store private keys securely (file permissions, access restrictions) and set regular rotation dates.

OpenDKIM: installation and basic configuration

sudo apt-get update
sudo apt-get install -y opendkim opendkim-tools

; /etc/opendkim.conf (Auszug)
Syslog                  yes
SyslogSuccess           yes
Canonicalization        relaxed/simple
Mode                    sv
Socket                  local:/run/opendkim/opendkim.sock
KeyTable                /etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table
InternalHosts           /etc/opendkim/trusted.hosts

sudo install -d -m 0750 -o opendkim -g opendkim /etc/opendkim/keys/example.tld
cd /etc/opendkim/keys/example.tld
sudo -u opendkim opendkim-genkey -b 2048 -s s2026q3 -d example.tld
sudo chown -R opendkim:opendkim /etc/opendkim/keys/example.tld
sudo chmod 0640 /etc/opendkim/keys/example.tld/s2026q3.private
# DNS prüfen
dig @1.1.1.1 +short TXT s2026q3._domainkey.example.tld

Postfix integration

# /etc/postfix/main.cf (Ausschnitt)
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/run/opendkim/opendkim.sock

Important: During the rollout phase you should set milter_default_action=accept so that milter failures do not block delivery.

DMARC: Enable reporting, tighten policy later

Publish DMARC as a TXT record under _dmarc.example.tld. Start with p=none and a rua recipient to collect aggregate reports and make issues visible.

Initial record

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; fo=1; pct=100"

RUA reports are XML files (often in ZIP) that contain information about SPF/DKIM results, IPs and volume. Use a parser (e.g. open-source tools such as pydmarc) or an external collector; pay attention to storage, retention and data protection of the included IP information.

Understanding alignment

DMARC requires that either SPF or DKIM be aligned with the visible From: domain. Common causes for DMARC failures are:

• The Envelope-From belongs to a third party (provider), while the From: header carries the corporate domain.
• DKIM signs with a different d= domain than the visible From: domain.

Solutions: adjust the Envelope-From (e.g. via relay), sign DKIM so that d= is the From domain, or send via subdomains with their own DMARC.

Testing workflow: measurable and controlled

An iterative approach prevents legitimate systems from being taken offline. Recommended workflow:

1) Baseline: DMARC p=none, 48–72 hours of reports

Collect RUA data, catalog sender IPs and services. Flag unclear sources and prioritize investigation by volume and criticality.

2) Clean up SPF

Reduce includes, create sending subdomains if necessary, and test after every change with public resolvers.

3) Enable DKIM everywhere

Ensure that all production paths run through the signing hop. Send test mails from every application and inspect the headers at the recipient.

4) Quarantine with pct control

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=50"

Increase policy strictness gradually and monitor canary mailboxes (Gmail, M365) as well as the support backlog.

5) Reject

Set p=reject only after all legitimate senders are stably aligned and you can respond to support tickets promptly. Plan clear SLAs for analysis & rollback.

Practical test and diagnostic commands

For sending test emails, swaks (Swiss Army Knife SMTP) is useful; with it you can check whether signatures are being generated:

# Beispiel: Testmail via lokalen Relay
swaks --to test@example.org --from zammad@example.tld --server localhost:25 --header "Subject: DKIM Test"

# DKIM/Header prüfen (auf Empfänger oder lokalen Mailbox-Store)
grep -i "DKIM-Signature|Authentication-Results" /var/mail/testuser | sed -n '1,80p'

DNS checks:

dig @1.1.1.1 TXT s2026q3._domainkey.example.tld
dig @8.8.8.8 TXT _dmarc.example.tld +noall +answer
# Über TCP testen, falls große TXT-Records Probleme machen
dig @1.1.1.1 TXT s2026q3._domainkey.example.tld +noall +answer +tcp

Check RUA report (unpack ZIP and format):

unzip -p report-12345.zip | xmllint --format - | sed -n '1,200p'

Zammad-specific operational rules

Zammad instances often send system-critical mail (ticket notifications, SLA alerts). Check the following points:

• Configure Zammad so that outbound mail flows through the central Postfix relay (Admin UI or systemsendmail). This ensures central DKIM signing and DMARC alignment.
• Check From: vs Envelope-From: Zammad can, by default, use different sender addresses; configure consistent sender domains or use a mailer subdomain.
• Perform test ticket sends and inspect the headers at the recipient fully (Received, DKIM-Signature, Authentication-Results).
• Automate spot checks: a monitoring job that regularly sends test emails and checks signature/Authentication-Results reduces operational risk.

Problem cases and troubleshooting

DMARC fail despite SPF/DKIM pass

This is often due to missing alignment. Check whether DKIM d= matches the From domain or whether the Return-Path belongs to the same organizational domain.

DKIM passing with some providers, failing with others

DNS delivery is often the cause: split-horizon, TXT truncation, or caching. Test with various public resolvers and over TCP to find fragmentation issues.

Milter failure

sudo systemctl status opendkim --no-pager
sudo ss -xlpn | grep opendkim
journalctl -u opendkim -n 200 --no-pager
journalctl -u postfix -n 200 --no-pager

During the rollout phase, Milter errors should not prevent delivery (milter_default_action=accept), but in the operational phase they should be monitored and resolved.

Forwarding, mailing lists and ARC

SPF often fails with simple forwarding because the forwarder is not listed in your SPF. Two practical options:

• Use DKIM — signatures usually survive forwarding better.
• Support Authenticated Received Chain (ARC) — ARC is a header mechanism that documents authenticity across mailing lists/forwarders and helps recipients accept legitimate messages despite broken SPF/DKIM results.

ARC is especially useful in environments with many mailing lists or internal forwards.

Security, key management and operational hygiene

Private DKIM‑Schlüssel sind Betriebsgeheimnisse: protect files, restrict file permissions and secure backups. Document rotation dates and test key changes in a staging zone. Implement change control for DNS changes (Git + CI for zone files or a ticket‑driven DNS deployment).

Concrete rollback plan (concise and actionable)

1. If critical delivery failures occur, quickly set DMARC to p=none:

# Beispiel: neuer DMARC-Record
_dmarc.example.tld. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=100"

# DNS-Änderung prüfen
dig @1.1.1.1 TXT _dmarc.example.tld +noall +answer
# Postfix/OpenDKIM Status prüfen
sudo systemctl status postfix opendkim --no-pager

Then start the root‑cause analysis: which senders failed, which services were affected, and document learnings in your change log.

Long-term maintenance and monitoring

Schedule regular reviews: analyze RUA‑reports (e.g., weekly), DKIM key rotation every six months, SPF inventory quarterly. Automate alerts for sudden spikes in volume or error rates in DMARC reports.

Conclusion

Introducing DMARC, DKIM and SPF is an operational project: inventory, DNS governance, a centralized signing strategy, a testing workflow and clear rollback paths are decisive. Start with DMARC reporting, clean up SPF, enable DKIM on the relay, and harden DMARC stepwise. Documentation, monitoring and regular maintenance make the measure sustainable — especially for applications like Zammad that send critical notifications.

DMARC, DKIM & SPF: operations, monitoring and automation

Once the basic technology is in place, ongoing operations determine success. Shift the perspective from a one‑off project to a continuous service: DNS governance, milter high availability, RUA pipeline, key lifecycle and rollback automation are operational workstreams you should plan early.

DNS‑providers and change operations

• Watch for provider limits on API calls and rate limiting for zone uploads; otherwise automated deploys can fail or lead to TTL inconsistencies.
• Use short TTLs before major changes (e.g., 300s) and increase them again after stability.
• Test TXT delivery via multiple public resolvers and over TCP to detect truncation.

High availability and key management

Operate the DKIM‑signer as a highly available component: decouple Postfix hops via TCP/inet milter or a central proxy. Private keys belong in a secure key store or HSM; create a documented emergency rotation playbook (publish a new selector, switch signatures, remove the old key only after a test window).

RUA pipeline & SIEM integration

RUA‑reports are raw data — build an automated pipeline: collector (email or API) → parser/normalizer → time series database & SIEM. Rules that should alert immediately: sudden increase in DMARC fails, new sending IPs with high volume, or recurring failures for critical subdomains. Pay attention to data protection: IPs in reports are personal data and require appropriate retention policies.

Operational Safety Nets

• Canary‑recipients: a small set of different providers (Gmail, M365) as an early warning system.
• Milter circuit breaker: automatic alerting on repeated milter timeouts; as long as milter_default_action=accept is set, a safe fallback phase helps.
• Infrastructure as Code: DNS changes via GitOps (pull request, review, CI) minimize human error and enable fast revert.

These operational building blocks make the project resilient: they reduce support tickets, prevent operational incidents for bespoke enterprise software such as Zammad, and create a clearly auditable change history.

For this topic, Postfix DKIM and SPF records are also important. The article contextualizes these aspects and shows what matters in day-to-day operations.