Documentation

IP Authentication Override

Overview

IP Authentication Override allows you to override SPF authentication failures caused by known, trusted sending infrastructure, particularly in environments with complex or hybrid mail routing.

In certain configurations (e.g., on-prem → cloud → on-prem), legitimate internal messages may fail SPF because the sending IP is not included in public DNS records.

This can lead to:

  • incorrect authentication failures in Sublime
  • misclassification of internal messages as Inbound
  • unintended detections or automations

IP Authentication Override resolves this by allowing you to explicitly trust specific sending IPs without modifying SPF records.

How It Works

During message processing:

  1. Sublime evaluates SPF based on the sending IP and domain
  2. If SPF fails due to an untrusted sending IP
  3. Sublime checks if that IP is listed in IP Authentication Override
  4. If matched:
    • SPF result is overwritten to pass
    • Message proceeds through normal classification and detection

This enables:

  • correct classification as type.Internal (instead of type.Inbound)
  • avoidance of false positives caused by authentication failure

Important Behavior

IP Authentication Override:

  • does not bypass detection or remediation
  • does not skip rules or automations
  • only modifies the SPF authentication result

All other signals (content, links, behavioral detections) remain unchanged.

Why This Exists

SPF requires publishing authorized sending IPs in DNS. However:

  • SPF records are public
  • some organizations consider internal IPs sensitive
  • hybrid routing can introduce intermediate hops that break SPF

These factors can cause legitimate mail to fail authentication.

IP Authentication Override provides a controlled alternative without requiring DNS changes.

Supported Use Cases

Internal Mail Relay

  • On-prem → cloud provider → back to on-prem
  • Internal relay IP not included in SPF
  • Messages incorrectly fail SPF

→ Add relay IP to IP Authentication Override

Hybrid Email Infrastructure

  • Combination of on-prem + cloud mail systems
  • Routing introduces SPF failures on internal traffic

→ Trust internal relay or gateway IPs

SPF Privacy Constraints

  • Customer does not want to expose internal IPs in public DNS

→ Use IP Authentication Override instead of modifying SPF

Temporary Migration State

  • SPF not yet updated during infrastructure changes

→ Use as a temporary mitigation

Classification Impact

Without IP Authentication Override:

  • SPF fail → message treated as type.Inbound

With IP Authentication Override:

  • SPF overridden to pass

    → message can be correctly treated as type.Internal

Limitations

Per-Hop SPF Behavior

  • Applies only to the evaluated sending IP
  • Does not override SPF failures from earlier hops

SPF Scope

  • Only affects SPF
  • Does not modify:
    • DKIM
    • DMARC
    • ARC

Risks

Shared Infrastructure (High Risk)

Do not add IPs from:

  • Google
  • Microsoft
  • AWS
  • Salesforce

These are shared environments and may introduce false negatives.

Large CIDR Ranges

Broad ranges may:

  • include IPs you do not control
  • weaken authentication signals

Best Practices

  • Only add IPs you fully control
  • Use narrow IP ranges
  • Treat this as a targeted override, not a general trust mechanism
  • Periodically review configured IPs

Updated 21 days ago