Your DMARC records are fine — so why are you still landing in spam? Common email authentication gaps shack users overlook

Introduction: When DMARC Compliance Isn’t Enough

You’ve done the homework. Your DMARC record is published, your SPF record is tidy, and your DKIM keys are rotated on schedule. Yet, despite this careful work, a significant portion of your outbound email is still landing in spam folders. This frustrating scenario is more common than many practitioners admit. The truth is that DMARC compliance is a necessary but insufficient condition for consistent inbox placement. Email deliverability depends on a complex ecosystem of authentication, reputation, content, and infrastructure factors that go far beyond the DMARC checkmark.

In this guide, we’ll explore the hidden gaps that even well-intentioned teams overlook. We’ll move beyond basic configuration checklists and dive into the practical, often messy reality of email delivery. Our goal is to help you identify why your emails are being filtered, even when your authentication records appear perfect. We’ll cover common pitfalls like misaligned domains in SPF, DKIM signature failures in forwarded messages, and the subtle ways that third-party services can break your authentication chain. By the end, you’ll have a clear diagnostic framework and actionable steps to close these gaps.

This overview reflects widely shared professional practices as of May 2026; verify critical details against current official guidance where applicable.

1. The False Comfort of a “Passing” DMARC Check

Many teams celebrate when their DMARC report shows a “pass” for most messages. However, this metric can be misleading. DMARC is a policy framework that tells receiving servers what to do with messages that fail SPF or DKIM checks. A passing DMARC check means that the message passed at least one of these underlying mechanisms with correct domain alignment. But passing DMARC does not guarantee that the message will avoid spam filters. ISPs and email security gateways use hundreds of additional signals to classify mail, including sender reputation, content analysis, user engagement patterns, and infrastructure consistency.

Consider a scenario where your DMARC policy is set to “none” (p=none) for monitoring purposes. In this case, even if all messages pass DMARC, they are not protected from abuse, and receiving servers may still treat them with suspicion if they lack a strong sending reputation. Furthermore, DMARC only covers the authentication of your domain; it does not address issues like poor list hygiene, high complaint rates, or content that triggers spam filters. A clean DMARC report can lull you into a false sense of security, while the real problems lie elsewhere.

The Misalignment Trap: When SPF or DKIM Align but Don’t Match

One of the most common gaps we see involves domain alignment. DMARC requires that the domain in the “From” header aligns with either the domain in the SPF envelope (return-path) or the domain in the DKIM signature. However, alignment can be “strict” or “relaxed.” Many teams use relaxed alignment (allowing subdomains) without realizing that their third-party email service provider might be sending from a completely different domain. For example, if your transactional email provider signs with their own domain (e.g., mail.sendgrid.net) instead of yours, DKIM alignment will fail even if the DKIM signature is valid. The message might pass SPF alignment if the return-path matches your domain, but this is a fragile setup that can break under forwarding.

We recommend auditing each sending source individually. Check whether your email service provider (ESP) supports DKIM signing with your domain, and verify that the signing domain matches your MX domain. A quick test using a tool like a raw email header analyzer can reveal the exact domains used in the Authentication-Results header. If you see alignment failures, contact your ESP to enable custom DKIM signing. This is a straightforward fix that many teams overlook for months.

Another subtle case involves using multiple subdomains for different sending streams (e.g., marketing.yourdomain.com and transactions.yourdomain.com). If your DMARC policy applies only to the parent domain, subdomain alignment may be relaxed, but the reputation of each subdomain is tracked independently. A low reputation on one subdomain can spill over to others, especially if you use shared IP pools. The solution is to publish separate DMARC records for each subdomain if they have distinct sending patterns, or to consolidate sending under a single domain with strict alignment.

Finally, consider the case of forwarded messages. When a user forwards an email from an external service, the SPF check often fails because the forwarding server is not authorized in the original domain’s SPF record. DMARC can still pass if DKIM alignment holds, but many forwarding services strip or modify DKIM signatures. This is why ARC (Authenticated Received Chain) is essential. Without ARC, legitimate forwarded messages can fail authentication and be rejected. We’ll cover ARC in more depth later in this guide.

