Click and Pledge SPF, DKIM and DMARC setup, step by step

For Click & Pay Salesforce Dispatch Mass Email, authenticate the sending domain in the SendGrid account already connected to Dispatch, then use that domain in the message's From Sender. With SendGrid's automated security enabled, the account supplies CNAMEs for its envelope and DKIM configuration. Verify the exact records in SendGrid and test a real, authorized Dispatch email. Separately confirm that the organization's Core Salesforce sender-domain verification prerequisite is satisfied. Authenticating SendGrid does not complete Salesforce verification. Click & Pledge: Dispatch Mass Email

This guide assumes an existing, approved Click & Pay/SendGrid connection and plan, authorized DNS access, and an independently verified Core Salesforce sender domain. It does not cover Click & Pledge receipt delivery, donation-form mailing-list opt-ins, Salesforce Marketing Cloud, new account connections, paid upgrades, or payment processing. No customer account, DNS changes, purchases or sending tests were performed.

On this page: Check the two prerequisites before changing DNS · Generate the existing account's authentication records · Understand the packet without copying sample values · Publish only the approved DNS changes · Verify the domain, then select the Dispatch sender · Test the actual email path without a payment · Troubleshooting and frequently asked questions

Check the two prerequisites before changing DNS

The current Dispatch customer guide specifies two external requirements: SendGrid domain authentication and Core Salesforce domain verification. It also distinguishes Marketing and API SendGrid accounts in its integration requirements. Identify the actual account used for this Dispatch sending path; do not authenticate an unrelated account simply because it belongs to the same organization.

Have the Salesforce administrator confirm that the exact sending domain meets the current Core Salesforce requirement. Click & Pledge warns that unverified addresses may be substituted with a different sender identity. Its linked Salesforce Help page returned a CSS error during this research, so this guide does not claim to reproduce or verify that separate Salesforce setup. If its completion cannot be established, stop and obtain current instructions and confirmation from the administrator or Salesforce support. Dispatch prerequisites

Record the approved From domain, connected SendGrid account, DNS host and existing authentication configuration. Preserve the existing default domain, other applications' selectors, mailbox service and inbound MX. A new sender is not permission to migrate the domain's email service.

The provider also has a publicly accessible domain-verification walkthrough marked “Internal — Zendesk staff article.” It describes authentication during a paid-plan upgrade. Treat it as contextual documentation, not a reason to enter payment information or complete a plan change. The existing-account Sender Authentication route below is documented directly by Twilio. Click & Pledge: verification walkthrough

Generate the existing account's authentication records

Use an authorized administrator of the connected SendGrid account:

1. Open Settings > Sender Authentication. Inspect the existing Domain Authentication entry before creating another one. If the intended domain is already verified, validate its current configuration and proceed to the Dispatch sender check rather than duplicating it.
2. For a domain needing setup, use Get Started in Domain Authentication and select the actual DNS host, or the applicable Other Host option.
3. For this documented procedure, enter the approved root domain only, omitting subdomains and protocols such as www or https://. Twilio's manual-flow instructions expressly limit this field that way. Separately configured child-domain sending requires applicable supported instructions or confirmation; do not use this wizard unchanged for it or assume that a parent's verification grants child-domain sending permission.
4. Keep Use automated security enabled for this guide's CNAME-based route. Manual Setup means the administrator publishes the records; it does not mean turning automated security off.
5. Leave optional link branding off unless separately approved. Do not change established branding, custom return paths, selectors or regional settings simply to match a tutorial. Preserve the account's approved region and use the records it actually generates.
6. Continue to Install DNS Records and select Manual Setup. Copy the exact record types, full owners and complete targets from the account.

Do not authorize Domain Connect, grant new DNS access, rotate credentials or connect a new SendGrid account as an implicit part of these steps. If your DNS provider cannot support the required CNAME syntax, coordinate an alternative with the service owners; the automated-security-off MX/TXT route is outside this guide. Twilio: configure domain authentication

Understand the packet without copying sample values

For the automated-security-on route, Twilio's record table identifies the authentication components:

Link-branding aliases are a separate optional routing feature, not the two DKIM aliases. Some explanatory prose in the current Twilio page calls the two aliases link-branding records; its explicit table identifies the _domainkey entries as DKIM. Follow the account packet and resolve discrepancies with support rather than relabeling a key record. Twilio authentication record table

