Firstup SPF, DKIM and DMARC setup, step by step

Firstup custom-domain authentication is a support-assisted workflow. Give Firstup the company domains you want to send from and your DNS contact's email address. Firstup sends that contact an account-specific DNS packet through SendGrid. Publish those exact records, confirm installation to ce@firstup.io, and wait for Firstup to verify completion. Then select the appropriate Creator Studio email alias and test its branded DKIM and DMARC results.

There is no universal Firstup SPF include, selector, record type or record count to copy from this guide. The official trusted-sender procedure establishes how to obtain and activate the correct records, rather than publishing a generic DNS recipe.

This guide covers Creator Studio campaign email with a custom company From address. It does not configure the separate Dynamic Signal platform, an independently operated SendGrid account, mailbox SMTP, or inbound allowlisting. Shared corporate history does not make those procedures interchangeable.

No customer account, support request, DNS change or test send was performed for this guide.

On this page

• Prepare the domain and responsible people
• Obtain and activate the Firstup DNS packet
• Publish only the issued records
• Set up and assign the email alias
• Preserve SPF and DMARC policy
• Test the selected campaign sender
• Troubleshoot authentication and delivery separately
• Frequently asked questions

Prepare the domain and responsible people

Decide the exact company domain for the visible From address. updates@example.com and updates@news.example.com do not automatically represent the same authenticated domain. Tell Firstup about every intended domain, including future custom senders, rather than assuming parent-domain approval covers each child.

Coordinate three responsibilities:

• Firstup: supplies the account-specific DNS instructions and verifies the completed technical setup.
• DNS administrator: identifies the authoritative zone, checks existing dependencies, publishes approved records and reports installation.
• Creator Studio administrator or publisher: creates or receives access to the alias, selects it for the campaign and performs a controlled test.

Access to aliases is not the same as authority to edit DNS. Firstup's public procedure does not establish a universal commercial plan entitlement or guarantee that every account exposes identical controls. Confirm the feature and required permissions in your community before scheduling a change.

Save the existing SPF, DMARC, selectors and relevant delegations. Keep a record of the intended From, the domains submitted to Firstup, and the responsible DNS contact. No mailbox password or DKIM private key is needed for this DNS publication workflow.

Obtain and activate the Firstup DNS packet

The trusted-sender instructions describe this sequence:

1. Request custom sender-domain setup from Firstup. Supply the company domains you want to use now or later and the email address of your DNS contact.
2. The contact receives an email titled Can you help install these DNS records?, sent from Firstup through SendGrid. Match it to the authorized setup request and the correct domains before applying it.
3. Have the DNS administrator install the records in that packet. Preserve each exact type, full owner, complete value or target, and any supplied options. Resolve collisions or ambiguous instructions with Firstup before changing existing data.
4. After installation, send confirmation to ce@firstup.io through the established support conversation. Include enough domain and record context for verification, not passwords or private keys.
5. Wait for Firstup to verify that technical setup is complete. A successful DNS save or an alias appearing in Creator Studio is not that confirmation.

If the packet is missing or no longer matches the desired domain, obtain a current one. Do not reconstruct it from another customer's setup, an old SocialChorus hostname, an inbound allowlist, or a standalone SendGrid example.

Firstup says aliases can be created before technical setup finishes, but that does not authenticate their mail. Keep publication, Firstup verification and campaign testing as separate checkpoints. Domain setup is required per company domain, not repeated for every local mailbox name using that same domain.

Publish only the issued records

Find the authoritative owner

Read the full owner in the packet before translating it to the DNS panel's name field. A panel may append the zone automatically. The following are mapping examples, not issued Firstup records:

Full owner: SELECTOR._domainkey.example.com
Zone: example.com
Relative name: SELECTOR._domainkey
Full owner: SELECTOR._domainkey.news.example.com
Parent zone: example.com
Relative name in parent: SELECTOR._domainkey.news
If news.example.com is separately delegated:
Zone: news.example.com
Relative name there: SELECTOR._domainkey

An existing _domainkey.example.com NS delegation can put a selector under a different administrator's authority. Publish through that authoritative service, not as an ineffective parent-zone copy. Preserve delegations and selectors used by other senders. Never delete NS records, change receiving MX, disable DNSSEC or switch nameservers merely to make a tutorial's layout fit.

Apply safeguards for the actual record type

If Firstup issues a CNAME, publish its exact target hostname, without a URL scheme. Do not add TXT, A, AAAA, MX or another CNAME at the same owner. If that owner already serves another sender, ask Firstup and the existing owner to resolve the conflict. Do not replace the alias with today's resolved TXT key; provider-managed rotation may rely on the alias remaining in place. RFC 1034 section 3.6.2 describes CNAME restrictions.