2. SPF Record Complexity: More Than Just a List of IPs

SPF (Sender Policy Framework) is often the first authentication mechanism teams implement, but its simplicity is deceptive. An SPF record that includes too many lookups, uses the “all” mechanism incorrectly, or omits critical sending sources can cause legitimate emails to fail authentication. The technical limit is ten DNS lookups per SPF evaluation; exceeding this limit causes a “permerror” that results in SPF failure. Many organizations add multiple third-party service includes without realizing they are approaching this limit, especially when they use services like Salesforce, Mailchimp, SendGrid, and HubSpot simultaneously.

Beyond lookup limits, the “~all” (softfail) versus “-all” (hardfail) mechanism is a frequent point of confusion. Using “~all” tells receiving servers that messages from unauthorized sources should be treated as suspicious but not rejected outright. This is a safe starting point, but it can lead to inconsistent handling across different ISPs. Some ISPs treat softfail as a pass, while others flag the message. Conversely, using “-all” is strict and will cause rejection of any message not from an authorized source, which can break legitimate forwarding. We typically recommend starting with “~all” and monitoring your SPF failure reports before switching to “-all” once you are certain all legitimate sources are included.

The Include Chain: Avoiding the Lookup Limit Trap

Let’s walk through a typical scenario. A company uses Microsoft 365 for email, Salesforce for CRM, and a third-party marketing platform. Their SPF record looks like this: v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com include:sendgrid.net ~all. This record uses three includes, each of which may resolve to multiple IP ranges. The total lookups might be 9 or 10, which is dangerously close to the limit. If the company adds a fourth include, the SPF evaluation will fail entirely for all messages. The solution is to consolidate includes where possible, use IP range mechanisms instead of includes for small providers, or migrate to a service that supports SPF flattening.

SPF flattening is a technique where you resolve all IP addresses from your includes and publish them as literal ip4 or ip6 mechanisms in your SPF record. This reduces the number of lookups to one (because the record itself contains the IPs). However, this approach has a downside: if your ESP adds new IP addresses, your SPF record will become stale until you update it. We recommend using flattening only if you have a dynamic process (e.g., a script that updates the record daily) or if your ESP provides a static IP range.

A more robust approach is to use SPF macros, though they are poorly supported by many providers. Instead, we suggest auditing your SPF record quarterly. Remove any includes for services you no longer use, and verify that each include is still valid. A common mistake is keeping an include for an old email provider long after you’ve migrated. This not only wastes lookup capacity but also authorizes IPs you no longer control, increasing your attack surface.

Finally, consider the impact of email forwarding on SPF. When a message is forwarded, the original SPF record checks the forwarding server’s IP, which is unlikely to be authorized. This is a known limitation of SPF. The solution is to use DKIM and DMARC together, and to implement ARC to preserve the authentication chain. We’ll discuss ARC in a later section. For now, remember that SPF alone is not a reliable authentication method for messages that are likely to be forwarded.

3. DKIM Signature Fragility: The Hidden Weaknesses

DKIM (DomainKeys Identified Mail) provides a cryptographic signature that verifies the email’s content has not been tampered with and associates it with a signing domain. However, DKIM signatures are surprisingly fragile. They can break if any part of the signed headers or body is modified during transit. Common modifications include adding a footer by a mailing list, changing the subject line by an email client, or inserting a tracking pixel by a forwarding service. When the signature breaks, the message fails DKIM verification, and if DMARC requires DKIM alignment, the message fails DMARC as well.