The Click & Pledge walkthrough's screenshots and text show different example envelope labels, and its screenshot includes reporting recipients different from the textual example. These are illustrations, not a reusable DNS recipe. Do not copy their customer identifiers, DKIM targets, reporting addresses or policy. The public key is made discoverable through the issued aliases; no DKIM private key should be published or shared.

Publish only the approved DNS changes

Find the authoritative DNS zone, which may be hosted somewhere other than the registrar or website. Compare each proposed owner and destination with the approved sending and routing plan. If the packet requires a new bounce or tracking route, approve that exact destination and its consequences before activating it. Optional branded web links need their own routing approval, not merely acceptance of the email-authentication task.

For each CNAME:

• Preserve its exact record type and full target. Do not turn it into a TXT record or paste a truncated screenshot value.
• Translate the full owner into the DNS editor's expected relative name when it appends the zone automatically. Inspect the saved full name to prevent duplicated domain suffixes.
• Publish in the correct authoritative child zone when delegation exists. Do not remove a parent or _domainkey delegation to force the record into a different zone.
• Check the exact owner for conflicts. A CNAME cannot coexist there with another target or unrelated A, AAAA, MX or TXT records. Stop and arrange an account-supported alternative if an existing sender depends on that owner.
• Use DNS-only records, not HTTP proxying. Preserve literal CNAME answers where the verifier needs them.

For Cloudflare, turn off a relevant per-record Flatten option when available. Check whether flatten-all zone settings override it, and review other services before making any approved zone-wide change. Apex and same-zone target behavior may flatten automatically. If those rules prevent the required answer, coordinate a supported configuration rather than inventing a switch or moving shared services. Cloudflare: CNAME flattening controls

Preserve SPF at its actual owner

Do not add a second SPF policy at the root or replace existing mailbox authorizations. In this route, the generated envelope alias supports SPF; the current setup does not require a separate root-domain SendGrid include.

SPF evaluates the SMTP MAIL FROM identity, or HELO in applicable cases, not automatically the visible From. If support supplies an additional requirement for a different route, first establish the evaluated owner. Keep one v=spf1 TXT policy per owner, retain legitimate mechanisms and the approved qualifier, and assess the ten evaluated DNS-dependent-term limit including nested processing. Any all mechanism suppresses redirect. Changing -all to ~all is not a default troubleshooting step. RFC 7208: SPF

Reconcile the DMARC row safely

A generated p=none suggestion is not permission to downgrade a working policy. Inspect the existing direct and applicable inherited policy, including alignment and authorized reports. Do not duplicate an existing DMARC record or replace an inherited enforcement policy with a weaker child record just to satisfy a wizard. Ask support how to verify the approved existing configuration if the screen appears to demand conflicting values.

Only when there is no direct or applicable inherited policy, and the domain owner approves a monitoring-first plan, a minimal initial policy can take this form:

Type: TXT
Full owner: _dmarc.APPROVED_FROM_DOMAIN
Value: v=DMARC1; p=none;

Replace the uppercase placeholder with the actual domain and map the owner relative to its authoritative DNS zone. This example requests no reports and imposes no quarantine/rejection request; it does not authenticate messages. Reporting destinations need a separate privacy and operational decision. For aggregate reports, compare the destination's Organizational Domain with the Organizational Domain of the domain where the DMARC policy was found, including when that policy is inherited. A destination in a different Organizational Domain from that policy-found domain requires receiver-checked DNS authorization; a destination within the same Organizational Domain as that policy-found domain is excepted. DNS authorization does not replace the owner's data-sharing approval. Do not copy rua or ruf recipients from the vendor screenshot. RFC 9989: DMARC, RFC 9990, section 4: external reporting authorization

Verify the domain, then select the Dispatch sender

Inspect every issued alias at the authoritative server and through an independent recursive resolver. These are command templates, not executed results:

dig @AUTHORITATIVE_NAMESERVER CNAME ISSUED_FULL_OWNER
dig CNAME ISSUED_FULL_OWNER

Replace the placeholders and repeat for each CNAME. Expect the exact account-issued target. An IP answer alone is not proof that the required alias is visible. Check the applicable DMARC policy separately.