For a CNAME on Cloudflare, use DNS only and check that flattening does not hide the literal alias. Per-record flattening may need to be off, but zone-wide, apex and same-zone behavior can take precedence. Have the DNS administrator resolve the specific issue without making an unreviewed zone-wide change. See Cloudflare's proxy guidance and flattening documentation.

If Firstup issues a DKIM TXT record, publish the complete tagged public value exactly as supplied, not just its p= portion. DNS may store one long TXT record in multiple quoted strings; they concatenate without added spaces. That is different from creating multiple competing key records. Never publish a private key. RFC 6376 defines the selector namespace and public-key format.

If the packet includes an SPF or DMARC instruction, review it against the existing policy before applying it. An apparent request to overwrite enforcement, duplicate SPF, reuse an occupied owner or replace receiving MX needs clarification, not automatic execution. SendGrid's general documentation explains alternative record arrangements, but does not establish which arrangement Firstup issued to your community.

Check publication without changing anything

Use the query matching each record's actual type. Replace all uppercase placeholders; these commands have no sample result:

dig @AUTHORITATIVE_DNS_SERVER FULL_ISSUED_OWNER ISSUED_RECORD_TYPE +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_OWNER ISSUED_RECORD_TYPE +noall +answer

Compare authoritative and public answers with the packet. Follow any issued CNAME chain to the relevant public data. If answers are empty, inspect the full response without +noall +answer to distinguish absent data from SERVFAIL, timeout or delegation problems. Allow for old and negative cache lifetimes, then repeat. These checks support the installation confirmation; Firstup still needs to verify completion.

Set up and assign the email alias

Use the current alias procedure, rather than treating the DNS packet as a sender-selection step:

1. In Creator Studio, open Configure → Aliases.
2. Select the Email Aliases tab and + Email Alias.
3. Enter the internal Name and Description, then the recipient-visible From name and From email. Use the company domain included in Firstup's verified setup.
4. Set the intended Reply-to email and review the remaining alias fields, including the required address information. Reply-To and the optional on-behalf-of display do not replace From-domain authentication.
5. Save the alias. Arrange its assignment if the publisher does not already have permission to use it.

Creation and assignment are different permissions. Firstup's roles documentation says a Community Admin can create aliases but cannot assign them to other users or to themselves. A Brand Super Admin assigns aliases through People → Users → the user → Permissions → Email Aliases → Save. Applicable custom roles must have the relevant permissions; do not infer assignment rights from a similar role name.

Brand Super Admins can use all aliases. Other users generally need a non-default alias assigned before selecting it on the campaign's Deliver page. All Creator Studio users can use the default alias.

Do not set the new alias as default merely to make it selectable. Changing the default updates existing campaigns that use the default alias, so it is a separate change with a wider audience. Archiving an alias removes a choice from future selection but does not rewrite the sender on already-created campaigns. Plan changes to existing campaigns explicitly.

Preserve SPF and DMARC policy

SPF follows the actual envelope domain

SPF evaluates SMTP MAIL FROM, commonly represented by the received Return-Path, not automatically the visible From. After testing, use the receiver's smtp.mailfrom identity to find the policy that was actually evaluated. An inbound Firstup allowlist is not an SPF authorization packet for your sending domain.

Do not add a guessed include:sendgrid.net or other include at the root. If the issued packet requires an SPF change at an existing owner, have its administrator merge the authorized change into one v=spf1 TXT policy while retaining legitimate senders and the intended qualifier. Two SPF policies at one evaluated owner cause a permanent error. -all and ~all do not promise deterministic rejection or delivery.

SPF has a budget of 10 evaluated DNS-dependent terms, including nested terms reached through include or redirect, not ten visible includes. Check that budget when reconciling an actual SPF change or investigating permerror. See RFC 7208.

Do not presume strict alignment. A hypothetical envelope domain bounce.example.com can align with From example.com under relaxed aspf=r, but not strict aspf=s. Firstup's actual envelope domain must be observed; this example is not a promised return path.

Keep existing DMARC enforcement and reporting

Determine the effective DMARC policy for the intended From, including applicable ancestor policy. Missing _dmarc at a child alone is not proof of no policy. Preserve existing enforcement, alignment modes and report destinations. Fix Firstup's authentication path instead of weakening an established policy to p=none. Current policy discovery and alignment are defined in RFC 9989.

Only when no direct or inherited policy applies, and the domain owner approves initial monitoring with a review plan, may this minimal first policy be appropriate for From example.com:

Type: TXT
Full owner: _dmarc.example.com
Relative name in example.com: _dmarc
Value: v=DMARC1; p=none

For From news.example.com, use full owner _dmarc.news.example.com: relative _dmarc.news in the parent zone, or _dmarc in the delegated child zone. Do not duplicate an existing policy or override inherited enforcement. Resolver errors do not establish policy absence.

This minimal record requests no reports. Before adding rua, approve the recipient, access and retention arrangements; aggregate data can expose sending infrastructure and traffic patterns. Under RFC 9990 section 4, receivers must check DNS authorization when the report URI host's Organizational Domain differs from the Organizational Domain where the policy was found. A destination within the same Organizational Domain is excepted, even with a different hostname. For an external destination, the recipient normally supplies a v=DMARC1 authorization at POLICY-DOMAIN._report._dmarc.REPORT-DESTINATION-HOST. Obtain its exact values from the reporting service. DNS authorization is separate from your organization's privacy and data-sharing approval.

Test the selected campaign sender

Firstup's test-campaign procedure requires publishing access, such as Content Publisher, Community Admin, Brand Super Admin or an applicable custom role.

After Firstup verifies the domain, prepare an email campaign and select the intended alias on Deliver. On Review, use Send Test Campaign, choose Email and only controlled test recipients with valid Firstup profiles. A test can be sent without publishing to the campaign audience. Confirm its sender; do not confuse a test from the default alias with a test of the new custom alias.

Inspect the received original, not a forwarded copy. Record:

• The actual visible From domain and selected alias.
• The intended Firstup signature's d= signing domain and s= selector from the same DKIM-Signature field.
• A trusted receiver's dkim=pass for that intended signature, with its domain aligned to the intended branded From.
• A trusted dmarc=pass for that From domain.
• The separate SPF result and actual smtp.mailfrom, including alignment and any error.

For DKIM, relaxed adkim=r requires a shared Organizational Domain; strict adkim=s requires an exact domain match. A provider-domain signature can pass without aligning. A DMARC pass through SPF alone does not establish that your branded DKIM configuration works, and a rewritten provider-owned From is not success for the requested company address.

Find the DKIM selector in the received message, then query SELECTOR._domainkey.SIGNING-DOMAIN. Multiple signatures must be evaluated individually; do not pair a selector from one with the domain from another.

Use Authentication-Results only from infrastructure the receiving administrator trusts. Header placement or a matching authserv-id string alone cannot exclude forged results. If trustworthy receiver results cannot be identified, use an administrator-verified trace or another controlled receiving system. RFC 8601 defines this boundary.

Repeat for each distinct From domain and relevant campaign path. One successful test is evidence about that message, not all communities, aliases or future deliveries.

Troubleshoot authentication and delivery separately

• No DNS packet: ask Firstup to issue or resend it to the approved DNS contact. Do not borrow another tenant's records.
• Records resolve but setup is pending: complete installation confirmation to ce@firstup.io and obtain Firstup's verification. Public DNS alone cannot finish its support-side step.
• The alias is missing on Deliver: check its active status and the publisher's assignment. A Community Admin cannot solve their own assignment by self-granting access; ask a Brand Super Admin.
• DKIM is missing or fails: check the selected alias, verified domain and observed selector. Compare the issued records and resolved key. If they match, investigate sender configuration or message modification with Firstup and receiving IT.
• DKIM passes but DMARC fails: check alignment against the actual From and current adkim, not only the signature's cryptographic result. Preserve the DMARC policy while repairing the route.
• SPF fails despite DMARC pass: investigate independently. fail or softfail concerns authorization; temperror is transient evaluation failure; permerror can involve duplicate records, syntax or lookup-budget problems. An SPF pass on an unaligned provider envelope is a different issue, not a failed SPF check.
• No test arrives: verify the test user's email, campaign link, trigger and time with Firstup Support, then have receiving IT inspect delivery and quarantine logs. Firstup warns that domain-impersonation filtering can quarantine mail without notifying the sender.
• Transport fails: Firstup's email delivery security requirements, require recipient servers to support TLS 1.2 or later. Correct SPF/DKIM cannot repair an incompatible receiving TLS configuration. Do not disable encryption or downgrade security to test delivery.

Firstup's inbound allowlisting guidance is a separate receiving-side matter. It explicitly does not prevent domain impersonation. Any needed receiving rule belongs with your security team; it is not permission to bypass anti-spoofing controls or copy that page's IPs into SPF. Even fully authenticated email can encounter reputation, content or recipient filtering.