Many teams assume that once they set up DKIM, it will work indefinitely. But DKIM keys need regular rotation, and the signing algorithm matters. Using a weak key (e.g., 1024-bit RSA) is less secure and may be rejected by some receiving servers. The recommended practice is to use 2048-bit RSA keys or, better yet, Ed25519 keys if your ESP supports them. Additionally, DKIM selectors (the name in the DKIM signature) must match the DNS record. A typo in the selector name can cause all DKIM checks to fail silently.

The Forwarding Problem: Why DKIM Breaks in Transit

Let’s examine a concrete example. Alice sends a newsletter signed with DKIM from newsletter.example.com. Bob has set up email forwarding from his personal domain to his Gmail address. When the message passes through Bob’s forwarding server, that server may modify the message’s body by adding a disclaimer footer. This modification changes the body hash, invalidating the DKIM signature. Even if the receiving Gmail server has a good relationship with the forwarding server, the DKIM failure can cause the message to be flagged as suspicious. The result: Alice’s newsletter lands in Bob’s spam folder, even though her DMARC setup is technically correct.

How do you fix this? There are two approaches. First, you can ensure your email content is resistant to modification. Avoid relying on body DKIM signatures alone; use the “l” (header list) parameter to sign critical headers that are less likely to change. Second, you can implement ARC (Authenticated Received Chain) on your forwarding servers. ARC creates a chain of authentication stamps that preserve the original SPF and DKIM results through each hop. While ARC adoption is growing, it is not universal. As a sender, you can encourage your recipients to use forwarding services that support ARC.

Another overlooked aspect is DKIM signature canonicalization. The two common algorithms are “simple” and “relaxed.” Simple canonicalization is strict and will break on minor whitespace changes. Relaxed is more forgiving and handles common modifications like header wrapping. We recommend using relaxed canonicalization for both headers and body, unless you have a specific reason to use simple. Check your ESP’s configuration to ensure you are using the most permissive setting.

Finally, monitor your DKIM signing status. Use the DKIM report provided by your ESP or a third-party monitoring service. Look for a high rate of “dkim=fail” results in your DMARC aggregate reports. A sudden increase in DKIM failures often points to a change in the email pipeline, such as a new content filter or a misconfigured relay. Investigate quickly, because persistent DKIM failures degrade your domain’s reputation over time.

4. ARC: The Missing Link in Forwarded Email Authentication

Authenticated Received Chain (ARC) is a protocol that preserves email authentication results through intermediate servers, such as mailing lists or forwarding services. Without ARC, when a message is forwarded, the original SPF and DKIM results can be lost, causing the message to fail DMARC even if it was originally authenticated. ARC creates a set of headers that record the authentication status at each hop, allowing the final receiving server to trust the original authentication results. Despite its utility, ARC adoption among email forwarding services and mailing lists remains inconsistent.

Many organizations overlook ARC because they focus on their own sending infrastructure. However, if your recipients use forwarding services, your deliverability can suffer regardless of your own authentication setup. For example, a user who forwards their work email to a personal Gmail account may cause your legitimate messages to be flagged. The receiving server sees a failed SPF check (because the forwarding server’s IP is not authorized) and a possibly broken DKIM signature. Without ARC, the receiving server has no way to know that the original message passed authentication.

How to Diagnose and Mitigate ARC-Related Gaps

To diagnose whether ARC is affecting your deliverability, examine your DMARC aggregate reports for patterns of failures from ISPs that use forwarding services. Look for messages that failed SPF but passed DKIM, or vice versa, and note the “Source IP” in the report. If the source IP belongs to a known forwarding service (e.g., a domain like forwarding-service.com), ARC is likely the missing piece. You can also send a test email to a disposable address that forwards to your own inbox, then inspect the full email headers. If you see “ARC-Authentication-Results” headers, the forwarding service supports ARC. If not, you’ve found the gap.

As a sender, you cannot directly force forwarding services to implement ARC. However, you can encourage your recipients to use forwarding services that support it. Some major providers like Gmail and Outlook.com have their own forwarding mechanisms that handle authentication better. You can also advise your users to whitelist your domain in their email settings, though this is not a scalable solution. A more practical approach is to improve the resilience of your own authentication. Use DKIM with relaxed canonicalization and longer key lengths to reduce the chance of signature breakage.

