Email Deliverability From Your Own Server: SPF, DKIM, DMARC and Reality

We brought transactional email back in-house for our internal staging notification engines and isolated client infrastructure after a major third-party relay silently dropped 40,000 password resets during an unannounced API deprecation. The common industry consensus claims self-hosting outbound mail is dead, killed off by Google and Microsoft's spam filters. That claim is lazy.

Outbound mail delivery from your own server is alive and reliable, provided you stop treating DNS records as copy-paste documentation snippets and start treating IP reputation and authentication alignment as stateful software systems. If you fail to configure a single milter socket or forget IPv6 PTR alignment, your messages will hit dev/null before touching an inbox.

Here is how we configure, validate, and maintain high-deliverability outbound mail servers on bare Debian instances using Postfix and OpenDKIM, alongside the exact DNS structures required to pass modern inbox verification filters.

Ground Rules: Network Layer and Identity

Before writing a line of Postfix configuration, your hosting provider and network layer must meet non-negotiable requirements. If your provider blocks outbound port 25 or issues dirty IP addresses, no amount of cryptographic signing will save your deliverability.

1. Static IPv4 and IPv6: You need clean, dedicated IP addresses. Check the IP block on Spamhaus ZEN, UCEPROTECT, and Barracuda Central before spinning up a server. 2. Matching Reverse DNS (PTR): The hostname returned by a reverse lookup on your IP must match the Forward A/AAAA record pointing to that IP, and it must match the domain declared in your MTA's myhostname configuration. 3. IPv6 Parity: Receivers like Gmail perform identical validation over IPv6. If your Postfix host attempts outbound connections via IPv6 without a valid PTR and matching SPF record for that IPv6 block, Gmail will reject the connection immediately with a 550 5.7.1 response.

If you cannot set an explicit PTR record with your hosting provider, stop here. You cannot deliver mail from that server.

We force Postfix to bind to specific interfaces and maintain identical naming across IPv4 and IPv6 protocols in /etc/postfix/main.cf:

class="text-code-comment"># /etc/postfix/main.cf - Core Identity & Network
myhostname = mailout.pajlabs.net
mydomain = pajlabs.net
myorigin = /etc/mailname
inet_interfaces = all
inet_protocols = ipv4, ipv6
class="text-code-comment">
# Disable local delivery; this node is purely outbound transactional
mydestination = localhost
local_transport = error:local delivery disabled
class="text-code-comment">
# TLS parameters
smtp_tls_security_level = verify
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Configuring OpenDKIM and Postfix Integration

DomainKeys Identified Mail (DKIM) provides cryptographic proof that an email was authorized by the domain owner and that the header and body were not tampered with in transit.

We use opendkim running as a systemd service bound to a Unix domain socket, allowing Postfix to communicate with it without network overhead.

First, set up /etc/opendkim.conf with relaxed canonicalization. Strict canonicalization breaks headers if downstream relays rewrap long lines or alter whitespace, invalidating the signature.

class="text-code-comment"># /etc/opendkim.conf
Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes

Mode                    sv
SubDomains              no
Canonicalization        relaxed/relaxed
class="text-code-comment">
# Match socket in Postfix chroot
Socket                  local:/var/spool/postfix/opendkim/opendkim.sock
UMask                   007

UserID                  opendkim:postfix

KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts

Generate the key pair for your selector. We rotate selectors using a year-month format (e.g., s202410):

mkdir -p /etc/opendkim/keys/pajlabs.net
cd /etc/opendkim/keys/pajlabs.net

opendkim-genkey -b 2048 -d pajlabs.net -s s202410
chown -R opendkim:opendkim /etc/opendkim/keys/pajlabs.net
chmod 600 /etc/opendkim/keys/pajlabs.net/s202410.private
class="text-code-comment">
# Define the key in KeyTable
echo class="text-code-string">"s202410._domainkey.pajlabs.net pajlabs.net:s202410:/etc/opendkim/keys/pajlabs.net/s202410.private" >> /etc/opendkim/KeyTable
class="text-code-comment">
# Map domain signatures in SigningTable
echo class="text-code-string">"*@pajlabs.net s202410._domainkey.pajlabs.net" >> /etc/opendkim/SigningTable
class="text-code-comment">
# Authorize local sources in TrustedHosts
echo class="text-code-string">"127.0.0.1" >> /etc/opendkim/TrustedHosts
echo class="text-code-string">"localhost" >> /etc/opendkim/TrustedHosts
echo class="text-code-string">"192.0.2.10" >> /etc/opendkim/TrustedHosts

