Why do internal emails show a 'via' warning?

The 'via' warning appears when the domain in the email's 'From' header (what you see) does not align with the domain that authenticated the email (via SPF or DKIM). This usually happens when a third-party service sends emails on your behalf without proper DMARC alignment. It's a security feature designed to alert recipients to potential discrepancies in the email's origin, even if the email itself is legitimate. You can learn more about removing the 'via' message for subdomains .

Does a 'via' warning mean the internal email is dangerous?

No, the 'via' warning itself does not mean the email is malicious. It indicates a lack of DMARC alignment, which is a security concern because it makes it harder to verify the email's authenticity. While legitimate emails can show this warning due to misconfiguration, it's also a common indicator of phishing attempts. Recipients should exercise caution with any email displaying such a warning.

How do I remove the 'via' warning from internal emails?

To fix it, you need to achieve DMARC alignment. This involves configuring your SPF and DKIM records so that the domain used for authentication matches your 'From' header domain. For third-party senders, this means ensuring they are authorized in your SPF record and that their DKIM signatures are tied to your domain. You may also need to adjust your DMARC policy from 'p=none' to 'p=quarantine' or 'p=reject' once alignment is established for all legitimate senders. Consider using DMARC monitoring to track progress.

What is the role of DMARC reports in resolving this issue?

DMARC reports provide valuable insights into your email authentication status. They show which emails are passing or failing SPF/DKIM and DMARC alignment checks. By analyzing these reports, you can identify legitimate sending sources that are causing 'via' warnings due to misalignment and take steps to correct their configuration. This also helps in detecting and mitigating unauthorized email senders. This helps avoid issues like DMARC verification failed errors .

Can third-party email senders cause 'via' warnings on internal emails?

Third-party services, like email marketing platforms or CRM systems, often send emails on your behalf. If their sending infrastructure isn't configured for DMARC alignment with your domain, they can cause 'via' warnings. You need to work with these providers to ensure their setup aligns with your domain's SPF and DKIM records, allowing DMARC to pass alignment checks. This is particularly relevant for marketing or transactional emails that still appear internal.

Why am I seeing a 'via' warning on internal emails and how do I fix it? - Troubleshooting - Email deliverability - Knowledge base

Seeing a 'via' warning on internal emails can be confusing, especially when you expect messages from colleagues to appear without any flags. This warning, often displayed by email clients like Google or Microsoft Outlook, indicates a discrepancy between the apparent sender and the actual sending server. While it doesn't always mean a message is malicious, it can signal an underlying email authentication issue that needs attention.

For internal emails, these warnings are typically a security measure designed to protect your organization from spoofing and phishing attempts. Even if the email seems to be from a trusted internal source, the 'via' tag suggests that the email didn't originate directly from your expected domain or mail server, which can raise flags. Understanding the root cause is crucial for maintaining trust and ensuring secure internal communication.

Understanding the 'via' warning on internal emails

The core reason you're seeing a 'via' warning on internal emails is typically related to email authentication alignment. When an email client displays a 'via' tag, it's usually because the email's 'From' address domain differs from the domain that actually authenticated the email, often through SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail). Even if the email originates within your organization, if it passes through a third-party service for sending or forwarding, this can trigger the warning.

A common scenario is when you use an external email service provider (ESP) or a marketing automation platform to send internal communications. While these services are legitimate, they often send emails on behalf of your domain. If your email authentication records, particularly DMARC (Domain-based Message Authentication, Reporting, and Conformance), are not configured to align the sending domain with your organization's domain, the 'via' warning will appear. This is a deliberate design feature of email systems like

Gmail to alert recipients about potential spoofing, even if the sender is technically legitimate.

This isn't necessarily a deliverability problem in the sense that the email isn't reaching the inbox. Instead, it's a flag about the email's perceived authenticity. The mail is delivered, but the 'via' tag serves as an important security notice to the recipient, encouraging caution. It indicates that while the email claims to be from a coworker, the underlying authentication doesn't fully confirm its origin from your company, making it harder to ensure it's not a forgery. Understanding why Gmail shows 'via' even when DMARC passes is essential.

The role of email authentication

Email authentication protocols like SPF, DKIM, and DMARC are crucial for verifying sender identity and preventing spoofing. SPF specifies which mail servers are authorized to send email on behalf of your domain, while DKIM provides a cryptographic signature that verifies the email content hasn't been tampered with in transit. DMARC, then, builds upon these by defining how receiving mail servers should handle emails that fail SPF or DKIM checks, and it also dictates whether the 'From' domain in the email header aligns with the SPF and DKIM domains.

For the 'via' warning to disappear, your DMARC record must be configured correctly, and the domain used in the 'From' header (the visible sender) must align with the domain authenticated by SPF or DKIM. If your organization uses multiple subdomains or third-party senders, ensuring this alignment can become complex. The 'via' message suggests that this alignment is not happening, even if SPF or DKIM technically pass for the underlying sending domain.

This situation often arises when a third-party service sends emails using their domain in the technical 'bounce' or 'return-path' address (for SPF) or signs the email with their DKIM key, but your corporate domain appears in the 'From' header. While this is common practice for legitimate services, it causes the visible 'From' domain to not align with the authenticated domain, leading to the 'via' warning. To prevent these warnings, it's vital to ensure that your DMARC, SPF, and DKIM records are set up for proper alignment.

