If you are searching for Dynamic Signal SPF or DKIM settings, first identify which product and email you have. The Dynamic Platform documentation says its Notification Settings cannot customize the From address; they can customize Reply-To. Changing where replies arrive is not the same as authenticating your domain as the sender. Do not publish guessed SPF includes or DKIM records to solve a Reply-To task.
This guide covers the documented Dynamic Signal Notification Settings route, not every Firstup product, a migrated tenant, or a separately contracted custom-sender integration. It explains the supported change, what not to change in DNS, and how to investigate the actual notification. No customer account, DNS change, delivered-message test or live configuration was performed for this article.
Which platform are you using?
The official support site identifies this product as Dynamic Platform. Its support procedure routes unresolved requests to the Firstup Support team. That relationship does not make every Firstup email setup procedure applicable to Dynamic Signal. Confirm your platform with your administrator and the help centre linked from your actual account. See Dynamic Platform support.
Firstup's separate Make Firstup a Trusted Sender procedure covers its own sender setup. Do not apply that process merely because both help centres mention Firstup. If your account has a custom-From feature or a support-issued DNS packet, verify its exact platform and scope before proceeding; that is outside the notification-setting limitation documented here.
From, Reply-To and authentication are different
- From is the visible author address. Its domain is the reference identity for DMARC.
- Reply-To tells a mail application where replies should go. Replacing it does not replace the visible From domain or establish SPF/DKIM alignment.
- SPF checks whether the connecting sender is authorized for the SMTP envelope identity, normally MAIL FROM; an empty MAIL FROM uses HELO. This need not be the visible From domain.
- DKIM verifies a signature associated with the signing domain in
d=. Its selector ins=identifies the public key to query. - DMARC requires a passing, aligned SPF identity or a passing, aligned DKIM signature. A passing check for an unrelated domain is not enough.
These distinctions follow SPF's specification and DMARC's specification. A branded display name, successful reply or attractive template is not authentication evidence.
Change Reply-To in the documented Dynamic Signal route
The official Notification Settings article states: “The From email address can't be customized. Only the Reply-to field can be customized.” Its documented navigation is Admin > Community Settings > Notification Settings. The Reply-to field accepts the replacement reply address.
- Ask the authorized community administrator to identify the affected community and existing reply destination. Record the old setting for rollback.
- Agree on a monitored reply mailbox and who is allowed to receive those replies. Do not choose a personal or external address without the organization's approval.
- Open the documented settings route and inspect the Reply-to field. If your interface differs or the field is unavailable, stop and confirm the platform/permissions instead of guessing another product's steps.
- Enter only the approved reply address. Use the save/apply control presented by your actual interface; the cited text does not establish a universal button label.
- Verify the resulting setting and perform an authorized, limited notification check as described below. Record the result rather than assuming the field persisted.
Changing a reply destination can redirect sensitive correspondence. Keep that decision separate from changing notification subscriptions, templates or recipients. Do not enable a community-wide broadcast just to test an address.
What should you put in DNS?
Nothing solely because you changed Reply-To. For a notification whose actual From and signing identities remain provider-controlled, your organization's DNS does not configure the provider's DKIM keys. Retain your existing SPF, DKIM and DMARC for the services that really send using your domains.
Do not add a guessed include: value, a selector found in someone else's message, or a generic SendGrid packet to your domain. An observed provider signature can identify a key used on that message; it does not grant control over that provider domain or supply a customer setup procedure.
Do not create a second SPF record as an experiment. If a separate, verified sender legitimately needs an SPF change, inventory the existing authorizations and review a single policy. See EmailAuth's guide to multiple SPF records. That is a separate sender-management task, not a prerequisite for this Reply-To setting.
Keep existing DMARC enforcement and reporting intact. Do not weaken p=reject or p=quarantine, change MX routing, delete selectors, or add wildcard DNS records to work around a product limitation. If a message unexpectedly uses your own domain in From, obtain the correct supported sender-authentication procedure before drawing conclusions from this guide.
Verify the exact notification, not an unrelated email
Dynamic Signal's notification catalogue distinguishes messages such as content digests, newsletters, invitations and reports. Not every notification is controlled by the same settings or member preference. Choose the specific notification type relevant to the change; do not assume success on one proves all others.
Use an approved internal recipient and a harmless message, or inspect an existing message of the same type when a new send is not authorized. Record the community, notification type and timestamp without unnecessarily collecting message contents.
Check the delivered message's raw headers for its actual From and Reply-To. Confirm that Reply-To is the approved mailbox. If an end-to-end reply test is authorized, send a non-sensitive reply and confirm receipt at that mailbox. A correct header and a delivered reply establish different things; retain both results when both were tested.
For authentication, use the receiving mail system's own verified processing results. Identify its documented trust boundary and how it removes or distinguishes externally supplied Authentication-Results. A familiar server name or the position of a header alone does not prove trust. Ignore untrusted, sender-supplied result fields. See Authentication-Results security requirements.
Inspect the evaluated SPF identity, the relevant DKIM signing domain and selector, and the receiver's DMARC result against the actual visible From domain. Under strict adkim=s, the DKIM domain must exactly match From; strict aspf=s separately requires an exact SPF-domain match. Relaxed alignment permits the applicable organizational-domain relationship. A child envelope domain can align with a parent From domain under relaxed SPF alignment while failing strict aspf=s; a DKIM result is assessed separately under adkim. A DNS lookup alone does not prove that this message was signed or aligned. Investigate SPF fail, temporary lookup errors and permanent policy errors separately, even when aligned DKIM lets DMARC pass.
If investigating DKIM specifically, require a trusted passing result for the intended aligned signature. A DMARC pass obtained through SPF does not prove that DKIM worked. Do not claim that this article verified a fixed Dynamic Signal sender, selector, IP range or every notification route: none was established through a customer message test.
Troubleshooting and escalation
- Replies go to the wrong mailbox: compare the delivered Reply-To with the approved setting and check mailbox routing with its owner. Restore the prior approved value if needed. Do not change authentication DNS as a first response.
- From did not change: that is consistent with the documented Notification Settings limitation. Reply-To is not a custom-From switch.
- A notification is absent: check the particular notification's community settings and recipient preferences before diagnosing authentication. Do not subscribe people without approval.
- Authentication fails on a provider-domain notification: give support a redacted sample, notification type, timestamp and receiver findings. Do not try to repair a provider-owned DNS zone through your organization's DNS.
- Your tenant behaves differently: ask support to identify the current product, sending route and exact supported setup. Preserve that evidence; do not force a newer or older tenant into this article's scope.
The official support route offers a self-service question tool and Contact Support when suggested articles do not resolve the issue. Share only what is necessary through an approved support channel. Never attach passwords, access tokens or unrelated private message bodies.
Quick answers
Can I change Dynamic Signal's From address here?
Not in the documented Notification Settings route. The supported customization is Reply-To. Confirm any separately provisioned custom-sender capability with support.
Does using our domain in Reply-To require a Dynamic Signal DKIM record?
No. Reply-To alone does not make your domain the DKIM signing identity. Your mailbox must be able to receive approved replies, but that is distinct from authenticating the notification sender.
Is Dynamic Signal the same setup as Firstup Creator Studio?
Do not assume so. Verify the actual platform and use its product-specific instructions. A shared support organization is not proof of an identical sending workflow.
Does a DMARC pass mean the email is safe?
No. It verifies a domain-alignment condition, not the honesty of the message, its links or its requests. Treat unexpected sensitive requests with your normal security controls.