A DMARC report arrives showing emails from your domain being sent through an unfamiliar IP address—but with valid authentication signatures. Is it a security breach or normal email behavior? This field note documents a real investigation from alarm to resolution, explaining why email authentication matters and what happens when forwarding, bounces, and cryptographic signatures collide in the wild.
“Why do you need all this complicated email stuff anyway?”
I’ve heard this question more times than I can count. Business owners, solopreneurs, even technical folks question why anyone would bother setting up SPF records, DKIM signatures, and DMARC policies when “email just works” without them.
Last week, I got a reminder of exactly why. And it came in the form of a DMARC report that initially looked like a security breach.
The Alarm Bell
I received a DMARC aggregate report from a major German email provider showing that two emails claiming to be from my domain had been sent through an IP address I didn’t recognize. The IP belonged to a web agency’s hosting infrastructure—not my mail service provider.
Here’s what made it concerning: the report showed that DKIM authentication had passed. DKIM uses cryptographic signatures, and if an email passes DKIM, it means it was signed by someone with access to your private signing keys. That should only be your authorized mail servers.
So the immediate question was: How did emails get signed with my DKIM key but sent through someone else’s infrastructure?
The Investigation
My first instinct was to check whether my email account had been compromised. After all, if someone had gained access to my business email account, they could send emails that would pass all authentication checks. I reviewed login history, checked for unauthorized OAuth applications, and examined application-specific passwords. Everything looked clean.
But the DMARC report was clear: SPF had failed (the sending IP wasn’t authorized), but DKIM had passed (valid cryptographic signature). My DMARC policy is set to “reject”—the strictest possible setting—yet these emails had been delivered anyway.
This is where understanding how DMARC actually works becomes critical.
How Email Authentication Actually Works
Email authentication relies on three main protocols working together:
SPF (Sender Policy Framework) is the simplest. It’s essentially a published list in your DNS records that says “these IP addresses are allowed to send email on behalf of my domain.” When a receiving mail server gets an email claiming to be from your domain, it checks whether the sending IP address is on your approved list.
DKIM (DomainKeys Identified Mail) is more sophisticated. Your mail server adds a cryptographic signature to every outgoing email. The signature is created using a private key that only your mail server knows, and the receiving server can verify it using a public key you publish in your DNS records. The crucial detail: the signature travels with the email, even if it gets forwarded.
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties them together. It tells receiving servers what to do when SPF or DKIM checks fail, and critically, it requires that either SPF or DKIM passes—not necessarily both.
This last point is the key to understanding what happened.
The Email Forwarding Problem
Here’s a scenario that happens thousands of times per second across the internet: Someone sets up an email forward. Maybe they have a business email address that forwards to their personal Gmail account. Or they have a contact form on their website that forwards submissions to their real inbox. This is completely normal and legitimate.
But here’s what happens when an email gets forwarded:
- You send an email from your mail server to their business address
- Your mail server adds a DKIM signature
- The email arrives at their mail server, passing both SPF and DKIM
- Their mail server forwards the email to the final destination
- SPF breaks because now the email is coming from a different IP address than your SPF record authorizes
- DKIM survives because the signature is part of the email content itself
Without DMARC’s “either SPF or DKIM” rule, every forwarded email would fail authentication and get rejected. That would break a massive amount of legitimate email traffic.
What Actually Happened
The unfamiliar IP address belonged to a web hosting company that hosts a website for an organization I had recently contacted. They had set up email forwarding: emails sent to their business address would automatically forward to another address at a different email provider.
I had sent them a perfectly legitimate email—a reply to an inquiry about a community event. My email was properly signed by my mail service provider and passed all authentication checks when it arrived at their server.
Their server then attempted to forward my email to the final destination. But that destination mailbox either didn’t exist anymore or was having problems. The forward failed.
When an email forward fails, the forwarding server generates a “bounce” message—a notification that the delivery failed. This bounce message is sent back to the original sender (me). The bounce includes the headers and often the full content of the original message, complete with my DMARC signature still intact.
So when the DMARC report showed emails from the web agency’s IP address passing DKIM but failing SPF, it was actually documenting this bounce message making its way back to my inbox. The cryptographic signature was still valid because it was my original signature. The SPF check failed because the bounce was coming from their server, not mine.
This is completely normal behavior. It’s exactly how email is supposed to work.
Why This Matters: The Real Value of Email Authentication
So why go through all this trouble setting up email authentication if legitimate emails can still trigger confusing reports?
First, visibility. Without DMARC reporting, I would have had no idea that someone was sending emails related to my domain through an unexpected IP address. Yes, it turned out to be benign—but what if it hadn’t been? The report gave me the information I needed to investigate immediately.
Second, protection. While this particular case was a false alarm, my email authentication setup prevents actual abuse. If someone tries to forge an email claiming to be from my domain without either authorized IP addresses or valid signatures, receiving servers will reject it outright. My “reject” policy means impersonation attempts don’t even make it to the inbox—they’re stopped at the gate.
Third, deliverability. Major email providers like Google and Microsoft have made email authentication increasingly important for inbox placement. Without proper SPF, DKIM, and DMARC configuration, even your legitimate emails risk being flagged as spam or rejected entirely. The authentication setup isn’t just about security—it’s about ensuring your business communications actually reach their destination.
Fourth, professional credibility. When you properly configure email authentication, you’re sending a signal to the internet that you take email seriously. ISPs, security tools, and receiving mail servers all take note. Your domain builds a reputation as a source of legitimate email, which compounds over time into better deliverability.
The Complexity Question
But what about the complexity? Is it really worth the setup hassle and the occasional confusing DMARC report?
Consider the alternative. Without email authentication:
- Anyone can send emails claiming to be from your domain
- You have no visibility into who’s using your domain name
- Your legitimate emails are more likely to be marked as spam
- You can’t prove your emails are actually from you
- Phishing attempts using your brand are trivially easy
The “complicated system” is actually doing several jobs simultaneously:
- Preventing domain impersonation
- Providing forensic data when something looks suspicious
- Improving delivery of legitimate emails
- Building your domain’s sending reputation
- Creating an audit trail of email activity
Yes, understanding DMARC reports requires some technical knowledge. Yes, the initial setup takes time and attention. But once configured, the system runs automatically and provides ongoing protection and visibility.
The Investigation Skills That Matter
This incident also highlights something I emphasize with clients: the value of understanding root causes rather than just reacting to symptoms.
When I received that DMARC report, I could have:
- Panicked and assumed I’d been hacked
- Ignored it as too technical to understand
- Changed all my passwords without understanding what happened
- Contacted support and asked them to “fix it” without investigating
Instead, I systematically worked through the evidence:
- Examined the authentication results to understand what actually passed and failed
- Researched the unfamiliar IP address to identify its owner
- Reviewed my account activity for signs of compromise
- Considered alternative explanations beyond security breach
- Traced the email path from send to bounce
The investigation took perhaps thirty minutes and revealed that no action was needed. But more importantly, it reinforced my understanding of how these systems work and gave me confidence that my security setup is functioning correctly.
The Takeaway
Email authentication might seem like overkill—until the day you need it. Whether that’s preventing a phishing attack using your domain, investigating suspicious activity, or simply ensuring your business emails actually reach customers, the investment pays off.
When someone asks why I bother with “all this complicated email stuff,” I think about this investigation. A system that gives me visibility into potential problems, protects my domain from abuse, and ensures my legitimate communications get delivered—all while running automatically in the background.
That’s not complexity for its own sake. That’s infrastructure working as designed.
The DMARC report that initially looked concerning turned out to document exactly the kind of edge case these systems are built to handle: email forwarding through third-party infrastructure, resulting in a bounce message that preserved authentication signatures while changing the sending IP.
Understanding what happened, why it happened, and why it wasn’t a problem—that understanding only comes from having the right tools in place and knowing how to read their output.
This field note is part of an ongoing series documenting real-world business infrastructure decisions and their outcomes. No security theater, no cargo cult practices—just practical experience with systems that actually matter.
