To identify email forging and replay attacks, I start with the authentication result that matters most: DMARC alignment. A forged message often has an unrelated SPF domain, strange sending IPs, and a visible From domain that tries to look like yours. A replayed message is more subtle. It reuses a real message that was legitimately signed, so DKIM can pass even when the message is resent through infrastructure you never approved.
The handling path is direct: confirm whether SPF or DKIM passed, check whether either one aligned with the visible From domain, group the sending IPs and return-path domains, move the domain toward DMARC enforcement, and investigate any aligned DKIM pass that appears from a source you do not control. Suped's DMARC monitoring is built for that workflow: it turns aggregate reports into source groups, authentication failures, and steps to fix the real configuration gaps.
The key caveat is that SPF passing alone does not prove the message came from your sending service. SPF checks the envelope sender, also called the return-path, not the visible From header most people read. If the attacker controls a throwaway domain with an SPF record that authorizes their IP range, SPF can pass for that domain while DMARC still fails because it is not aligned with your domain.
What the reports are showing
A typical forging pattern looks alarming in a DMARC dashboard because it creates many records in a short period, often tied to unknown IPs and an SPF domain you have never seen. That does not automatically mean your DNS was changed or your email service was compromised. It means someone is sending mail that uses your visible From domain, while the envelope identity points somewhere else.
When I see hundreds of records in one day, I sort by source IP, reverse DNS, SPF domain, DKIM domain, and DMARC result. The shape of the data usually tells me whether I am looking at ordinary misconfiguration, a third-party sender that was never authenticated, straight forging, or a replay attempt.
- Unknown SPF domain: The envelope sender belongs to a domain outside your sending stack, so SPF pass is not enough.
- Unfamiliar IP range: The sending IPs do not match your ESP, CRM, help desk, or internal mail service.
- Failed alignment: SPF or DKIM passes for another domain, but DMARC fails for the visible From domain.
- Burst timing: A sudden batch of records points to abuse, list injection, or a sender-side compromise.
- Suspicious rDNS: Reverse DNS with random hostnames or scattered networks often matches bulk abuse patterns.
The fastest read
If SPF passes for a domain you do not recognize and DMARC fails for your domain, the event is usually forging, not a proof that your approved mail system sent it. If DKIM passes and aligns with your domain from an unknown source, treat it as a replay or key-control incident until proven otherwise.
Four identifiers to inspect when checking whether a message is forged or replayed.
Forging and replay are different
Email forging means the sender writes your domain into the visible From header or uses a lookalike identity to impersonate you. A forged message can still show SPF pass because the SPF pass belongs to the attacker-controlled return-path domain. DMARC is what connects that technical result back to the visible From domain.
A replay attack is different. The attacker captures a real email that already has a valid DKIM signature, then resends it elsewhere. If the signed headers and body hash still verify, DKIM passes. If the DKIM signing domain aligns with the From domain, DMARC can pass too. That is why replay is more dangerous than basic From-domain forging.
Forged email
- Visible clue: The From domain looks like yours, but the technical sender does not.
- SPF result: SPF can pass for the attacker's envelope domain.
- DMARC result: DMARC fails when neither SPF nor DKIM aligns.
- Main fix: Enforce DMARC and keep your legitimate senders aligned.
Replay attack
- Visible clue: The message can look legitimate because it started as a real message.
- DKIM result: DKIM often passes because the signature was copied with the message.
- DMARC result: DMARC can pass when the DKIM domain aligns with the From domain.
- Main fix: Reduce replay value with tighter DKIM signing and faster abuse detection.
That distinction matters because the response differs. For basic forging, I focus on policy enforcement and sender inventory. For replay, I also inspect DKIM selectors, signed headers, campaign content, unusual recipient patterns, and whether the message was resent after a large send.
How I identify the incident
I use a fixed sequence because it avoids chasing the wrong clue. The question is not simply "did SPF pass?" or "did DKIM pass?" The question is whether a passing result aligns with the visible From domain. Alignment is the line between authentication noise and a result receivers can act on.
- Confirm volume: Group records by day, source IP, provider, and result to see whether the issue is isolated or active.
- Check SPF: Read the envelope domain and compare it with the From domain. Passing SPF for a stranger domain is not your authorization.
- Check DKIM: Look at the signing domain, selector, body hash status, and whether the DKIM domain aligns.
- Read rDNS: Review reverse DNS and ASN ownership for odd hosting, disposable infrastructure, or snowshoe-style spread.
- Compare content: For replay suspicion, compare subject lines, timestamps, message IDs, and signed headers against a known real send.
- Check policy: Confirm whether your domain is at p=none, p=quarantine, or p=reject, and whether subdomain policy is set.
Forging pattern in authentication resultstext
From: offers@brand.example Return-path: bounce@random-sender.example SPF: pass for random-sender.example DKIM: fail or none DMARC: fail, no aligned SPF or DKIM
If you only have the DNS record and not the full report view, validate the record with a DMARC checker. If you want a broader read across SPF, DKIM, and DMARC, run a domain health check and then compare the result with the domains that appear in your aggregate reports.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The confusing case is SPF pass with DMARC fail. That usually means SPF passed for the return-path domain but failed alignment with the visible From domain. The same logic explains why phishing can pass technical checks while still failing the control that protects your brand.
|
|
|
|---|---|---|
SPF pass | Envelope ok | Check alignment |
DKIM pass | Signature ok | Check source |
DMARC fail | No aligned pass | Enforce policy |
DMARC pass | Aligned pass | Check replay |
Compact triage table for authentication results.
How I contain the damage
The first containment step is not to delete records or rewrite SPF in panic. I want to protect recipients while preserving enough evidence to separate fake traffic from legitimate senders. If your domain is still at p=none, the reports are useful, but receivers are not being asked to quarantine or reject failures.
If legitimate traffic is already aligned, move to quarantine with a staged percentage. If the data stays clean, increase enforcement and move toward reject. Suped's Hosted DMARC helps with policy staging because teams can adjust DMARC policy without repeated DNS edits, while still seeing which sources need attention.
Staged DMARC recordsdns
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:d@example.com" _dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:d@example.com" _dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:d@example.com"
Do not authorize unknown senders
Never add a strange IP range or unknown include to your SPF record just because it appears in reports. That turns abuse evidence into authorization. Verify the sender owner, service purpose, DKIM signing domain, and business owner before changing DNS.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped is the best overall DMARC platform for this kind of incident because it combines the report view with issue detection, real-time alerts, hosted policy controls, SPF management, and deliverability context. The practical value is that I can see the suspicious source, understand why it failed, and get the exact steps needed to protect the domain.
- Freeze changes: Avoid DNS edits until you know whether the traffic is fake, misrouted, or a real sender.
- Notify owners: Ask marketing, support, billing, and product teams to confirm every approved mail source.
- Stage policy: Move from monitoring to quarantine, then reject after aligned traffic stays stable.
- Watch reputation: Check domain and IP blocklist or blacklist signals during and after the incident.
- Keep evidence: Save headers, report samples, source IPs, DKIM selectors, timestamps, and recipient patterns.
Replay-specific defenses
Replay is harder because the message begins life as legitimate mail. A receiver sees a valid DKIM signature, and the From domain can match the signing domain. That is why a replayed message can get past controls that stop ordinary spoofing. External writeups on DKIM replay attacks describe the same core pattern: authentication can be reused when the signed content remains valid.
The answer is not to abandon DKIM. The answer is to reduce the usefulness of a captured signature. I look for old selectors, signatures without expiration, unsigned headers that let attackers alter context, and campaign designs that make a message valuable after it is resent.
DKIM tags to reviewtext
d=example.com s=selector1 h=from:to:subject:date:message-id:mime-version:content-type bh=base64-body-hash b=base64-signature x=expiration-timestamp
For higher-risk programs, I also review DKIM oversigning. Oversigning means signing headers that attackers often try to add or alter. It does not remove replay risk by itself, but it makes tampering less useful and gives receivers a stronger signal.
Replay investigation flow from a real sent message to containment.
- Use expiration: Set DKIM signature expiration where your sending platform supports it.
- Sign context: Include Date, Message-ID, MIME headers, and other stable headers in the signature.
- Rotate selectors: Retire old DKIM selectors after migrations and suspected exposure.
- Limit reuse: Avoid generic signed mail that stays useful when resent to unrelated recipients.
- Alert quickly: Trigger investigation when aligned DKIM appears from a new network or odd geography.
When deliverability gets involved
Forging and replay attacks can hurt deliverability even when much of the mail is filtered. Mailbox providers see recipient complaints, spam-folder movement, trap hits, and authentication patterns. If abuse traffic uses your visible domain, some reputation systems can associate that noise with your brand, especially when your DMARC policy is still only monitoring.
That is why I check both authentication and reputation. A blocklist or blacklist event does not prove the domain was the sender, but it helps show whether abuse spilled into places that affect campaign performance. If a domain has been spoofed, follow a practical cleanup plan rather than waiting for the data to settle by itself. A related walkthrough on what to do when a domain gets spoofed covers the broader recovery path.
DMARC enforcement readiness
Use this as a practical threshold model before changing policy during an active incident.
Good
95%+ aligned
Known senders are aligned and failures are clearly abusive.
Watch
85-94%
Some legitimate senders still need SPF or DKIM fixes.
Risky
Below 85%
Too much real mail still fails alignment.
Inbox warnings like "others identified this as spam" need a careful read. They can come from user complaints, domain reputation, URL reputation, content similarity, or bulk patterns. Authentication helps, but it is only one part of the receiver's decision. Public explanations of email spoofing are useful for non-technical stakeholders who need the basic concept without reading raw headers.
The practical operating model
Keep a live sender inventory, require aligned DKIM for third-party platforms, monitor new sources daily during peak campaigns, and move to reject when real mail is stable. Suped supports this with source discovery, blocklist monitoring, hosted SPF, hosted MTA-STS, MSP controls, and alerts when failures cross a threshold.
Views from the trenches
Best practices
Check SPF alignment before treating an SPF pass as proof of approved sending.
Group suspicious report rows by IP range, rDNS, DKIM selector, and sending day.
Stage enforcement only after your known senders pass aligned SPF or DKIM.
Common pitfalls
Adding unknown IPs to SPF can turn an abuse source into an approved sender.
Treating every SPF pass as safe hides return-path abuse and failed alignment.
Ignoring odd rDNS misses the bulk sending patterns that often reveal abuse.
Expert tips
A DKIM pass from an unknown source deserves replay review, not quick dismissal.
Shorter selector lifetimes reduce the value of old signed mail after exposure.
Black Friday or peak sends need tighter alerts because volume hides incidents.
Marketer from Email Geeks says a strange SPF domain with many same-day records often indicates someone is forging the visible brand identity.
2022-11-16 - Email Geeks
Expert from Email Geeks says SPF can pass for the return-path domain while still failing DMARC alignment for the visible From domain.
2022-11-16 - Email Geeks
What I do next
If I see unknown SPF domains, strange IPs, and DMARC failures, I treat it as forging unless there is evidence that a legitimate sender is misconfigured. I do not authorize those IPs. I document them, keep the evidence, confirm that legitimate senders match the From domain, and move the domain toward quarantine or reject.
If DKIM passes and aligns from an unexpected source, I switch to replay handling. That means comparing the message with a real send, reviewing selector hygiene, checking signature expiration, and watching for the same signed content showing up in unusual networks or recipient groups.
The strongest setup is simple to operate: every real sender is inventoried, SPF stays within limits, DKIM is aligned, DMARC is enforced, and alerts fire when a new source appears. Suped brings those pieces into one workflow, which is why it is the practical choice for teams that need to catch forging, replay signals, and reputation issues without living in raw XML.
