Skip to main content

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.

  1. 1Original sender
  2. 2Forwarder/gateway
  3. 3SPF/DKIM/ARC results
  4. 4DMARC alignment
Preserve raw headers.

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

ObservationLikely cause / distinctionVerification
SPF fail, DMARC passAligned DKIM succeeds.Verify header.d/header.from alignment.
Only forwarded mail failsSignature modification or envelope differences.Compare raw messages before/after forwarding.

Acceptance checks

  1. Preserve raw headers.
  2. Distinguish SPF identity from From.
  3. Verify DKIM alignment.
  4. Check body modifications.
  5. Inspect ARC trust chains.
  6. 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.

Knowledge Center

Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!