Ordinary Adobe Workfront notifications use notifications@my.workfront.com as their visible From address, even when the display name identifies a colleague. They are not customer-domain messages simply because your organization uses Workfront. For this route, start by verifying the actual message and its provider-managed authentication, not by adding a Workfront include to your company's root SPF record.
Adobe's current email-allowlist documentation identifies that sender for automated alerts and user-to-user communication. This guide covers those standard notifications only. It does not cover standalone Workfront Proof, a custom integration sending through another service, or every Adobe product.
No customer account, DNS configuration or delivered message was tested for this guide.
On this page: What this guide can establish · Distinguish current behavior from the 2020 change · Identify the message before investigating DNS · Interpret SPF, DKIM and DMARC separately · Make receiver-result trust operational · Why copying the Workfront SPF example is not the answer · Diagnose a missing or failed notification · Use a harmless acceptance check · Preserve DNS and report privacy · Frequently asked questions
What this guide can establish
Use this diagnostic when a Workfront notification is missing, quarantined, unexpectedly authenticated, or mistaken for an email from your own domain. You need permission to inspect the relevant Workfront context and receiving-mail logs, plus an approved recipient for any controlled test. Reading a public guide does not authorize changing either system.
| Question | Answer for this route |
|---|---|
| Do I obtain a customer-domain DKIM key in Workfront? | The reviewed instructions do not establish that workflow for ordinary notifications. Do not invent a selector or DNS record. |
| Is a colleague's display name the authenticated identity? | No. Inspect the address inside the From field and the signature's domain. |
| Does my company's SPF authenticate this notification? | Not automatically. SPF evaluates the actual SMTP envelope identity, not the colleague's name or your subscription domain. |
| Does a receiver allowlist turn failed authentication into a valid signature? | No. An exception changes handling, not the cryptographic result. |
| Is Workfront Proof included? | No. Establish its separate sending route before applying instructions. |
The goal is an accurately identified, provider-signed notification with receiver evidence, not a fabricated customer-domain setup. If your requirement is that notifications visibly originate from your own domain, this documented route does not establish that outcome. Ask Adobe to confirm a supported product-specific alternative before planning a migration or DNS change.
Distinguish current behavior from the 2020 change
Adobe introduced the fixed notification sender in the 20.3 release, available in the week of 10 August 2020. The release notes also announce DKIM on outgoing Workfront messages. Their September 2026 page-update date does not make this a new 2026 migration. See the historical 20.3 email changes and DKIM announcement.
The accompanying spoofing and POP-reply announcement explicitly separates messages coming directly from Workfront Proof. It also describes removal of the old custom POP-reply option. Neither historical change is a reason to reconfigure a current mailbox, forward replies elsewhere, or assume Proof uses the standard notification identity.
Use the current sender documentation to classify ordinary messages; use the historical release material to explain why older instructions about a custom From may no longer fit. Neither document supplies a universal current DKIM selector, signing domain or envelope sender for you to paste into DNS. Those identities must come from the actual message and, if uncertain, Adobe's confirmation of the route.
Identify the message before investigating DNS
Collect the minimum evidence needed from an approved notification or a controlled synthetic test. Avoid uploading complete project discussions, attachments or recipient lists to public header-analysis services.
- Confirm that the message was generated by ordinary Workfront notifications, rather than standalone Proof, an integration, a forwarding rule or another Adobe application.
- Record the visible From address separately from its display name. A familiar colleague name beside the documented provider address is not evidence of customer-domain sending.
- Record the actual Reply-To separately if present. It controls replies, not DMARC alignment. Do not reply merely to test authentication: some notification replies can become Workfront comments.
- Have the receiving-mail administrator identify the SMTP MAIL FROM, relevant delivery hops and receiver-generated authentication results. A displayed Return-Path can help, but interpret it within the real received route rather than assuming a fixed Workfront value.
- Identify each DKIM signature's
d=signing domain ands=selector. Multiple signatures can coexist. Determine which belongs to the intended Workfront delivery path before treating a passing signature as success.
Keep UTC time, a safe message identifier and the relevant receiving log reference. Do not publish full headers containing personal addresses, internal hosts or project details. If the visible sender differs from the documented standard address, stop and identify the route rather than forcing this diagnostic onto it.
Interpret SPF, DKIM and DMARC separately
SPF: the receiving server evaluates authorization for the SMTP MAIL FROM domain, or HELO in applicable cases. A pass says something about that evaluated identity. It does not by itself authenticate the address a person sees in From. This distinction is defined by RFC 7208.
DKIM: a passing signature establishes verification under its signing domain. For this diagnostic, require the intended Workfront signature to pass and align with the actual approved provider From. A valid unrelated signature is not enough to validate the intended signing path. Adobe's historical DKIM announcement is documentary evidence of the feature, not a substitute for checking today's message.
DMARC: alignment connects an authenticated SPF or DKIM identity to visible From. Under relaxed alignment, the relevant domains share an Organizational Domain; under strict alignment, the domains must match exactly. Compare DKIM d= under adkim, and SPF's authenticated MAIL FROM domain under aspf. A child envelope domain is not automatically a strict match. Use the effective policy and actual identities rather than assuming Adobe's alignment mode or Return-Path. See RFC 9989.
A trusted dmarc=pass through SPF alone does not prove the intended DKIM signature works. Conversely, aligned DKIM can permit DMARC to pass while SPF has a separate failure that still needs diagnosis. EmailAuth's raw DKIM results versus aligned DKIM policy results explains why these are separate questions.
Authentication also does not prove that the content is safe, that the named colleague intended it, or that every downstream recipient will place it in the inbox.
Make receiver-result trust operational
Ask the receiving-mail administrator which service actually generated the authentication assessment and how its processing boundary handles externally supplied Authentication-Results fields. Use results generated inside that known receiving boundary, corroborated by its documented behavior and message trace or logs.
Do not trust a field merely because it is near the top of the headers or contains a familiar authserv-id. An attacker can insert convincing-looking result text before delivery. Ignore externally supplied or otherwise untrusted assertions; do not combine a real result for one message or hop with an unrelated signature. RFC 8601 describes the trust-boundary considerations for Authentication-Results.
Where a gateway forwards or modifies the message, establish which hop checked which version. A downstream failure may have a different cause from failure at first receipt. Preserve the actual path in the diagnostic rather than immediately changing DNS or disabling a gateway control.
Why copying the Workfront SPF example is not the answer
Adobe's SPF troubleshooting page discusses spf.workfront.com alongside firewall and filter allowlisting. Its example separates include: from its domain with whitespace. Do not paste that malformed syntax or interpret the firewall discussion as a complete customer-domain authentication recipe.
For the standard provider-From route, adding an authorization to your company's SPF cannot change the signature domain, change visible From, or repair Adobe's own DNS. First establish which domain was actually evaluated and who controls it. If the failed owner is provider-controlled, send the diagnostic evidence to Adobe through an approved support process.
This guide intentionally supplies no replacement SPF record. If investigation establishes a different, authorized customer-controlled sending route, its owner needs a separate reviewed change plan. That plan must preserve one v=spf1 TXT policy per evaluated owner, legitimate existing senders and intended qualifiers. SPF has a limit of ten evaluated DNS-dependent terms, including nested evaluation, not merely ten include strings. An all mechanism causes redirect to be ignored. Qualifiers do not guarantee a recipient's delivery decision. These constraints are relevant to avoiding a harmful repair, not permission to change a record here.
Do not delete an existing Workfront-related authorization solely because it appears unnecessary to this notification. Another verified legacy or separate sending path may still depend on it. Inventory that dependency first.
Diagnose a missing or failed notification
| Observation | Next bounded investigation |
|---|---|
| No message appears in receiving logs | Confirm generation, intended recipient and relevant Workfront restrictions with the responsible administrator. Do not assume SPF caused a message that never reached the receiver. |
| SPF fail | Identify the evaluated owner and source IP. Confirm route applicability and responsible operator before proposing an authorization change. |
| SPF temperror | Investigate the temporary DNS or evaluation failure; do not add another policy as a workaround. |
| SPF permerror | Inspect the evaluated policy for structural or lookup-budget defects. Provider-owned defects require the provider, not edits to your unrelated domain. |
| Intended DKIM fails | Check the exact signature, selector lookup, receiving trace and intervening modification. Do not generate a customer key to replace a provider signature. |
| DKIM passes but does not align | Reconcile the intended signature's domain with actual From and effective alignment mode. Another passing signature or SPF-only DMARC pass does not close this issue. |
| Authentication passes but mail is quarantined | Review the receiver's actual policy or content reason. Authentication success does not override every security control. |
| From is your own domain | Identify a different workflow or unexpected identity; do not count it as the documented standard route without confirmation. |
Workfront's own email-domain allowlist concerns allowed recipient/profile domains and data-sharing restrictions. It is not a customer DKIM activation control. The current documentation's feature and access descriptions also should not be generalized into a universal entitlement for every account. Have the authorized administrator inspect applicable settings without adding domains, changing recipient permissions or broadening disclosure simply to make a test arrive.
A receiver-side safe-sender exception likewise is not an authentication repair. This guide does not instruct you to disable spam filtering, bypass inspection, allowlist Workfront globally or change your organization's security policy.
Use a harmless acceptance check
Use an existing approved synthetic notification where available. Otherwise have the Workfront owner identify an authorized, harmless notification path with a controlled recipient and no real project data. There is no universal test-button procedure established by the sources used here. If generating a message requires a real task change, approval request, comment, invitation or reply, stop and obtain an appropriate test plan rather than causing that side effect casually.
Acceptance for this diagnostic requires all of the following:
- The message came through the intended ordinary Workfront path and retained the documented, approved provider From.
- The receiving system's trustworthy assessment shows the intended provider DKIM signature passing and aligned with that From under the effective policy.
- Trusted receiver DMARC passes; SPF's actual outcome is recorded and any fail, temperror or permerror is investigated separately.
- Delivery handling and recipient authorization are understood, without weakening controls to manufacture success.
- The result is labeled provider-domain notification authentication, not authentication of your organization's own From domain.
Record actual observations, not expected values copied from a guide. A missing signature, unexplained rewrite or unsupported testing path leaves acceptance incomplete. A successful sample establishes that sample and route, not all notifications, future key rotations or every receiver.
Preserve DNS and report privacy
No DNS publication is required by this diagnostic. Preserve your existing SPF, DKIM selectors, delegations, direct and inherited DMARC policies, and authorized report destinations. Do not add a monitoring record or reduce enforcement in response to an unrelated provider-domain notification.
If a separate approved investigation considers aggregate reporting, compare the Organizational Domain of the reporting URI destination host with the Organizational Domain of the domain where the DMARC policy was found, including an inherited policy. When they differ, the report-generating receiver checks DNS authorization; the same-Organizational-Domain exception applies when they match. See RFC 9990 section 4. That protocol check does not replace the domain owner's privacy decision about sharing report data. This guide does not authorize a new reporting recipient.