Another strategy is to use BIMI (Brand Indicators for Message Identification) in conjunction with DMARC. While BIMI does not solve the forwarding problem directly, it provides a visual trust signal that can influence recipient behavior. Users who see a verified brand logo are more likely to move your email from spam to inbox, which trains the ISP’s filter over time. This is a long-term play, but it can complement your technical fixes.

Finally, consider using a dedicated sending infrastructure that avoids forwarding altogether. For critical communications, ask your recipients to update their email preferences to receive mail at their primary inbox rather than through a forwarding alias. This is a behavioral change, but it can dramatically improve deliverability for high-value messages like password resets and purchase confirmations.

5. MTA-STS and TLS Reporting: The Infrastructure Gaps

Email authentication is not just about headers and DNS records; it also depends on secure transport between mail servers. MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS reporting are protocols that ensure your outbound email is transmitted over encrypted connections and that failures are reported. Without MTA-STS, your emails can be downgraded to plaintext during transit, making them vulnerable to interception and modification. More importantly, some ISPs factor the security of the transport layer into their spam scoring. If your mail server does not support TLS or has a poor TLS reputation, your emails may be penalized.

Many teams ignore MTA-STS because it is not required for basic authentication. However, as email security best practices evolve, major providers like Google and Microsoft are increasingly prioritizing encrypted delivery. If your mail server does not publish an MTA-STS policy, or if the policy is misconfigured, your emails may be treated as less trustworthy. Similarly, TLS reporting (SMTP TLS Reporting) allows you to receive reports about delivery failures due to TLS issues, giving you data to improve your infrastructure.

Setting Up MTA-STS: A Step-by-Step Guide

To implement MTA-STS, you need to publish a policy file on your web server and create a DNS record. First, create a JSON policy file that specifies your mail server hostnames and the desired TLS behavior (enforce, testing, or none). For example: { "version": "STSv1", "mode": "enforce", "mx": ["mx1.yourdomain.com", "mx2.yourdomain.com"], "max_age": 86400 }. Place this file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Then, create a DNS TXT record at _mta-sts.yourdomain.com with the value v=STSv1; id=2026050101;. The ID is a simple version number; update it when you change the policy.

Once published, monitor your MTA-STS policy for errors. Use tools like the MTA-STS validator from Hardenize or the SMTP TLS Reporter to check that your policy is accessible and correctly formatted. A common mistake is forgetting to update the DNS record when you change the policy file, causing a mismatch. Another pitfall is setting the mode to “enforce” before you are confident that all inbound servers support TLS. Start with “testing” mode to collect reports without risking delivery failures. Switch to “enforce” only after you have verified that all legitimate mail servers in your ecosystem can handle TLS.

For TLS reporting, publish a DNS TXT record at _smtp._tls.yourdomain.com with the value v=TLSRPTv1; rua=mailto:[email protected]. This tells receiving servers to send TLS failure reports to the specified email address. Review these reports regularly to identify delivery issues caused by TLS problems. If you see a spike in failures from a particular ISP, it may indicate a temporary outage on their side or a configuration change that you need to address.

Finally, ensure that your own mail servers support TLS 1.2 or higher. Older versions like TLS 1.0 and 1.1 are now deprecated and may be blocked by some providers. Regularly test your SMTP connection using tools like CheckTLS or the SMTP TLS Tester. A simple misconfiguration, such as requiring client certificates when not needed, can cause encrypted delivery to fail. By investing in MTA-STS and TLS reporting, you close a gap that many teams overlook entirely.

6. Third-Party Service Integration: The Authentication Chain Breaks

