Establish what the security service does in your route
A Perception Point name in a mail-security console does not establish that the service originates your organization’s messages or signs them with your domain. Begin with the integration that is actually deployed. Identify the mailbox platform, inbound scanning method, outbound scanning scope and any separate SMTP relay. This article provides a route-identification and verification method. The available first-party evidence does not establish a universal Perception Point SPF include or customer-domain DKIM setup.
The current WP documentation on docs.perception-point.io is branded FortiMail Workspace Security. Its Microsoft 365 outbound onboarding page describes outbound scanning through a Microsoft 365 API connection, added to an existing inbound integration. That documented function is security inspection, not evidence of a new SMTP sending identity. Confirm that these product instructions apply to the deployment before using their controls.
Draw the route and assign each responsibility
Create a short flow from the application or mailbox to the final recipient. For each component, record whether it generates the message, submits SMTP, relays SMTP, signs DKIM, scans a copy or makes a recipient-side delivery decision. Ask the platform owners to supply configuration evidence rather than relying on a product logo in an email footer.
Separate at least three questions. Which system transmits the message to the recipient? Which domain signs it? Which security service inspects it? One product may perform more than one role, but those roles must be demonstrated. If the message is ordinary Microsoft 365 outbound mail observed through an API, do not add a gateway’s unrelated inbound IP range to your sender policy simply because the gateway protects the tenant.
Also distinguish organization-generated messages from notifications generated by the security service itself. A report or alert sent by the product may use a different sender and route from an employee’s email. Do not use an alert’s headers as proof of authentication for business correspondence, or the reverse.
Interpret scan evidence within its limits
For the documented Microsoft 365 route, the provider describes checks for enabled outbound scanning and an Outbound connection scope, with results visible in the Scans page. It states that outbound scanning does not block outgoing messages or provide outbound quarantine. The onboarding procedure also warns that selected scope can affect existing scanning configuration. Have the security administrator review that scope before changing anything.
Those observations can establish that a message was scanned within a named integration. They do not establish SPF authorization, a valid DKIM signature or DMARC alignment at an external receiver. Keep scan results and receiver results in separate evidence fields so that a clean verdict does not become a substitute for authentication.
The verdict-header documentation says the listed X-PERCEPTION-POINT headers are not added by Microsoft 365 or Google Workspace API scanning and are not added to outgoing emails. Their absence is therefore not, by itself, proof that outbound scanning failed. Their presence on some other message also does not turn them into an external recipient’s DMARC decision.
Configure the actual sender only after identification
Once the SMTP sender and signing service are known, use that service’s applicable first-party configuration procedure. Obtain its issued domain records and activation evidence. If a verified deployment really uses an additional outbound relay, request the relay’s current domain-authentication and signing instructions for that tenant rather than extrapolating from the inbound security guide.
SPF authorizes the applicable SMTP identity and has record-selection and DNS-lookup constraints under RFC 7208. DKIM identifies a signing domain and selector under RFC 6376. DMARC relates a passing authenticated identity to the visible From domain under RFC 9989. An IP allowlist, API consent or successful threat scan is not a substitute for those checks.
Avoid broad allowlisting as a diagnostic shortcut. It can change local security treatment while obscuring the original failure. If the issue is a receiver rejection, preserve the rejection code, time, intended recipient system and a redacted message identifier. If the issue is security coverage, examine the scan scope and matching scan record. Resolve the specific failure instead of treating every delivery problem as an SPF change request.
Perception Point deployment worksheet
Complete this worksheet before proposing authentication records:
- Product name shown in the tenant and contract: ____; applicable documentation: ____.
- Mailbox platform, tenant and deployment region: ____.
- Inbound integration method: ____; outbound scanning method and scope: ____.
- Message-generating application and owner: ____; SMTP sender or relay: ____.
- DKIM signing service and owner: ____; evidence connecting it to the route: ____.
- Notification versus business-message classification: ____.
- Controlled test Message-ID and UTC time: ____; corresponding scan record: ____.
- External receiver, visible From and envelope domain: ____.
- DKIM d= and s=: ____; trusted SPF, DKIM and DMARC results: ____.
- Proposed DNS change and actual sender’s source: ____; unsupported assumptions: ____.
- Pilot decision, recovery owner and human reviewer: ____.
If the SMTP sender or signing owner is unknown, the worksheet is not ready for a DNS change. Continue read-only investigation and ask the responsible administrator for the missing route evidence.
Fictional diagnosis of missing verdict headers
Fictional example only: Summit Design enables outbound API scanning and sends a controlled message. Its administrator sees no X-PERCEPTION-POINT verdict header and assumes the message bypassed protection. The documented header limitation explains why that expectation is unsuitable for this route. The team checks the message’s matching scan entry for security coverage, then separately examines the external receiver’s authentication results for the actual mailbox sender.
Adding security-service IPs to the organization’s SPF policy would not answer either question without evidence that those IPs transmit the outbound message. The team leaves DNS unchanged while it confirms the route. No Summit deployment, scan console, DNS zone or received message was tested for this manuscript.
Scope and remaining gates
The original broad sender-configuration topic remains on hold. This candidate identifies the boundary between documented scanning and unverified customer-domain sending capabilities; it does not claim those capabilities are universally absent. Actual product applicability, routing and signing ownership, tenant-issued instructions where relevant, live scan and receiver evidence, rendered review, human SME approval and publication remain pending.
Record the scope effect before editing scanning
For the documented Microsoft 365 API integration, the provider warns that a new selection of domains, groups or users replaces the existing inbound, internal and outbound scope. With an existing inline inbound integration, the selection affects outbound coverage only. Treat this as a security coverage decision requiring its owner, not an authentication fix.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.