Problem
Alumni Forwarding customers use two distinct mail routing architectures, and the correct settings for SPF Checking and Spam filtering differ between them. Applying the wrong settings when mail is being routed indirectly through a platform like Microsoft 365 or Google Workspace can cause legitimate messages to be rejected or flagged as spam.
The Two Routing Scenarios
- Direct Routing — Your domain's MX records point directly to DuoCircle's Alumni Forwarding servers. Mail from external senders arrives at Alumni Forwarding first.
- Indirect Routing — Your domain's MX records point to Microsoft 365, Google Workspace, or another mail platform first. That platform then relays the message on to Alumni Forwarding via a connector or transport rule.
Recommended Settings
Direct Routing
| Setting | Recommended Value |
|---|---|
| SPF Checking | Enabled |
| Suspect Mail Action | Deliver with Tag |
| Spam Mail Action | REJECT |
This is the standard configuration. Mail arrives at Alumni Forwarding directly from the internet, so SPF/DKIM/DMARC checks are valid and meaningful.
Indirect Routing (via M365, Google Workspace, or similar)
| Setting | Recommended Value |
|---|---|
| SPF Checking | Disabled |
| Suspect Mail Action | Your preference |
| Spam Mail Action | Your preference |
Why SPF Checking Must Be Disabled for Indirect Routing
The SPF Checking setting controls SPF, DKIM, and DMARC validation. When mail passes through an upstream platform before reaching Alumni Forwarding, two problems make these checks unreliable:
1. SPF will fail.
SPF validates the IP address of the sending server. When M365 or Google Workspace relays a message to Alumni Forwarding, the connecting IP is theirs — not the original sender's. Neither platform is guaranteed to perform Sender Rewriting Scheme (SRS) on all forwarded mail, so the original sender's SPF record may not authorize the relay IP. Alumni Forwarding will see an SPF failure on otherwise legitimate mail.
2. DKIM may fail for messages containing URLs.
Some security products rewrite URLs inside message bodies to route clicks through a threat-scanning service. This modification happens after the original sender signed the message with DKIM, and any change to the message body invalidates the original signature. Common products that rewrite URLs include:
| Product | Rewritten URL domain |
|---|---|
| Microsoft Defender Safe Links | *.safelinks.protection.outlook.com |
| Proofpoint URL Defense | urldefense.proofpoint.com |
| Mimecast URL Protect | protect-us.mimecast.com |
| Barracuda Link Protect | linkprotect.cudasvc.com |
| Google Workspace (Security Premium / Chrome Enterprise) | *.google.com/url?... |
M365 with Safe Links enabled rewrites essentially every URL in every message, making DKIM failures near-universal.
Google Workspace URL rewriting is less common and depends on the security edition and configuration, but third-party security gateways used in front of Google Workspace (Proofpoint, Mimecast, Barracuda, etc.) behave the same as Safe Links.
Since your upstream platform already performed SPF/DKIM/DMARC validation when mail arrived at their servers, repeating those checks at the Alumni Forwarding layer is redundant and will produce false failures.
Related Articles
- Routing Office 365 via Transport Rule for Email Forwarding
- Route Unknown G Suite Users for Alumni Forwarding
- Split Delivery to Existing Mailbox AND Alumni Forwarding — Google Workspace
- Route a Group to Alumni Forwarding (Split Delivery by Group Membership) — Google Workspace
- Message modification like adding 'External' banners will break DKIM