How SPF, DKIM, and DMARC records demolish "forged header" allegations in email anti-spam cases
Before evaluating whether email headers were "forged" or "spoofed," courts and attorneys must understand how modern email delivery infrastructure actually operates. This section provides a non-technical explanation of the email ecosystem that forms the foundation for every authentication defense.
Modern commercial email is not sent directly from a sender's personal computer to a recipient's inbox. Instead, it flows through a multi-step infrastructure that involves specialized email service providers (ESPs). Here is the actual delivery path:
This is exactly how every major business sends email. The ESP acts as an authorized sending agent — just like a courier service shows their own tracking and routing information rather than the original sender's home address.
Every email contains metadata called "headers" that document the email's journey from sender to recipient. Understanding these headers is critical because plaintiffs in anti-spam cases often misinterpret standard header fields as evidence of "forgery."
marketing@example.com
bounces.sendgrid.net). This is not forgery — it is standard bounce-processing infrastructure.
<abc123@mail.sendgrid.net>). This is standard and expected.
When a sender uses an ESP to send email, the ESP's servers physically transmit the message. This means headers like Received:, Return-Path:, and Message-ID: will naturally contain the ESP's domain names and IP addresses.
Seeing "sendgrid.net" or "mcsv.net" in routing headers does not mean the email was "spoofed." It means the email was sent through a legitimate, authenticated email platform. This is how every business email works — from a 10-person startup to a Fortune 500 company.
The analogy is straightforward: when you send a package via FedEx, the tracking label shows FedEx's routing information, not your home address. No one would claim the package was "forged" because the courier's name appears on the shipping label. Email works the same way.
Under California B&P § 17529.5, the statute targets emails with headers that are "falsified, misrepresented, or forged." When email passes SPF, DKIM, and DMARC authentication, the headers are by definition not falsified, misrepresented, or forged — they are verified as authentic by the domain owner's own published DNS records and cryptographic signatures.
The three authentication protocols described in the following tabs provide the technical framework for proving that email headers are genuine, authorized, and unaltered.
SPF — The first layer of email authentication. SPF is a DNS-based protocol that explicitly declares which mail servers are authorized to send email for a domain.
SPF is a DNS TXT record published by the domain owner that lists every mail server and IP address authorized to send email on behalf of that domain. When a receiving server gets an email claiming to be from example.com, it looks up the SPF record for example.com and checks whether the sending server's IP address is listed.
Authentication-Results header.An SPF pass result means one thing unequivocally: the domain owner explicitly authorized the ESP to send email on their behalf. The domain owner went into their DNS management panel, typed out the ESP's include directive, and published it for the entire internet to verify.
Translation: Google's mail server checked the SPF record and confirmed that the Mailchimp server (198.2.xxx.xxx) is an authorized sender for this domain. The email is legitimate.
Translation: The sending server was NOT authorized. This is what genuine spoofing looks like — and it fails SPF verification.
SPF pass = the domain owner explicitly authorized the sending infrastructure. This is the opposite of spoofing. The domain owner published a public DNS record telling every mail server in the world: "These ESPs are authorized to send email for my domain." A plaintiff cannot credibly argue that headers are "forged" when the domain owner's own DNS records prove the sending infrastructure was authorized.
DKIM — The second and most powerful layer of email authentication. DKIM provides cryptographic proof that an email's headers and body have not been altered and that the email was sent by an authorized entity.
DKIM is a cryptographic signature system. The ESP signs every outgoing email with a private key, and the corresponding public key is published in the sender's DNS records. Any receiving server can verify the signature against the public key to confirm authenticity.
This is the same class of cryptography used in HTTPS certificates, digital signatures, and secure banking — it is mathematically unforgeable.
DKIM-Signature header on the email.The From:, Subject:, and other signed headers have not been altered since the ESP sent the email. They are exactly what the sender intended.
The email body (content) has not been changed in transit. The body hash (bh=) proves the content is identical to what was sent.
The signature was created with a private key, and the matching public key is in the sender's DNS. Only an authorized sender has access to the private key.
DKIM is mathematically unforgeable. The cryptographic signature cannot be generated without the private key, which is held exclusively by the ESP. If DKIM passes verification, it proves beyond technical doubt that:
Translation: The cryptographic signature on this email is valid. The headers and body are authentic, unmodified, and authorized by the domain owner. This is mathematical proof — not an opinion.
"Forged" headers would fail DKIM verification. If someone actually spoofed or altered the email headers, the cryptographic hash would not match the public key, and DKIM would report dkim=fail. A DKIM pass is definitive proof that the headers are genuine.
DKIM pass = cryptographic proof that the email headers are genuine, unaltered, and authorized. This is the strongest technical evidence available against "forged header" allegations. Unlike witness testimony or circumstantial evidence, DKIM verification is a mathematical certainty — the signature either matches or it does not. There is no room for interpretation.
DMARC — The third layer that ties SPF and DKIM together into a unified authentication policy. DMARC ensures that both SPF and DKIM align with the visible From: domain and tells receiving servers what to do with unauthenticated email.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS-published policy that:
From: header_dmarc.example.com defines the authentication policy.From: header domain.none, quarantine, or reject), the receiving server handles unauthenticated email accordingly.DMARC's unique contribution is alignment — it verifies that the domain authenticated by SPF or DKIM matches the domain in the visible From: header. This prevents a scenario where SPF passes for one domain but the From: header shows a completely different domain.
| Check | What It Verifies | Alignment Requirement |
|---|---|---|
| SPF Alignment | Return-Path domain matches From: domain | Relaxed: organizational domain match (e.g., subdomain OK) Strict: exact domain match |
| DKIM Alignment | DKIM signing domain (d=) matches From: domain | Relaxed: organizational domain match Strict: exact domain match |
DMARC passes if either SPF or DKIM passes and aligns with the From: domain. Most properly configured ESP setups achieve alignment through DKIM (custom DKIM signing with the sender's domain).
Translation: This email passed all three authentication checks. The domain owner configured authentication (DMARC), authorized the sending server (SPF), and cryptographically signed the email (DKIM). The headers are genuine, verified, and aligned with the From: domain.
DMARC aggregate reports provide a powerful source of evidence for litigation. These XML reports, sent by major mailbox providers (Google, Microsoft, Yahoo), document:
Preservation note: DMARC reports are typically sent daily and may only be retained for a limited period. Issue a litigation hold on these reports early to preserve this evidence of ongoing authentication compliance.
A passing DMARC result is the most comprehensive authentication evidence available. It proves: (1) the domain owner configured an authentication policy, (2) the ESP is authorized to send on behalf of the domain, (3) the authentication checks align with the visible From: address, and (4) the headers are genuine and verified by the receiving mail server. This eliminates any credible claim of forged or misrepresented headers.
This step-by-step guide covers how to collect, preserve, and present email authentication evidence to defend against "forged header" allegations. Each step builds on the previous one to create a comprehensive technical defense.
Log in to your ESP account (Mailchimp, SendGrid, Klaviyo, Postmark, Hive.co, etc.) and export the specific email campaign at issue. Critical items to capture:
Capture the current SPF, DKIM, and DMARC DNS records. These records prove the domain owner's authentication configuration. Take both a screenshot and save the command output.
Important: DNS records can be changed at any time. Capture them as early as possible and consider using a notarized screenshot or a third-party DNS monitoring service (e.g., SecurityTrails, DNSHistory) for timestamped records.
Obtain the raw email headers from the received email and analyze them using professional tools. The most authoritative tool is Google Admin Toolbox Message Header Analyzer.
Save both the raw header text and the parsed analysis output as evidence.
The single most important piece of evidence is the Authentication-Results: header in the received email. This header is added by the receiving mail server (not the sender) and shows the results of SPF, DKIM, and DMARC verification.
The key results to document: spf=pass, dkim=pass, dmarc=pass. These three results, recorded by the receiving server, conclusively demonstrate authenticated, authorized email delivery.
Contact your ESP's legal or compliance department and request formal documentation confirming:
Many ESPs will provide a compliance letter or can have their records custodian provide a declaration suitable for litigation.
Issue a litigation hold to your ESP to preserve all relevant data. Critical items to preserve:
Act quickly. ESPs have different data retention policies. Some retain detailed sending logs for only 30-90 days. Issue the preservation request as soon as litigation is anticipated.
For cases where the technical evidence is complex or the opposing party contests the meaning of authentication results, consider retaining an email infrastructure expert who can testify about:
An expert in email deliverability, email security, or DNS infrastructure can provide authoritative testimony that standard ESP operations are not spoofing.
| Evidence Item | Source | What It Proves |
|---|---|---|
| SPF record snapshot | DNS query output | Domain owner authorized the ESP |
| DKIM public key record | DNS query output | Domain owner enabled cryptographic signing |
| DMARC policy record | DNS query output | Domain owner configured authentication policy |
| Authentication-Results header | Received email headers | Receiving server verified SPF/DKIM/DMARC pass |
| ESP campaign export | ESP account dashboard | Campaign configuration and From address setup |
| ESP compliance letter | ESP legal/compliance team | Account ownership and authentication configuration |
| DMARC aggregate reports | Email to rua= address | Ongoing authentication compliance over time |
Plaintiffs in email anti-spam cases frequently mischaracterize standard ESP infrastructure as "spoofing" or "forged headers." Below are the most common arguments and the technical rebuttals that defeat them.
This is exactly how ESP routing works. When a sender uses Mailchimp, SendGrid, Klaviyo, Postmark, or any other ESP, the email is physically transmitted from the ESP's servers. Certain technical headers (like Return-Path and Received) will show the ESP's domain because the ESP is the authorized delivery agent.
The visible From: header still shows the sender's identity. The technical routing headers show the delivery infrastructure — just as a FedEx tracking label shows FedEx, not the person who shipped the package.
include:sendgrid.net) that tells every receiving server in the world: "SendGrid is authorized to send email for my domain." This is authorization, not forgery.
Because the ESP's servers handle email delivery. That is their entire purpose. The sender contracts with the ESP specifically to send email on their behalf. The Received: chain showing the ESP's servers is proof that the email traveled through legitimate, authorized infrastructure.
DKIM proves the email is authentic. The cryptographic signature was generated by the ESP (using the domain owner's authorized key) and verified by the receiving server. If the headers were "forged," the DKIM verification would fail.
The Return-Path (also known as the envelope sender or bounce address) is always set by the ESP to handle bounce processing. This is an industry-standard practice documented in RFC 5321 and used by every major email platform worldwide.
The Return-Path serves a specific technical function: it tells receiving servers where to send delivery failure notifications (bounces). The ESP sets this to their own bounce-processing domain so they can track deliverability and maintain list hygiene.
Return-Path is a technical routing address that recipients never see. It is not the "sender" address. Confusing these two distinct header fields reflects a fundamental misunderstanding of email architecture. RFC 5321 Section 4.4 explicitly provides for the Return-Path to differ from the From address.
Gmail shows a "via" indicator when SPF or DKIM authentication does not fully align with the From: domain. Importantly, if SPF and DKIM both pass and align with the From: domain, Gmail removes the "via" indicator entirely.
The "via" indicator is Gmail's way of showing authentication status to users. Its presence actually demonstrates that Gmail's authentication verification system is working correctly. And for emails where proper DKIM alignment is configured, the "via" indicator does not appear at all.
All email is relayed through servers. That is how email works. The SMTP protocol (RFC 5321) is fundamentally a store-and-forward relay system. Every email — whether sent from Gmail, Outlook, a corporate server, or an ESP — passes through multiple servers (relays) before reaching the recipient's inbox.
The Received: headers document this relay chain, and their presence is expected, normal, and required by RFC 5321 Section 3.7.2. The question is not whether the email was relayed (it always is), but whether the relay was authorized.
When an email passes SPF, DKIM, and DMARC verification, the receiving mail server has independently confirmed that: (1) the sending server was authorized by the domain owner, (2) the email content and headers were not altered in transit, (3) the visible From: domain aligns with the authenticated sending domain, and (4) the domain owner configured an authentication policy. These are machine-verified, cryptographically provable facts — not allegations or opinions. They constitute the strongest possible technical evidence against "forged header" claims.
The burden of proof shifts. When the defendant produces SPF, DKIM, and DMARC pass results, the plaintiff must explain how headers can simultaneously be "forged" AND pass cryptographic verification by the receiving server. This is a technical impossibility — forged headers fail authentication checks by definition.
If you are facing "forged header" allegations in an email anti-spam case, our team can help gather and present authentication evidence. We work with email infrastructure experts to build comprehensive technical defenses.
Contact: owner@terms.law
California State Bar #279869