Teamwork.com’s documented project-notification route uses provider-owned email identities. Its support guide says mail is sent through SendGrid, signed with DKIM using DNS entries on teamwork.com, and authorized through SPF entries on teamwork.com. It also places the From and Reply-To addresses on that domain. This is not a customer-domain SPF or DKIM setup procedure. Adding SendGrid to your company’s SPF record is not the documented repair for a missing Teamwork.com notification.
This guide explains the supported notification checks, administrator logs and message evidence that help distinguish an application problem from filtering or authentication failure. It covers Teamwork.com project notifications, not Teamwork Desk, unrelated Teamworks products, customer-managed SMTP, or a custom-branded sending feature. Those routes need their own product-specific evidence.
What you can configure, and what belongs to Teamwork.com
The official Resolve Email Notification Issues article identifies smtp.sendgrid.net as the sending infrastructure. That is descriptive evidence, not an instruction to create a SendGrid account, replace your SMTP service or obtain credentials.
For this route, responsibilities are different:
- Your notification preferences: check whether the notification bell is muted. The vendor says muting also prevents push and email notifications.
- Your site administrator: inspect the failed-email log and establish which intended recipients were affected.
- Your receiving-mail administrator: investigate acceptance, rejection, quarantine, filtering and the trustworthiness of authentication results.
- Teamwork.com: investigate its sending service, provider-domain SPF and DKIM, and any provider-side suppression or signing problem.
The documented route does not issue a customer TXT record, selector, public key, CNAME, custom Return-Path or DNS verification token. Do not manufacture one from a generic SendGrid tutorial. Your company’s unrelated mailbox, marketing and billing senders retain their existing DNS and policies.
The source describes the notification route; it does not establish that every other Teamwork product or commercial arrangement lacks custom-domain functionality. If a different feature is your objective, ask for the current instructions for that exact product and account before making changes.
Identify the missing notification before touching DNS
Start with a specific event, intended recipient and time, including the time zone. Establish that the event should have generated an email under the user’s actual notification preferences. An event visible in the application does not by itself prove that an email was submitted.
Check the bell’s mute state. If notifications were intentionally muted, restoring them is a user preference decision, not an authentication repair. Record the previous state before an authorized change so it can be restored. Do not toggle unrelated project permissions or notification settings simply to produce traffic.
Next, check the recipient address actually associated with the event and examine spam, junk and quarantine locations through the receiving service. A typo, disabled mailbox or suppressed notification can produce the same “nothing arrived” complaint as a rejected email, but each requires a different response.
The vendor’s troubleshooting page suggests an alternative personal mailbox test. Do not silently change a user’s account email to a personal address: that can affect identity, access and where project information is sent. Prefer an owner-approved test account and controlled recipient already authorized to receive the selected project notification. If an account-address change is genuinely needed, obtain the account owner’s explicit approval and plan restoration first.
Open the failed-email log with the correct role
Only site administrators in the owner company can access the site settings used here. The current Viewing Failed Email Logs instructions give this sequence:
- Click the profile icon in the top-right corner of the Teamwork.com site.
- Select Settings.
- Open the Email tab.
- Find Failed Log and click View Logs.
- Hover over the Detail field to see the associated recipient, sender and subject.
The vendor screenshots show the Email tab and Failed Log / View Logs control. They are not a DNS administration screen and do not show a DKIM activation switch.
Record only the incident details needed for the investigation. Log subjects and recipient addresses can expose project or personal information; avoid copying unrelated entries into a support ticket. If you cannot access this screen, ask an authorized owner-company site administrator to inspect it rather than changing roles solely to follow a guide.
The vendor asks customers to contact support@teamwork.com with affected email addresses to remove them from the listing. An authorized administrator should first establish whether the address is valid, why the failure occurred and whether retrying is appropriate. Do not treat removal as proof that the underlying rejection or authentication problem is fixed. Do not ask support to unblock every address indiscriminately.
Separate application, delivery and authentication evidence
Use the strongest available evidence for the particular stage:
- No intended notification: review mute state and the relevant event’s notification behavior. DNS cannot fix an email that the application did not attempt to send.
- Failed-log entry: preserve the affected recipient, event time and available error information; involve Teamwork support where provider action is required.
- Receiving-server rejection: obtain the SMTP response or message trace from the receiving administrator. A failed inbox search is not a substitute for that evidence.
- Quarantined or junked message: examine the receiving service’s reason. Authentication can pass while reputation, content or local policy still causes filtering.
- Delivered message: inspect the original message and trusted authentication results for that exact route. A different sender or forwarded copy can have different results.
The support page publishes sending IP and reverse-DNS information. Treat those values as provider-maintained diagnostic context, not permanent customer SPF authorizations or a blanket bypass list. Confirm current applicability with the provider and receiving security owner before considering any narrowly scoped exception.
Although the vendor recommends safe-sender entries for @teamwork.com and @eu.teamwork.com, a familiar visible address is not proof of origin. Do not disable phishing, malware, spoofing or authentication checks to force delivery. The receiving security owner should decide whether any exception is needed, what verified traffic it matches, how long it lasts and how it will be removed.
Inspect the actual identities in a received message
Open the original message’s raw headers in the receiving mailbox or use the receiving service’s administrative trace. Record the actual visible From domain, Reply-To, SMTP MAIL FROM identity, DKIM signing domain and selector, and the receiver’s SPF, DKIM and DMARC results. Keep the complete relevant authentication fields locally; redact unnecessary personal or project information before sharing.
Establish the receiver’s trust boundary first. Use results generated inside the actual receiving service’s known processing boundary and its documented handling of externally supplied Authentication-Results. The service must remove, ignore or clearly distinguish untrusted external result fields. Header position or a familiar authserv-id string alone is insufficient: an attacker can insert plausible-looking results. If you cannot identify trustworthy fields, ask the receiving administrator for a trace rather than declaring a pass.
The documented From and Reply-To are provider-domain identities. Reply-To determines where a reply goes; it is not the identity SPF evaluates and does not establish DMARC alignment. SPF normally evaluates the actual SMTP MAIL FROM domain, with HELO relevant in the protocol’s applicable cases. Do not assume that the envelope domain is exactly teamwork.com merely because the From address is.
For DKIM, identify the intended Teamwork notification signature, its actual d= signing domain and s= selector, and the receiving service’s result for that signature. The support source does not publish a universal selector or a complete runtime identity tuple. Do not invent one or accept an unrelated passing signature as proof that the intended provider signature worked.
DMARC compares authenticated identifiers with the visible From domain. Relaxed alignment allows an Organizational Domain match; strict alignment requires an exact domain match. A child domain that aligns in relaxed mode is not automatically a strict match. Evaluate the actual message and applicable policy instead of assuming a mode or current policy value from this guide.
For the documented provider route, seek the intended provider DKIM signature passing and aligning with the actual provider From, together with trusted dmarc=pass. A DMARC pass supplied only by SPF does not prove DKIM worked. A provider-domain pass is also not evidence that your company’s domain has been authenticated as a sender. See raw DKIM results versus aligned DKIM policy results for that distinction.
Diagnose SPF and DKIM failures without changing the wrong domain
Keep SPF diagnosis independent even if DKIM supplies a DMARC pass:
- SPF fail: compare the evaluated envelope identity, actual connecting sender and receiving path. Forwarding can change the relevant connection. Escalate provider-owned authorization issues to Teamwork rather than adding authorization to your company’s apex.
- SPF temperror: preserve the receiver’s temporary DNS/error evidence and timestamps. Retry through the approved route after the responsible operator investigates; a temporary error is not a request to replace SPF.
- SPF permerror: ask the owner of the evaluated domain to inspect policy syntax, duplicate SPF policies and the limit of ten evaluated DNS-dependent terms, including nested processing. This is not merely a limit of ten visible include statements.
- DKIM fail or missing signature: preserve the intended signing domain, selector and error. Determine whether the original message was modified or passed through another gateway, and involve Teamwork for signing/key problems on its domain.
Do not create a second SPF record, weaken your existing qualifier, replace your DMARC policy or delete a DNS delegation to troubleshoot this provider-owned route. Adding any all mechanism to an SPF policy disables its redirect behavior, but no customer SPF edit is prescribed here in the first place.
Likewise, there is no customer CNAME publication or flattening change to perform, no customer DKIM key to generate, and no MX or nameserver migration in this workflow. Preserve current inbound routing, DNSSEC and security settings. A public DNS lookup can inform a diagnosis; it cannot prove a particular message was signed or accepted.
Retest safely and define what success means
After the authorized owner has addressed the identified cause, arrange one controlled notification through the same Teamwork.com project route and a valid recipient authorized to receive it. Use a non-sensitive test event where possible. Do not send real project content to an outside mailbox merely to compare delivery.
Check each stage separately: the intended notification was enabled, the relevant application event occurred, the provider did not report the same failure, the receiving service recorded the outcome, and the delivered original has trustworthy identity and authentication evidence. For DKIM acceptance, retain the intended signature’s passing aligned result and the trusted DMARC result, not just a green inbox or a generic SPF pass.
If the From domain differs from the documented provider route, stop and identify the actual feature, integration or gateway. Do not relabel a rewritten From as successful customer-brand authentication. If authentication passes but filtering persists, continue with the receiving service’s delivery explanation rather than editing sender DNS.
Restore temporary notification preferences or approved test configuration after the investigation. Any security exception should have an owner, review date and rollback plan. No single successful sample guarantees future delivery or proves every notification type uses the same path.
What to send Teamwork support
An authorized support request can include the affected site and notification type, UTC time, minimally necessary recipient address, the relevant failed-log details, a receiving trace or SMTP error, and redacted authentication evidence. State whether the notification was muted and whether the recipient saw a delivered, junked or quarantined copy.
Do not send passwords, API keys, session cookies, private DKIM keys or unrelated project content. Ask a precise question: whether this message was attempted, whether provider-side suppression applies, or whether the observed signing identity is expected for this notification route. A support request or log removal is a checkpoint, not proof of recovery; verify the next approved notification afterward.
Sources and documentary limits
The notification article supports provider-owned SPF/DKIM and From/Reply-To, the mute boundary and administrator troubleshooting. The two inspected UI images corroborate Email and View Logs; their filenames are not proof of a current UI revision date. Neither date is a customer implementation test.
This is a documentary guide, not a report of access to a customer account, DNS changes, test sends or observed customer delivery. It does not establish a custom-domain sending workflow or the capabilities of other Teamwork products.