Fixing a Backscatter Storm: How We Secured a Client’s Domain with SPF, DKIM & DMARC
Real-world case study on resolving a backscatter spam attack by implementing SPF, DKIM, and DMARC correctly. Learn how DNS misconfiguration led to spoofing, how we diagnosed it, and how to lock down your domain against impersonation
One morning, a client’s inbox was suddenly flooded with messages from “Mail Delivery System”, dozens of “Undelivered Mail Returned to Sender” notifications from relay.mailchannels.net.
At first glance, it looked like her mailbox had been compromised. But after reviewing the headers, the truth was subtler:
spammers were sending messages pretending to be her.
Her domain had become the victim of backscatter, forged emails bouncing back to her address because her domain lacked proper authentication.
The Root Cause: Backscatter Explained
Backscatter occurs when a spammer spoofs your domain in the “From” field and sends junk messages to others.
When those fake messages fail to deliver, the bounce-backs are sent to you, even though you never sent them.
They don’t have access to your inbox, they’re just impersonating your identity.
In this case, the problem existed because:
- The SPF record was too permissive, allowing almost anyone to send mail.
- There was no DMARC policy in place.
- DKIM was present but not fully aligned with the domain.
As I explained to the client:
“This was a case of backscatter, a spammer sent mail pretending to be you. They never accessed your mailbox, but exploited weak authentication..”
I solely get the blame for blame for this incident tho. At the time I setup the service, I know little to nothing about email authentication and how spoofing worked. My recent spiral into learning about emails security has been key to helping me identify the issue and resolve it promptly.
The Secondary Problem: Sending Blocked
Because so many spoofed messages were circulating, the outbound relay service (MailChannels via A2Hosting) temporarily blocked outgoing mail from the domain.
Every attempt to send an email triggered:
“Cannot Send Mail — [address] is not valid and has been rejected by the server.”
Even legitimate emails were bouncing. The domain was effectively blacklisted. My service provided had also reached out to let me know of the change and informed me the domain was heavily spamming.
The Turning Point: Finding the Real DNS Zone
I initially updated the SPF and DMARC records inside A2Hosting’s DNS editor and waited 24 hours, but nothing changed. I wear missing something. Running:
dig NS exampledomain.com
revealed this:
ns1036.ui-dns.biz. ns1016.ui-dns.org. ns1057.ui-dns.com. ns1083.ui-dns.de.
IONOS was the authoritative DNS host, not A2Hosting. This is a setup I had decided upon because It made it cheaper for my friend, who only had to pay for her website hosting and no extras fees for emails. I cover the cost since I already have a mail service on my server.
Once I made the corrections directly in the IONOS DNS zone, the new records propagated within minutes.
The Corrected Records
After confirming the proper zone and using dig to verify changes, these are the final working configurations:
dig +short TXT example.com
v=spf1 ip4:68.66.226.123 include:spf.a2hosting.com -all
Only the website’s server and A2Hosting’s MailChannels relays are authorized.
DKIM
default._domainkey Value: v=DKIM1; k=rsa; p=<public key from A2Hosting>
Every message is cryptographically signed before leaving the server.
DMARC
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@exampledomain.com; fo=1; ri=86400
Strict alignment, full reporting, and a clear “reject” policy for any unauthorized sender.
After applying the changes on the sever, I checked it was effectively saved with
dig +short TXT example.com @ns1036.ui-dns.biz
v=spf1 ip4:68.66.226.123 include:spf.a2hosting.com -all
The command consults one of the name servers to ensure it has received the new config. To verify propagation on the web, the command will be
dig +short TXT example.com
Within minutes of publishing the updated records on IONOS, a new test message sent to Gmail returned:
spf=pass
dkim=pass
dmarc=pass
All authentication checks passed. Emails were delivered successfully again, and the MailChannels block was lifted after I requested it to my service provider, informing them of the updates.
In the process of making sure everything was back to normal, I discovered this tool : dracoeye.com. It confirmed the affected domain reputation was still in good standing, at least as we speak. We will see if this status stays the same in the upcoming months.
This case wasn’t just about stopping spam, it was about reclaiming control of a domain’s identity by tightening email authentication and adding DMARC enforcement, the client’s domain went from being impersonated by spammers to being fully verified, sealing shut the door to bad actors.