Return to SendGrid > Settings > Sender Authentication and use Verify for the domain. Twilio notes that DNS visibility may take up to 48 hours, but incorrect owners or targets need correction rather than passive waiting. Confirm the complete domain-verification outcome, not only one passing row. Twilio documents that sending from the matching authenticated domain then applies that domain to the message; DNS publication alone is not this activation checkpoint. Twilio: verification and domain application

Do not follow a billing wizard's final Continue merely because a screenshot says “It worked.” That screenshot's continuation finishes a paid-plan change. This guide uses an already approved account and does not authorize a purchase.

In Salesforce, the Dispatch customer guide places configuration at Click & Pay Suite > Dispatch > Email > Mass Email > Settings. Use an existing approved Sender whose address belongs to the verified domain. If a new Sender is needed, the guide documents +Create Sender, but creating or changing that identity must remain within the administrator's approved scope. Domain authentication does not authorize impersonating an arbitrary address.

When composing the controlled message under Mass Email > Marketing > Messages, confirm From Sender, subject and message settings. Keep the required unsubscribe group and consent controls intact. Do not enable never-suppress exceptions, automatic bounce purging, contact synchronization, new imports, Engagement Plans or recurring schedules merely to test authentication. Dispatch sender and message controls

Test the actual email path without a payment

Have an authorized operator send a plain, non-sensitive Dispatch message to a controlled, consenting test recipient, using an approved test list and any required existing test campaign configuration. Do not initiate a donation, charge, receipt, pledge or other financial obligation. Avoid production campaign-status automation; if a safe email-only test cannot be arranged, stop and coordinate it with the administrator.

The customer guide says SEND in the designer triggers sending, and Sync refreshes the displayed status and statistics. A Scheduled or Sent label, or an inbox delivery, is not authentication evidence. Examine the newly received message from this exact Dispatch route instead.

Use Authentication-Results generated within the receiving service's known processing boundary. Consult its documented treatment of externally supplied Authentication-Results or ask its administrator to identify the authoritative results. Header position or familiar authserv-id text alone is not proof; disregard attacker-supplied or untrusted fields. RFC 8601: Authentication-Results trust

Acceptance requires all of the following:

• The visible From remains the intended organizational address, not a Salesforce or provider substitution.
• The intended Dispatch/SendGrid DKIM signature passes, using the expected signing domain d= and selector s=, and aligns with the visible From under the current policy.
• The trusted receiver reports dmarc=pass for that intended identity. An SPF-only pass or unrelated DKIM signature does not prove the configured signing path works.
• SPF and its actual MAIL FROM identity are recorded and any failure is investigated separately.

Relaxed DKIM alignment permits a shared Organizational Domain; strict alignment requires the signing domain to exactly match the From domain. SPF alignment compares MAIL FROM with From under its own mode. A generated child envelope domain does not automatically satisfy strict SPF alignment. Preserve the approved policy instead of relaxing it to conceal a mismatch. See raw DKIM results versus aligned DKIM policy results and RFC 9989.

Troubleshooting and frequently asked questions

Why is the domain still unverified?

Check the connected account, authoritative zone, exact owners and full targets, domain-suffix duplication, CNAME conflicts, proxying and flattening. Resolve a shared-selector conflict with support; do not overwrite another sender. A verified domain in a different SendGrid account does not establish this Dispatch account's setup.

Why did Salesforce change the From address?

Recheck the separate Core Salesforce verification prerequisite and the selected Dispatch Sender. The current Click & Pledge guide warns about substitution for unverified domains. SendGrid authentication alone is not proof that Salesforce has accepted the identity.

Why does SPF fail even though DMARC passes?

Aligned DKIM can supply DMARC pass while SPF has a separate problem. Investigate fail against the actual envelope owner and sending route. A temperror calls for investigating a temporary evaluation/DNS failure and retesting; a permerror indicates a permanent configuration/evaluation problem, such as duplicate SPF policies or excessive DNS-dependent terms. Do not blindly add root includes or dismiss errors because delivery succeeded.

Can I use these settings for donation receipts?

No. This is a Dispatch Mass Email guide. The provider documents receipt delivery separately, and the sending route and sender behavior must be evaluated independently. Do not process a payment to test this article.

Does a valid DNS packet guarantee inbox delivery?

No. Record publication, sender verification, actual signing, alignment and inbox placement are different observations. Keep the controlled test evidence and repeat it after account, domain, selector or routing changes. Share only minimally necessary diagnostic details with authorized support, not donor lists or financial information.