Troubleshooting · Business Email and Collaboration
Forwarded-Mail DMARC Failures: SPF, DKIM and ARC
Forwarding exposes a new sending IP and can break SPF. DKIM may survive if signed content is unchanged. DMARC requires alignment of visible From with a passing SPF or DKIM identity;…
Technical review:
Architecture and operating model
Forwarding exposes a new sending IP and can break SPF. DKIM may survive if signed content is unchanged. DMARC requires alignment of visible From with a passing SPF or DKIM identity; independent pass results alone are insufficient.
A footer-adding gateway or mailing list can break DKIM. ARC can preserve intermediate authentication results, but not every ARC chain is trusted. Diagnose actual headers in Workspace/Microsoft 365 instead of treating permanent p=none as a fix.
- 1Original sender
- 2Forwarder/gateway
- 3SPF/DKIM/ARC results
- 4DMARC alignment
Design parameters
- Header chain
- Read Received, Authentication-Results, DKIM d= and visible From in the raw message.
- Envelope sender
- SRS can change envelope behavior in forwarding but does not automatically solve DMARC alignment.
- ARC trust
- Check chain validation and trusted-sealer scope in service documentation.
Worked example
For From alice@example.test and DKIM d=example.test, forwarding may fail SPF when the new IP is unauthorized. Unchanged aligned DKIM can still satisfy DMARC. If the gateway modifies signed content, DKIM can fail; compare both delivered headers/bodies.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| SPF fail, DMARC pass | Aligned DKIM succeeds. | Verify header.d/header.from alignment. |
| Only forwarded mail fails | Signature modification or envelope differences. | Compare raw messages before/after forwarding. |
Acceptance checks
- Preserve raw headers.
- Distinguish SPF identity from From.
- Verify DKIM alignment.
- Check body modifications.
- Inspect ARC trust chains.
- Retest without weakening policy.
Related concepts
DNS caching and dependencies
DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
TLS and certificate validation
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.