Reading Authentication-Results Headers to Fix DMARC Alignment

You check your email deliverability tools and find that outbound messages to recipients at providers like Google or Yahoo are bouncing, getting throttled, or landing directly in the spam folder. When you check your domain records, your SPF record returns a valid pass, and your outgoing messages carry a cryptographically intact DKIM signature. Yet the mailbox provider reports a DMARC policy failure, leaving you wondering how an email can pass both core security checks and still fail authentication. The disconnect almost always comes down to domain alignment. DMARC does not merely check whether an email has a signature or comes from an authorized server; it checks whether the identity stamped on those technical checks matches the visible sender address shown to the end user. When troubleshooting these issues, your most reliable diagnostic tool is the Authentication-Results header inserted by the receiving mail transfer agent.

Why does DMARC fail if both SPF and DKIM pass?

To understand why this happens, it helps to distinguish between authentication and alignment. SPF validates the technical envelope sender—known in email protocols as the RFC 5321 Mail From or return-path address. DKIM validates that a specific message body and selected headers were signed by the domain specified in the d= tag of the DKIM-Signature header. Neither of these protocols, by default, cares what domain appears in the visible From: address (the RFC 5322 header) that a user sees in their email client. DMARC was specifically created to tie these disparate protocols to the visible From: domain. Under DMARC specifications, an email passes authentication only if at least one underlying protocol (SPF or DKIM) passes both its cryptographic/authorization check and aligns with the organizational domain of the From: header. If your transactional mail service sends an email with From: [email protected] but signs it with d=serviceprovider.com and transmits it via a return-path of [email protected], both SPF and DKIM pass in isolation. However, neither aligns with example.com, causing DMARC to fail outright. In standard hosting environments, this situation surfaces frequently when third-party services, CRM platforms, or web application forms send mail using your root domain as the visible sender while relying entirely on shared third-party infrastructure. Major providers like Google and Yahoo require compliant authentication for reliable bulk inboxing, making proper identifier alignment non-negotiable.

Where do you find the Authentication-Results header, and what does it look like?

When a mailbox provider receives a message, its incoming mail server evaluates the incoming connection, headers, and DNS records. It then injects a header named Authentication-Results (defined by RFC 7601) at the top of the message headers before writing the email to storage. To view it, you open the message in the recipient inbox and choose the option to view raw headers (such as "Show original" in Gmail or "View raw message" in standard webmail interfaces). If you have already worked through checking mail headers to trace message routing, finding this section will be familiar. The header contains a list of sub-results, typically detailing SPF, DKIM, DMARC, and sometimes PTR or reverse DNS status. Reviewing this output reveals exactly which identity the recipient server evaluated.

TEXT

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=smtpapi header.b=AbCd1234;
       spf=pass (google.com: domain of [email protected] designates 198.51.100.25 as permitted sender) [email protected];
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com

(Contoh format output header otentikasi di server penerima) In this illustrative output, notice the individual components. The dkim=pass entry indicates that the message signature is valid, but the signing identity (header.i) belongs to @sendgrid.net. Similarly, spf=pass confirms that the sending IP address is authorized, but the evaluated envelope (smtp.mailfrom) is also under sendgrid.net. Finally, look at the DMARC line: dmarc=fail ... header.from=example.com. Because neither the SPF domain nor the DKIM signing domain matches example.com, DMARC evaluates to an absolute failure.

How do you check if SPF is failing alignment?

To check SPF alignment, locate two specific parts of the header: the smtp.mailfrom (or Return-Path) value in the authentication summary, and the visible header.from domain. SPF alignment requires that the domain in the envelope sender matches the domain in the From: header. By default, DMARC uses "relaxed" alignment for SPF (specified by aspf=r in your DMARC DNS record, which is the default if omitted). Relaxed alignment means the organizational domains must match, even if the subdomains differ. For example, if your From: address is [email protected] and your return path is [email protected], relaxed SPF passes alignment because both share the organizational root example.com. However, if your DMARC record explicitly sets strict alignment (aspf=s), the subdomains must match identically, meaning mail.example.com would fail alignment against example.com. If the header shows that the smtp.mailfrom domain belongs to your hosting provider's shared server hostname or an email routing vendor rather than your own domain, SPF cannot provide DMARC alignment. You can fix this either by configuring a custom return-path (often set up via a CNAME record pointing to your sending service) or by relying on DKIM alignment instead, since DMARC requires only one of the two protocols to pass in alignment.

How do you verify whether DKIM is aligning properly?

DKIM alignment is checked by comparing the d= (domain) tag in the DKIM evaluation to the domain in the visible From: header. In the Authentication-Results header, look for the header.i= or header.d= tag alongside dkim=pass. Just like SPF, DKIM alignment operates in relaxed mode (adkim=r) by default unless strict mode (adkim=s) is specified. In relaxed mode, a signature with d=sub.example.com will successfully align with a visible header of From: [email protected]. But if the signature reads d=shared-relay.net or d=cpanel-server.hosting-company.internal, the cryptographic check passes while DKIM alignment completely fails. Fixing DKIM alignment is typically cleaner and more resilient than fixing SPF alignment, especially when messages pass through automated mail forwarding or distribution lists. When an email is forwarded, the forwarding server's IP will break the original sender's SPF check, causing SPF to fail at the ultimate destination. A correctly aligned DKIM signature, however, survives transit across intermediate relays as long as the email body and critical headers remain unmodified. To fix DKIM alignment for third-party platforms, generate custom DKIM keys within the sending application's settings and publish the corresponding public key records in your authoritative DNS. Once the outgoing server signs messages using your own domain rather than its generic default, the d= tag will match your header.from, satisfying DMARC.

What should you check if headers show alignment passes but mail still bounces?

If you inspect the raw headers of a bounced or rejected test message and confirm that both dkim=pass with proper alignment and dmarc=pass are present, the rejection is stemming from a different tier of receiver policy. Authentication alignment proves identity; it does not guarantee delivery. First, check connection-level hygiene. Mailbox providers like Google and Yahoo require valid Forward-Confirmed reverse DNS (FCrDNS) on the sending IP address. If the IP address delivering your messages lacks a proper PTR record, or if that PTR record does not resolve back to the same IP address via an A record, receivers will reject incoming connections regardless of DMARC passes. You can verify this using the steps outlined in checking forward-confirmed reverse DNS to stop sudden bounces. Second, check receiver-specific requirements such as user complaint rates and unsubscribe mechanisms. For high-volume sending domains, mailbox providers enforce maximum spam complaint thresholds and require machine-readable List-Unsubscribe headers supporting one-click unsubscription. Finally, ensure your domain is not listed on active DNS blocklists (DNSBLs) and that your DMARC policy record itself contains no typographical errors, such as missing semicolons or invalid tags, that might lead a strict parser to discard your policy. When troubleshooting email delivery, jumping straight to re-generating keys or altering DNS records without inspecting headers is often counterproductive. Reading the Authentication-Results header tells you in plain terms whether the issue is a failed mathematical check or a mismatched domain identifier. Once you isolate whether SPF or DKIM is falling out of alignment with your visible From: domain, aligning the corresponding return-path or signing selector resolves the underlying DMARC failure.