Email Authentication Demystified: SPF, DKIM, and DMARC #

Email authentication is one of those areas every developer has to deal with, but few actually understand deeply. You set it up once during deployment, it seems to work, and you move on. Then one day a user reports your emails are landing in spam, or worse — someone is spoofing your domain in a phishing campaign targeting your own users.

The pitfalls are subtle. The interactions between protocols are non-obvious. And the consequences of getting it wrong at scale are real.

If you're running a web app that sends transactional emails — think membership platforms, SaaS tools, anything with a login — you need to understand email authentication properly. Not just because it improves deliverability, but because without it, anyone can send emails pretending to be you.

This post covers SPF, DKIM, and DMARC: what they do, how they interact, and why all three together are non-negotiable.

The Problem: Email Has No Built-In Identity #

SMTP — the protocol that powers email — was designed in the 1980s with zero authentication. Any server can claim to send mail from any domain. This is why phishing exists. Email authentication protocols were bolted on later to fix this.

There are three layers: SPF, DKIM, and DMARC. Each solves a different part of the problem.

SPF: Who Is Allowed to Send? #

Sender Policy Framework (SPF) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain.

v=spf1 include:_spf-eu.ionos.com ~all

When a receiving mail server gets an email, it extracts the Return-Path domain (not the From address — more on that below) and looks up its SPF record. If the sending IP matches the authorized list: SPF passes.

The Return-Path Shift #

This is where most guides get it wrong. SPF does not check the From address the recipient sees. It checks the Return-Path — the envelope sender used during the SMTP transaction, primarily for bounce handling.

Years ago, SPF was checked against the From domain. That changed. Today, receiving servers check the Return-Path domain. This has a major practical implication:

If your ESP (e.g. Postmark) sets its own Return-Path domain, you don't need to include them in your SPF record.

Postmark, for example, uses pm-bounces.yourdomain.com as the Return-Path via a CNAME record. The CNAME points to pm.mtasv.net, which carries Postmark's own SPF TXT record (v=spf1 include:spf.mtasv.net -all). The SPF check resolves there — completely independent of your domain's SPF record.

Two Senders, Zero Collision #

Here's how running IONOS and Postmark in parallel works without conflict:

Two different hostnames, two separate SPF lookups. They never touch each other.

Critical DNS rule: A CNAME and a TXT record cannot coexist on the same hostname (RFC 1912). That's fine here because the CNAME lives on the subdomain pm-bounces.yourdomain.com, not on the root yourdomain.com where your SPF TXT record lives.

SPF Weakness #

SPF alone is easy to abuse. An attacker can:

• Set From: info@yourdomain.com (what the user sees)
• Set Return-Path: attacker@hisowndomain.com (his own domain with valid SPF)

SPF passes. The user sees your domain. This is why SPF alone is not enough.

DKIM: Was the Message Tampered With? #

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing emails. The sending server signs the message with a private key. The public key is published in DNS as a TXT record under a _domainkey subdomain.

s1-ionos._domainkey.yourdomain.com  TXT  "k=rsa; p=MIG..."

When a receiving server gets the email, it fetches the public key from DNS and verifies the signature in the email header. If valid: the message was not altered in transit and genuinely originated from a server with access to the private key.

DKIM gives you two things:

1. Integrity — the email wasn't modified between sender and recipient
2. Origin proof — only someone with the private key could have signed it

DKIM Alignment #

For DMARC purposes, DKIM alignment means the domain in the DKIM signature (d= tag) must match the From domain.

• From: info@yourdomain.com + DKIM d=yourdomain.com → aligned ✓
• From: info@yourdomain.com + DKIM d=attacker.com → not aligned ✗

An attacker can sign with their own key — but they can't fake your domain in the d= tag without your private key.

DMARC: The Enforcer #

Domain-based Message Authentication, Reporting & Conformance (DMARC) ties everything together. It answers the question SPF and DKIM cannot answer alone:

Does the authenticated domain align with the From domain the user actually sees?

A DMARC record is a TXT record on _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

How DMARC Evaluates a Message #

For a message to pass DMARC, it must pass at least one of:

• SPF authentication + SPF alignment (Return-Path domain matches From domain)
• DKIM authentication + DKIM alignment (DKIM d= domain matches From domain)

Both checks require alignment — not just a technical pass.

DMARC Policies #

Closing the SPF Loophole #

Remember the SPF spoofing scenario? With DMARC p=reject:

• Attacker sends From: info@yourdomain.com, Return-Path from his own domain
• SPF passes (his domain) — but SPF alignment fails (his domain ≠ yourdomain.com)
• DKIM not signed with your key — DKIM alignment fails
• DMARC: both checks failed → message rejected

This is why DMARC is essential. Without it, SPF and DKIM are locks without a door frame.

The rua Reporting Tag #

The rua parameter tells receiving servers where to send aggregate reports. These XML reports show you which IPs are sending mail using your domain — legitimate or not. It's your early warning system for spoofing campaigns.

For a human-readable version of these reports, Postmark offers a free DMARC report digest at dmarc.postmarkapp.com. No paid service required.

Deployment Strategy #

Don't go straight to p=reject. You risk blocking your own legitimate mail if something is misconfigured.

Step 1: Deploy p=none across all your domains and set up reporting.

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Step 2: Wait 1–2 weeks. Check reports. Verify all your sending sources (IONOS, Postmark, transactional mailers) appear as aligned.

Step 3: Move to p=reject.

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

Summary #

All three are needed. SPF and DKIM without DMARC leave your domain open to spoofing. DMARC without SPF and DKIM has nothing to enforce.

For any platform sending email at scale — especially one with a login form and real users — this is baseline hygiene, not optional hardening.