Ensure the runtime socket directory exists with proper permissions for Postfix access:

mkdir -p /var/spool/postfix/opendkim
chown opendkim:postfix /var/spool/postfix/opendkim
chmod 750 /var/spool/postfix/opendkim
usermod -a -G opendkim postfix

Now attach OpenDKIM to Postfix as a Milter by adding the following parameters to /etc/postfix/main.cf:

class="text-code-comment"># Milter configuration
smtpd_milters = unix:opendkim/opendkim.sock
non_smtpd_milters = unix:opendkim/opendkim.sock
milter_default_action = accept
milter_protocol = 6

Restart both services and verify the socket file is accessible:

systemctl restart opendkim
systemctl restart postfix
ls -la /var/spool/postfix/opendkim/opendkim.sock

Building Proper DNS Records: SPF, DKIM, DMARC

Mail authentication relies on three interdependent DNS TXT records. Missing or misconfigured parameters in any of these records will trigger spam filters or result in direct dropping of your packets.

1. Sender Policy Framework (SPF)

SPF explicitly defines which IP addresses can send mail claiming your domain in the Return-Path (envelope sender).

Do not use +all under any circumstances. Do not use ?all in production; it signals lack of control over your infrastructure. Use -all (hardfail) for production systems once verified.

Rule of thumb: Limit DNS lookups. The SPF specification enforces a hard limit of 10 DNS lookups per check. Exceeding 10 causes SPF validation to fail with a PermError. Use raw IP definitions (ip4: and ip6:) rather than chained include: statements where possible.

2. DKIM Record

The opendkim-genkey utility produces a file named s202410.txt. The contents contain the public key portion that must be published in your public DNS zone file under the selector name.

3. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC specifies what receivers should do with messages that fail SPF or DKIM checks, and configures feedback paths via XML reports.

DMARC checks two things: 1. Did SPF or DKIM pass? 2. Alignment: Does the domain in the visible From: header match the domain validated by SPF (Return-Path) or DKIM (d= tag)?

A message can pass SPF and DKIM independently but still fail DMARC if the domains do not align.

Here is a complete, production-grade BIND-style zone setup for pajlabs.net:

; Forward identity records
mailout.pajlabs.net.    IN  A      192.0.2.10
mailout.pajlabs.net.    IN  AAAA   2001:db8::10

; SPF Record: Explicitly grant sending rights to the IPv4 and IPv6 block
pajlabs.net.            IN  TXT    class="text-code-string">"v=spf1 ip4:192.0.2.10 ip6:2001:db8::10 -all"

; DKIM Record (Public key generated by opendkim-genkey)
s202410._domainkey.pajlabs.net. IN TXT class="text-code-string">"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv...IDAQAB"

; DMARC Record: Quarantines failures, mandates strict DKIM/SPF alignment
_dmarc.pajlabs.net.     IN  TXT    class="text-code-string">"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@pajlabs.net; ruf=mailto:dmarc-telemetry@pajlabs.net; pct=100; adkim=s; aspf=s"

In the DMARC record:

• p=quarantine: Moves non-compliant emails to the recipient's spam folder. Once trusted, upgrade this to p=reject.
• adkim=s and aspf=s: Enforces strict alignment. The visible From: domain must match the DKIM signature domain and SPF envelope domain exactly, without relying on subdomains.

Diagnostics and Reality: Handling Edge Cases

Even with clean configurations, remote receivers apply arbitrary filters based on heuristics, domain age, and internal blacklists.

Below is a diagnostic reference of failure modes we regularly monitor in /var/log/mail.log and their solutions:

| Error / Log Signature | Failure Cause | Root Cause | Resolution | | :--- | :--- | :--- | :--- | | 550 5.7.1 ... Our system has detected that this message does not comply with mail-hosts standards | Gmail IPv6 Policy Failure | Missing PTR on IPv6 interface, or IPv6 missing from SPF record. | Add IPv6 PTR with host provider; append ip6:... to SPF TXT record. | | dkim=neutral (bad format) or dkim=fail (bad signature) | Header Mismatch | Mail relay or local application altered line endings or headers post-signing. | Set Canonicalization relaxed/relaxed in OpenDKIM; sign fewer headers using SignHeaders. | | DMARC policy evaluation failed: unaligned domain | DMARC Alignment Failure | From: domain (app.example.com) does not match SPF/DKIM domain (example.com). | Align the Return-Path and d= DKIM tag with the exact domain in the visible From: header. | | 451 4.7.500 Server busy. Try again later. | Microsoft Greylisting / SNDS Block | Cold IP sending volume spike or unknown IP subnet reputation at Outlook/Office365. | Register IP range with Microsoft Smart Network Data Services (SNDS); warm IP gradually. | | 554 5.7.1 Service unavailable; Client host [X.X.X.X] blocked using Spamhaus | Dirty IP Assignment | Provider reassigned an IP address previously abused by another customer. | Request delisting on Spamhaus after securing system, or request clean IP allocation from host. |

To inspect signature generation on outgoing mail locally before sending to external receivers, use swaks (Swiss Army Knife for SMTP):

swaks --to check-auth@verifier.port25.com \
      --from no-reply@pajlabs.net \
      --server 127.0.0.1:25 \
      --header class="text-code-string">"Subject: Infrastructure Test" \
      --body class="text-code-string">"Testing DKIM and SPF alignment."

Check /var/log/mail.log immediately after running swaks to ensure OpenDKIM attached the signature header cleanly:

tail -n 25 /var/log/mail.log | grep opendkim

Output should show successful signature injection:

postfix/opendkim[18402]: 4WvLz20XzZz190B: DKIM-Signature header added (s202410._domainkey.pajlabs.net)

IP Warming and Feedback Loops

When bringing a new IP address online, you cannot immediately blast 50,000 marketing messages or notifications. Mail servers track global IP reputation. Unrecognized IPs sending sudden bursts of traffic are throttled or sent straight to spam folders regardless of valid SPF/DKIM/DMARC authentication.

We follow a rigid warm-up schedule for any newly provisioned outbound IP:

1. Days 1–3: Max 100 messages/day. Send exclusively high-engagement transactional mail (e.g., password resets, purchase confirmations). 2. Days 4–7: Max 500 messages/day. 3. Week 2: Max 2,500 messages/day. 4. Week 3: Max 10,000 messages/day. 5. Week 4: Full capacity.

Monitor progress using external reputation webmasters:

• Google Postmaster Tools: Register your sending domains to monitor DKIM success rates, SPF success rates, domain reputation, and IP reputation.
• Microsoft SNDS (Smart Network Data Services): Tracks spam complaint rates and block status across Hotmail, Outlook, and Office 365 networks.

If your spam complaint rate exceeds 0.1% on Google Postmaster Tools, Google will temporarily downgrade your IP reputation score to "Low" or "Bad", routing your transactional email to the spam folder for 3 to 7 days until the complaint volume drops.

The Reality

Self-hosting outbound email infrastructure is not a set-it-and-forget-it deployment task. It demands continuous visibility.

If you run high-volume transactional workloads, you must continuously process bounce logs, monitor DMARC aggregate XML reports via automated parser tools, keep PTR records aligned across dual-stack IP pools, and maintain zero tolerance for unaligned From: headers generated by internal application code.

If your core business relies on sending low-volume, critical application alerts and you have experienced engineers who understand MTAs and network configurations, self-hosting outbound mail on your own IP gives you complete operational control, lower latency, and zero dependency on third-party SaaS vendors. If you lack the bandwidth to monitor log streams and aggregate DMARC feedback, pay a dedicated SMTP relay provider to handle the overhead for you.