How to Find and Fix an Undocumented Mail Relay That Bypasses Gmail Spam Filters

Spam Lands in Gmail Despite Normal Email Security

Gmail is letting spam through from your domain. Your Google Workspace settings look correct. Your email security vendor shows nothing suspicious. Your SPF and DKIM records check out. The mail log shows nothing obviously wrong. Yet you have reports of spam appearing to come from your domain, and no one on your team can explain it.

The explanation is usually an undocumented or forgotten internal mail relay. This is a mail server, script, or automation tool inside your network that was set up years ago by someone who has since left the company. It forwards mail directly to Gmail for delivery, and it carries your domain in the From header. No one documented it. No team owns it. It just keeps running.

This is a real and recurring failure mode. It is not a theoretical risk.

Why the Bypass Happens

The mechanism is straightforward. A mail relay inside your infrastructure receives a message from an internal system and forwards it directly to Gmail for final delivery. Gmail applies its spam filtering when it receives the message. If the relay is not authenticated under your DMARC policy, Gmail may apply different filtering to relay-injected mail than it would to mail submitted through your normal sending infrastructure.

The relay is not malicious. It is simply sending mail on behalf of your domain without the SPF or DKIM credentials that Gmail uses to verify the message originated from your authorized infrastructure. The result is that Gmail's spam filtering operates on the message with less confidence in its origin, which can result in different filtering behavior than your normal mail flow would produce.

This is not a Gmail bug. It is a configuration gap created by an unmaintained relay carrying your domain in the From header without proper authentication.

How to Find the Relay Using DMARC Aggregate Reports

DMARC aggregate reports are the fastest way to find a forgotten relay. These reports show every source that has sent mail using your domain over a reporting period, including sources you do not know about. The report includes the source IP address, the domain being sent from, and the volume of messages.

When reviewing your report, look for these specific signals:

• A source IP address that does not match your known mail infrastructure. This includes office servers, cloud instances, marketing automation platforms, and any other authorized senders.
• A source sending to a narrow, consistent set of recipients, which is typical of automation rather than user-sent mail.
• Sporadic or burst-and-silence sending patterns that do not correspond to any scheduled process your team runs.
• A hostname in the PTR record that points to an internal server you cannot account for.

With DMARCFlow, source IPs are displayed alongside their PTR records and claimed sending domains in a single view. When you see an IP that does not match your infrastructure list, you have found the gap. The report tells you what is sending, even when no one on your current team remembers that the relay exists.

Step by Step: Confirming the Relay

Once an unfamiliar IP appears in your DMARC report as a source for your domain, confirm it before taking any action:

1. Run a PTR record lookup for the IP. Internal relays typically resolve to internal hostnames that do not appear in public DNS records, which itself is a useful signal.
2. Cross-reference the IP or hostname against your internal network documentation, configuration management database, and any recent infrastructure changes.
3. Ask your infrastructure or DevOps team if they recognize the IP or hostname.
4. Before shutting anything down, confirm that no active service depends on the relay for alerts, notifications, or automated reports.

Fixing the Gap

If the relay is still in active use, the fix is to authenticate it properly. Add the relay's IP address to your SPF record. Ensure the relay is aligned with your DMARC policy so Gmail treats its mail with the same confidence as your other legitimate sending sources.

If the relay is not needed, shut it down. Confirm first that no active service depends on it. When the relay is decommissioned, remove its IP from your SPF record. An outdated SPF record is its own problem: it creates ambiguity about what is authorized to send on behalf of your domain.

Preventing the Same Gap in Future

Forgotten relays accumulate over time in organizations where email infrastructure is not treated as a first-class asset. Preventing them requires habits, not tools:

• Document every system that sends mail, including internal scripts, monitoring tools, and one-off automation.
• Assign clear ownership for every relay, even internal ones used only by a single team.
• Include mail-sending infrastructure in your regular audit cycle, not just in annual email security reviews.
• When a system is decommissioned, include its mail relay in the decommission checklist.

Continuous DMARC monitoring catches new relays faster than periodic reviews. When a new source IP appears in your DMARC report without a corresponding change request, that is a signal worth investigating. DMARCFlow monitors your aggregate reports on an ongoing basis and alerts you to new source IPs that do not match your recognized infrastructure, making unknown relays visible before they become persistent gaps.

FAQ

How does a mail relay bypass Gmail spam filters?

A relay that injects mail directly into Gmail without proper SPF or DKIM alignment can receive different spam filtering treatment than mail submitted through your normal sending infrastructure. Gmail applies filtering based on its confidence in the message's origin. A relay carrying your domain without matching authentication may trigger a lower-confidence signal, which can affect how Gmail classifies the message.

Can DMARC reports show me every mail relay in my organization?

DMARC aggregate reports show every source that sends mail using your domain in the From header. This includes direct relays, backend systems, and any infrastructure that sends email using your domain name. Relays that forward through a third-party service rather than sending directly to Gmail may not appear in your report, which is why understanding your full sending architecture matters.

How do I know if a source IP in my DMARC report is a real problem or just noise?

A source representing a real problem typically has one or more of these characteristics: the IP does not match any authorized sender in your infrastructure, it sends to a limited set of recipients, and its PTR record points to an internal hostname you cannot account for. A one-time test by a developer or a legitimate internal system will often be identifiable by context or pattern. When in doubt, investigate the PTR record and ask your infrastructure team.

What is the fastest way to fix a Gmail spam bypass caused by an unknown relay?

If the relay is not needed, shut it down and remove its IP from your SPF record. If it is needed, add its IP to your SPF record and verify it aligns with your DMARC policy. Then monitor your DMARC reports to confirm the unknown source stops appearing and your legitimate mail continues flowing normally.