Modern email ecosystems often involve multiple third-party services: a transactional email provider, a marketing platform, a CRM, and perhaps a customer support ticketing system. Each of these services sends email on your behalf, and each must be properly authenticated. The most common mistake is assuming that a single DMARC record covers all of them. In reality, each service may use its own sending infrastructure, subdomains, and authentication methods. If any one of them is misconfigured, it can drag down the reputation of your entire domain.

For example, a team might set up DKIM for their marketing platform but forget to configure it for their transactional provider. The transactional emails pass SPF (if the return-path is aligned) but fail DKIM. If DMARC requires DKIM alignment (as many providers recommend), those transactional emails will fail DMARC and may be rejected or spammed. Worse, if the transactional provider has poor sending practices (e.g., high bounce rates), the reputation of your domain can suffer, affecting all email streams.

Auditing Your Third-Party Sending Ecosystem

We recommend a systematic audit of every service that sends email using your domain. Start by creating a list of all third-party services you use for email. For each service, determine the following: what sending domain or subdomain they use, whether they support custom DKIM signing, whether they support SPF include for your domain, and what their sending reputation is. You can check reputation using tools like SenderScore or by reviewing your DMARC aggregate reports for that service’s IPs.

Once you have the list, prioritize fixing services that fail authentication. The most common fix is to enable custom DKIM signing, which usually involves adding a CNAME record provided by the service to your DNS. For example, a service might ask you to add dkim._domainkey.yourdomain.com CNAME dkim.service.com. Follow the service’s documentation exactly, and verify the DNS propagation before sending a test email. A typo in the CNAME target can cause DKIM to fail silently.

Another gap is the use of shared IP pools by ESPs. If your transactional provider uses shared IPs, your emails may be affected by the sending behavior of other customers on the same IP. Some ESPs offer dedicated IPs or private pool options, which isolate your reputation but come at a higher cost. We recommend using dedicated IPs for high-volume senders, especially if you are experiencing deliverability issues. Also, ensure that your ESP supports SPF flattening or provides a stable list of IPs so you can update your SPF record accurately.

Finally, consider the impact of email authentication on your analytics. Some ESPs add tracking links that redirect through their own domains, which can break DMARC alignment if the redirect domain is not authenticated. Use custom tracking domains (e.g., track.yourdomain.com) to maintain alignment. This requires setting up a separate subdomain with its own SPF and DKIM records, but it ensures that your tracking links are covered by your DMARC policy. By closing these third-party integration gaps, you protect your domain’s reputation from the weakest link in your sending chain.

7. Content and Reputation: The Non-Authentication Factors

Even with perfect authentication, your emails can still land in spam due to content issues or poor sender reputation. Spam filters use machine learning models that analyze the text, structure, and metadata of your email. Common triggers include excessive use of spammy keywords (e.g., “free,” “guaranteed,” “act now”), high image-to-text ratios, lack of a plain-text alternative, and poor HTML code. Additionally, user engagement signals like low open rates, high complaint rates, and high bounce rates feed into the sender reputation that ISPs maintain for your domain.

Many teams focus solely on authentication and ignore content hygiene. For example, a marketing campaign that uses all-caps subject lines and multiple exclamation marks may pass DMARC with flying colors, but it will still be flagged by content filters. Similarly, if you send to stale email lists with high bounce rates, your sender reputation will degrade over time, causing even your transactional emails to be spammed. Authentication does not substitute for good list management and content practices.

Diagnosing Content and Reputation Issues

To diagnose content-related issues, use a spam checker tool like Mail-Tester or SpamAssassin. Send a test email to the tool’s address and review the score and the specific rules that triggered. Common issues include missing List-Unsubscribe headers (required for bulk senders), missing physical mailing address (required by CAN-SPAM), and poor subject line formatting. Fix these issues one by one, and re-test until your score is below 3 (on a scale of 0 to 10, where lower is better).

