Email authentication is one of those areas where people think they understand it—until something breaks. Then suddenly, messages are getting flagged, spoofed, or silently dropped, and nobody can quite explain why.
Let’s be clear: modern email delivery is not just about sending mail. It’s about proving identity at multiple layers, to multiple systems, in a way that aligns consistently. If any piece is misaligned, your message becomes suspect.
This post walks through the four components that actually matter in practice: SPF, DKIM, DMARC, and HELO (EHLO)—and how they interact.
SPF (Sender Policy Framework)
What it does:
SPF answers a simple question:
Is this server allowed to send email for this domain?
It works by publishing a DNS TXT record listing authorized sending IPs or systems.
Example:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -allWhat happens during a check:
- Receiving server extracts the domain from the MAIL FROM (envelope sender)
- Looks up the SPF record for that domain
- Compares the sending IP against authorized sources
Key reality:
SPF is fragile.
- It breaks on forwarding (because the forwarder’s IP isn’t in your SPF)
- It does not validate message integrity
- It does not validate the visible “From” address
Verdict: Necessary, but insufficient on its own.
DKIM (DomainKeys Identified Mail)
What it does:
DKIM cryptographically signs the message.
This message hasn’t been altered, and it was authorized by this domain.
How it works:
- Sending server signs the email using a private key
- Public key is published in DNS
- Receiving server validates the signature
Key components:
d=→ domain that signed the messages=→ selector (used to locate the DNS key)
Example DNS record:
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."What DKIM solves:
- Message tampering
- Domain-level authenticity
What it does NOT solve:
- It doesn’t guarantee the From address matches the signing domain
- You can sign mail for one domain while claiming to be another
Verdict: Strong, but only meaningful when aligned (see DMARC).
DMARC (Domain-based Message Authentication, Reporting & Conformance)
What it does:
DMARC ties everything together—and enforces policy.
Do SPF and/or DKIM pass, and do they align with the visible From address?
Example record:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; aspf=s; adkim=sCore concepts:
1. Alignment (this is where most people fail)
- SPF must align with the From domain
- DKIM must align with the From domain
Alignment can be:
- Relaxed (
r) → subdomains allowed - Strict (
s) → exact match required
2. Policy
none→ monitor onlyquarantine→ spam/junkreject→ outright block
3. Reporting
- Aggregate reports (RUA)
- Forensic reports (RUF, less commonly used)
Why DMARC matters:
- Prevents spoofing
- Enables enforcement
- Provides visibility
Hard truth:
If you don’t have DMARC set to at least quarantine, you are not actually protecting your domain—you’re just observing abuse.
HELO / EHLO (The Overlooked Signal)
What it is:
HELO (or EHLO) is part of the SMTP handshake:
EHLO mail.example.com
It tells the receiving server:
This is who I claim to be at the connection level.
Why it matters more than people admit:
Receiving systems evaluate:
- HELO hostname
- Sending IP
- Reverse DNS (PTR record)
- Forward-confirmed reverse DNS (FCrDNS)
Common problems:
- HELO =
localhost→ immediate suspicion - HELO domain doesn’t match PTR → degraded trust
- No PTR record → often rejected outright
What good looks like:
- HELO hostname matches PTR
- PTR resolves back to the same IP
- Domain is valid and consistent with sending identity
Key insight:
HELO is not part of SPF/DKIM/DMARC—but it absolutely influences reputation and filtering decisions.
Ignore it, and you will chase “random” deliverability issues forever.
How They Work Together (Real-World Flow)
Here’s what actually happens when you send an email:
- Connection established
- HELO/EHLO evaluated
- IP reputation checked
- PTR validation
- SPF check
- Is this IP allowed to send for the envelope domain?
- DKIM check
- Is the message signed?
- Is the signature valid?
- DMARC evaluation
- Do SPF/DKIM pass?
- Do they align with the From address?
- Apply policy
- Content + reputation filtering
- Spam heuristics
- Historical behavior
Common Failure Patterns (What Actually Breaks)
Let’s be blunt—these are the mistakes that cause real issues:
1. SPF passes, but DMARC fails
- Because SPF domain ≠ From domain
- Result: spoof still possible
2. DKIM passes, but wrong domain
- Signed by a third-party vendor domain
- No alignment → DMARC fail
3. Forwarding breaks SPF
- No DKIM → message fails authentication entirely
4. Misaligned HELO / PTR
- Causes silent filtering or throttling
- Often misdiagnosed as “random delivery issues”
5. Overly complex SPF
- 10 DNS lookups → SPF permerror
- Entire mechanism fails
Practical Recommendations
If you want email to work reliably—not just “most of the time”—do this:
Minimum viable setup
- SPF: include all senders, end with
-all - DKIM: enable for every sending platform
- DMARC: start with
p=none, move toquarantine, thenreject
Alignment discipline
- Ensure:
- Envelope sender domain aligns
- DKIM signing domain aligns
- Avoid mixing domains casually
HELO hygiene
- Set a proper hostname (e.g.,
mail.yourdomain.com) - Ensure:
- PTR record exists
- Forward + reverse match
Vendor management
- Every SaaS sender (M365, Google, SendGrid, etc.) must:
- Be in SPF
- Have DKIM enabled
- Align with your domain
Final Thought
SPF, DKIM, and DMARC are not independent features—they are a system of trust. HELO sits just outside that system but still influences the outcome.
Most organizations don’t fail because they lack these technologies. They fail because they configure them in isolation.
If you take one thing away from this:
Alignment matters more than passing checks.
You can pass SPF and DKIM and still fail DMARC—and that’s exactly how spoofing succeeds in poorly configured environments.
If you want, I can take a real header from your environment and walk through exactly why it’s passing or failing.