Understanding DMARC alignment

DMARC alignment is key. It checks if the domain in the "From" header (what users see) matches the domain used for SPF authentication (the return-path domain) or DKIM authentication (the d= domain in the signature). If these domains do not match, even if SPF or DKIM pass, the DMARC alignment will fail, triggering the 'via' warning.

Troubleshooting and solutions

Resolving the 'via' warning for internal emails primarily involves ensuring proper DMARC alignment for all your sending sources. This means configuring your third-party email service providers to send emails on behalf of your domain in a way that aligns with your DMARC policy. The first step is to identify all services that send email using your domain, especially those used for internal communications or forwarded messages.

Once identified, you'll need to configure SPF and DKIM records for each of these senders on your domain's DNS. For SPF, ensure that the IP addresses or hostnames of your third-party senders are included in your SPF record. For DKIM, the third-party sender typically provides you with a CNAME record to publish, which allows them to sign emails on your behalf. The goal is to ensure that the domain used for SPF and DKIM authentication matches your organization's primary domain, which is visible in the 'From' header.

It's also important to review your DMARC policy. If your policy is set to `p=none` (monitoring only), you might still see the 'via' warning even if authentication passes, because the alignment check is stricter for higher policies like `p=quarantine` or `p=reject`. To eliminate the 'via' warning entirely, your DMARC policy should eventually be set to at least `p=quarantine` with proper SPF and DKIM alignment in place. This will also help prevent Gmail from marking internal emails as potentially dangerous.

Current state

Email is sent from a third-party service (e.g., Salesforce Marketing Cloud, Mailchimp) using their sending domain for SPF/DKIM authentication, but with your primary domain in the 'From' header. This causes a DMARC alignment failure.

Visibility: Recipients see a 'via' warning (e.g., 'sender@yourdomain.com via salesforce.com') on internal emails.
Trust: Internal users may question the legitimacy of the email, despite it being valid.

Desired state

Email is sent from a third-party service, but SPF and DKIM are configured to align with your primary domain, ensuring DMARC passes alignment checks.

Visibility: The 'via' warning is removed, and emails appear to come directly from your domain, e.g., 'sender@yourdomain.com'.
Trust: Internal users have full confidence in the authenticity of the message.

Here's an example of a DMARC record that could help achieve alignment and remove the 'via' warning. Remember that deploying DMARC should be done carefully, starting with a relaxed policy and gradually tightening it.

Example DMARC record for alignmentDNS

v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; adkim=s; aspf=s;

The adkim=s and aspf=s tags in this example specify "strict" alignment. Strict alignment means the domain in the 'From' header must exactly match the domain authenticated by DKIM or SPF. This is generally what's needed to remove the 'via' tag. Be sure to replace yourdomain.com with your actual domain and adjust reporting email addresses as necessary.

Views from the trenches

Best practices

Ensure SPF records include all legitimate sending IP addresses, including third-party senders.

Implement DKIM for all email sending services and verify that the d= tag in the DKIM signature matches your domain.

Deploy DMARC with a policy of p=none first, monitoring reports to identify unaligned senders.

Gradually transition your DMARC policy to p=quarantine or p=reject for stronger protection.

Regularly review your DMARC reports to detect and address any new sending sources or alignment issues.

Common pitfalls

Forgetting to include all authorized third-party senders in your SPF record, leading to SPF failures.

Incorrectly configuring DKIM records, resulting in signature mismatches and authentication failures.

Setting a DMARC policy too aggressively (e.g., p=reject) without first monitoring its impact.

Not regularly checking DMARC reports, which can hide emerging alignment or authentication problems.

Assuming that SPF or DKIM passing means DMARC alignment is also passing, which is not always true.

Expert tips

Always start DMARC with a 'p=none' policy to gather data without impacting email delivery.

Utilize a DMARC monitoring tool to simplify report analysis and quickly identify alignment issues.

Communicate DMARC changes internally to IT teams and email senders to ensure smooth transitions.

Prioritize fixing DMARC alignment for high-volume or critical internal communication channels.

Consider using a subdomain for marketing emails to isolate potential deliverability issues.

Expert view

Expert from Email Geeks says that the 'via' warning is a Google feature designed to inform employees that an email claiming to be from a colleague is not fully authenticated by the company's domain, even if it is delivered to the inbox.

2024-05-07 - Email Geeks

Marketer view

Marketer from Email Geeks says that 'via' warnings occur when multiple domains are set up and emails are bounced back and forth between them, or when authentication isn't fully configured, for instance, in a marketing cloud setup.

2024-05-07 - Email Geeks

Strengthening internal email security

Eliminating the 'via' warning on internal emails is a critical step in enhancing your organization's email security and maintaining user trust. While the warning itself doesn't prevent email delivery, it signals an authentication gap that could be exploited by malicious actors attempting to spoof internal identities. By ensuring that your SPF, DKIM, and DMARC records are correctly configured for all sending sources, including third-party platforms, you strengthen your email's authenticity.

Addressing these authentication issues helps not only with internal email presentation but also contributes to your overall domain reputation, which is crucial for external email deliverability. A robust email authentication setup means clearer communication, reduced risk of phishing attacks, and a stronger email ecosystem for your entire organization. Regularly monitoring your DMARC reports is essential to keep these systems robust and effective.