For reputation issues, monitor your domain’s reputation using Google Postmaster Tools and Microsoft SNDS (Smart Network Data Services). These tools provide data on complaint rates, spam rate, and delivery errors. If your complaint rate exceeds 0.1%, take immediate action. Review your list acquisition practices, ensure you have a clear unsubscribe process, and consider implementing a double opt-in for your subscription forms. A high complaint rate is a strong signal to ISPs that your recipients do not want your email, and they will route more of your messages to spam as a result.

Another often overlooked factor is email authentication for feedback loops. Many ISPs provide feedback loops (FBLs) that notify you when a recipient marks your email as spam. Set up FBLs with major providers like Yahoo, AOL, and Outlook.com. When you receive a complaint, promptly remove the recipient from your list. This not only reduces future complaints but also demonstrates to ISPs that you are responsive to user preferences.

Finally, consider the timing and frequency of your emails. Sending too many emails in a short period can trigger rate-limiting or volume-based filtering. Spread your campaigns out, and warm up new sending IPs gradually. A common practice is to start with low volume and increase over a few weeks, monitoring deliverability at each step. By combining authentication with content and reputation management, you create a holistic email program that earns inbox placement rather than relying solely on technical compliance.

Frequently Asked Questions About DMARC and Spam Delivery

Q: If my DMARC reports show a 100% pass rate, why are my emails still going to spam?
A: DMARC only checks authentication alignment. Spam filters also evaluate content, sender reputation, user engagement, and infrastructure. A 100% pass rate does not guarantee inbox delivery. Check your spam score, complaint rate, and list hygiene separately.

Q: How do I know if email forwarding is breaking my authentication?
A: Look at your DMARC aggregate reports for messages that failed SPF but passed DKIM (or vice versa). If the source IP is a known forwarding service, ARC is likely missing. Inspect the headers of a forwarded test email to see if ARC headers are present.

Q: Should I use p=reject in my DMARC policy right away?
A: No. Start with p=none to monitor your email flows for at least a month. Then switch to p=quarantine for a month, and only move to p=reject after you have verified that all legitimate sources pass authentication. Moving too quickly can block legitimate forwarded or third-party emails.

Q: Can BIMI help with spam delivery?
A: BIMI provides a visual trust signal but does not directly affect spam filtering. However, it can improve user engagement, which indirectly trains ISP filters over time. It is a complementary measure, not a replacement for fixing authentication gaps.

Q: How often should I rotate my DKIM keys?
A: Industry best practice is to rotate DKIM keys every 6 to 12 months. Some ESPs offer automatic rotation. Use at least 2048-bit RSA keys or Ed25519 for stronger security. Rotate immediately if you suspect a key compromise.

Q: What is the most common mistake teams make with SPF?
A: Exceeding the 10-DNS-lookup limit. This causes SPF to permanently fail for all messages. Use SPF flattening or remove unnecessary includes to stay under the limit. Also, avoid using multiple includes for the same service.

Conclusion: Moving Beyond DMARC Compliance

DMARC is a powerful tool, but it is not a silver bullet for email deliverability. The gaps we’ve covered—SPF complexity, DKIM fragility, missing ARC, third-party integration issues, infrastructure security, and content hygiene—are common reasons why even well-configured domains end up in spam. The key takeaway is that email deliverability requires a holistic approach. Authentication must be combined with reputation management, content best practices, and proactive monitoring.

We recommend a three-phase strategy: first, audit your current authentication setup using the steps in this guide. Second, fix the gaps you find, starting with the highest-impact issues (like DKIM alignment and SPF lookup limits). Third, establish ongoing monitoring processes, including regular review of DMARC aggregate and forensic reports, TLS reports, and sender reputation dashboards. By treating email authentication as an ongoing practice rather than a one-time setup, you can maintain consistent inbox delivery and protect your domain’s reputation.

Remember that the email landscape evolves constantly. New protocols like TLS 1.3, MTA-STS, and ARC are becoming standard. Stay informed about updates from major providers and adjust your configuration accordingly. With careful attention to the gaps we’ve outlined, you can move from “DMARC is fine” to “my emails consistently reach the inbox.”