Why am I seeing a 'via' warning on internal emails and how do I fix it?

Key findings

• Authentication misalignment: The 'via' warning often appears when an email's SPF or DKIM authentication record passes, but the domain used in the 'From' header (the visible sender) doesn't align with the domain that actually sent the email.
• Third-party senders: This is especially common when sending internal emails through a third-party service (e.g., a marketing automation platform, CRM, or IT management tool) that uses its own domain for the actual sending path, while the 'From' address retains your company's domain.
• Spoofing protection: Gmail and other email clients display this warning as a security measure to alert recipients that the email might not be from the claimed sender, even if it's from within the organization, if authentication is not perfectly configured.
• Impact on external emails: While internal 'via' warnings might be overlooked, the same authentication issues will likely cause phishing warnings or spam placements for emails sent to external recipients.

Key considerations

• DMARC policy enforcement: Implement a DMARC policy that aligns both SPF and DKIM for your sending domains. This tells receiving mail servers what to do with emails that fail authentication or alignment.
• SPF record updates: Ensure your SPF record includes all IP addresses or domains authorized to send email on behalf of your domain, including third-party services. An outdated or incomplete SPF record is a common cause of 'via' warnings.
• DKIM configuration: Properly configure DKIM for all sending services. This involves adding the DKIM public key to your DNS records and ensuring the sending service signs your emails with that key.
• Domain alignment: Focus on achieving DMARC alignment, where the domain in the 'From' header matches the domain that passed SPF or DKIM authentication. This is crucial for removing the 'via' warning. More information on email authentication can be found on Mailhardener's DMARC alignment guide.

Key opinions

• Multiple domains and forwarding: Marketers frequently see 'via' warnings when their setup involves multiple domains or email forwarding through services like RMM, which can break standard authentication paths.
• Authentication not fully set up: A common cause cited is incomplete email authentication setup, especially when using platforms like Marketing Cloud or similar ESPs. Even if mail is delivered, the warning persists.
• Google's security feature: Many marketers understand this as a Google-specific security feature designed to warn recipients about potential spoofing, even for internal emails where the sender appears to be a colleague but lacks proper organizational authentication.
• Misconception as a deliverability problem: While the email reaches the inbox, some marketers initially mistake the 'via' warning as a direct deliverability failure, when it is more about authentication integrity.

Key considerations

• Addressing the 'via' for internal emails: If internal emails are triggering 'via' warnings, it indicates a need to review how your subdomains or third-party senders are authenticated.
• Impact on external subscribers: Marketers are concerned about whether this warning affects external subscribers, and indeed, it can lead to emails being marked as spam or blocked if the authentication doesn't meet the sender requirements of major mailbox providers.
• Focus on DMARC compliance: Ensuring DMARC alignment is paramount, as it directly addresses the issue of the 'via' warning and strengthens overall email security and deliverability. This aligns with Google and Yahoo's new sender requirements.
• Authentication standards: Marketers must understand that the 'via' warning is a clear sign that existing authentication (SPF, DKIM, DMARC) does not meet current industry standards for domain alignment, necessitating immediate corrective action to avoid broader email blocklisting or spam filtering.

Key opinions

• Google's warning mechanism: Experts identify the 'via' warning as a Google-specific security feature designed to alert recipients when an email claims to be from an employee but isn't properly authenticated by the company's domain.
• Authentication misalignment: The core issue is authentication misalignment; the 'via' message indicates that the email is authenticated by a third-party domain (e.g., Salesforce, ExactTarget) but the 'From' address does not match this authenticated domain.
• Not a deliverability problem (for inbox placement): Experts clarify that this specific 'via' warning doesn't mean the email failed to deliver to the inbox, but it indicates a trust issue regarding the sender's authenticity.
• Warning for potential spoofing: The warning serves as a protective measure to guard against scammers impersonating internal users. It advises recipients to be cautious and verify the sender before taking action on the email.

Key considerations

• Fixing sending configurations: Even if the email lands in the inbox, experts strongly advise fixing sending configurations to achieve proper DMARC alignment. This prevents external recipients from seeing similar or more severe warnings that could lead to spam folder placement or outright blocking.
• Meet Yahoogle standards: Compliance with the latest Google and Yahoo sender requirements is essential to eliminate 'via' warnings and ensure emails are trusted.
• SPF and DKIM integrity: While the warning indicates DMARC alignment failure, the underlying fix involves correctly implementing and aligning SPF and DKIM records for all legitimate sending sources.
• Understanding the warning: It's crucial for organizations to understand that the 'via' message is a legitimate security alert, not a false alarm, and it signals a weakness in their email setup that could be exploited by malicious actors. More details on unverified emails and future deliverability issues are available.

Key findings

• RFC 5322.From vs. authenticated domain: The 'via' warning appears when the domain in the visible 'From:' header (RFC 5322.From) differs from the domain that authenticated via SPF or DKIM. This misalignment is key to the warning.
• DMARC alignment requirements: DMARC mandates that the organizational domain of the RFC 5322.From address must match the organizational domain of the SPF or DKIM authenticated domain for alignment to pass.
• Security vs. deliverability: The 'via' warning is primarily a security indicator for the recipient, informing them that the email's authenticity is questionable, rather than an outright deliverability failure (i.e., the message is still delivered).
• Policy enforcement: Mailbox providers use this warning as part of their broader anti-spoofing efforts, especially for domains with a 'p=none' DMARC policy that does not instruct receivers to quarantine or reject unaligned mail.

Key considerations

• Configuring DMARC for alignment: To remove the 'via' warning, senders must configure their email infrastructure to ensure DMARC alignment, which may involve updating SPF records to include all sending IPs and configuring DKIM for third-party senders. More information on fixing DMARC issues in Microsoft 365 and Google Workspace is available.
• Subdomain handling: Documentation often advises that subdomains used for sending (e.g., news.yourdomain.com) must also pass DMARC alignment to avoid the 'via' tag when the 'From' header is the organizational domain.
• Reviewing email headers: Analyzing email headers is critical for diagnosing the precise authentication failure that leads to a 'via' warning, by identifying which authentication method (SPF or DKIM) failed alignment. This can be complex, and you might need to fix compauth failure due to domain alignment issues.
• Importance of DMARC reporting: Documentation recommends setting up DMARC reporting (using rua and ruf tags) to gain visibility into which emails are failing alignment and from which sources. This data is crucial for systematic remediation. Official DMARC documentation provides comprehensive details on DMARC overview and implementation.