Your DMARC aggregate reports are the first place you will see DKIM failing at one domain while it passes everywhere else. Most people respond by going straight to DNS. That is the wrong investigation. The aggregate data already tells you whether the problem lies in your infrastructure or somewhere between your infrastructure and that specific receiver. Those two problems have different causes, different evidence, and different fixes.
What DMARC Aggregate Reports Actually Tell You
DMARC aggregate reports are XML files sent daily by receiving domains. Most senders parse them through a reporting tool rather than reading raw XML. Whatever tool you use, the underlying data is the same: which IP addresses sent mail claiming to be from your domain, how many messages they sent, and how each fared against SPF, DKIM, and your DMARC policy.
The first question when you see any failure is whether you recognize the source IP. If the IP is not yours (not your ESP, not your transactional platform, not any infrastructure you authorized), then DMARC is doing exactly what it is supposed to do. Someone is sending mail claiming to be you, failing authentication, and getting it flagged. That is not a problem to fix.
If the IP is yours, the investigation begins. You want to know whether the failures are appearing across multiple reporting organizations or only one, what percentage of that source’s messages are affected, and whether SPF is also failing on the same messages. That combination tells you whether you are looking at a configuration problem, a routing problem, or a post-signing modification problem.
Is Your DKIM Failing at One Domain or All of Them?
Pull the last seven days of aggregate reports and filter for DKIM failures. Then ask: Is the failure appearing in reports from multiple receiving domains, or just one?
If multiple reporters are seeing DKIM failures from the same source IP, the problem is almost certainly in your key infrastructure. The signature is not being generated correctly for that source, or is not generated at all. Check whether that IP is covered by your DKIM signing configuration, confirm the selector is published in DNS, and verify the keys match.
If only one reporter is seeing DKIM failures, do not touch your DNS. A signature that validates at Gmail, Yahoo, and six other receivers but fails at one specific domain is not a broken signature. It is a sign that something is breaking between you and that receiver, or that the receiver is handling it differently than everyone else. DNS does not explain that.
Getting a Failed Message
The aggregate report tells you something is wrong. It does not tell you what. For that, you need to read a message that actually failed at that domain, which means getting the raw headers.
Neither Google nor Microsoft sends DMARC forensic reports. Most senders have not received a single forensic report from anyone in some time. The practical path is a test message to an address at the failing domain, or a message with complete headers from a contact there. What you are looking for is the Authentication-Results header, which is the receiving server’s record of what authentication checks ran and what each found.
The detail in that header varies by receiver. Some will tell you something about why DKIM failed, not just that it did. That is your primary diagnostic clue.
What the Failure Class Tells You
Whatever the failed message header shows you, selective DKIM failures at a single receiver generally fall into one of three categories. Knowing which one you are dealing with determines where you look next.
Post-signing modification is the most common cause of selective failures. Your signature was valid when it left your infrastructure, but the signed header was changed before the receiving server verified it. The signature commits to specific header content at send time. If anything alters those headers in transit, the hash will not match.
Look for very long headers. RFC 5322 dictates the length of an email header. If you have a header that is longer Postmark documented exactly this failure pattern in January 2026, tracing DKIM failures specific to Microsoft recipients to List-Unsubscribe headers exceeding safe lengths.1
Key retrieval failures look different: the receiver tried to fetch your public key from DNS and either got nothing or got something it could not use. This occurs selectively when a receiver’s DNS implementation handles edge cases differently, such as a 2048-bit key that was not correctly split into multiple quoted strings within the TXT record. Standard DNS tools will resolve the record successfully while specific implementations fail. If your header points in this direction, verify the record format directly against RFC requirements rather than just confirming the record exists.
Missing signatures from a recognized source IP are a different problem. If the aggregate data shows an IP you own generating no DKIM signature, that source was never configured to sign, or it is signing with a domain that does not align with your From header. This is common with secondary sending streams (transactional platforms, CRMs, notification services, or even teams trying to get around restrictions) added after initial authentication setup. The source is yours. It just needs to be brought into compliance the same way you would configure any new sender: sign with your domain’s credentials or remove it from your infrastructure.
Confirming the Fix
Once you have identified the cause and made a change, do not assume the problem is resolved. Watch the next several cycles of aggregate reports from the affected domain. The failure rate should drop to zero or near zero on messages from the source you fixed. If it does not, either the fix was incomplete or there is a second source generating the same symptom.
DMARC reports tell you where to look. The message header tells you what you are looking at. The fix follows from the evidence, not from the habit of going straight to DNS whenever DKIM comes up in a conversation.
Footnotes
- Postmark Team, How We Improved Unsubscribe Links to Boost Your Email Deliverability | Postmark, Postmark Blog(Jan. 29, 2026), https://postmarkapp.com/blog/how-we-improved-unsubscribe-links-to-boost-your-deliverability. ↩︎
About the Author
Mickey is a Consultant & Attorney with over 28 years of experience in Email Deliverability & Privacy Law. He has a strong background in email authentication infrastructure (SPF, DKIM, DMARC), ISP and mailbox provider relations, anti-spam policy and compliance, CAN-SPAM and state anti-spam law gained through overseeing the Abuse & Compliance team at Salesforce Marketing Cloud, originating the ISP relations role at Informz (now part of Higher Logic), and working in the fight against spam since 1997. He holds a B.A. in Government, a B.S. in Computer Information Systems, and a J.D. from the University of Houston Law Center. He is a certified CIPP/US professional and a certified CIPM professional.
