Click & Pay (Salesforce): Dispatch - Verifying a Customer's Sending Domain in SendGrid

Internal — Zendesk staff article

This article covers the steps to Authenticate your sending domain in SendGrid, which a customer must complete before a paid Dispatch plan upgrade can finish.

⚠️ This is a SendGrid requirement, not a Click & Pledge requirement. Click & Pledge does not control this step, cannot waive it, and cannot complete it on the customer's behalf — it happens inside SendGrid's own flow during the process of setting up a paid marketing plan.

Why SendGrid requires this: Domain authentication proves to receiving mail servers (Gmail, Outlook, etc.) that the customer's organization actually owns the domain they're sending mass email from, and that SendGrid is authorized to send on their behalf. Without it, mail sent through Dispatch is more likely to be flagged as spam or spoofed, since anyone could otherwise claim to send email "from" a domain they don't own. This is standard email deliverability/anti-fraud practice across all mass email providers, not something unique to SendGrid or Click & Pledge.

This article walks through what the customer sees, the two branding paths (Yes/No), and what they need to do at their DNS host to finish verification.

Glossary

• DNS (Domain Name System) — The system that translates domain names (like clickandpledge.com) into the records mail servers, browsers, and other systems use to find and verify that domain. DNS records are managed at the customer's DNS host (e.g., Route 53, GoDaddy, Cloudflare, Namecheap).
• DNS host / registrar — The service where a customer's domain is managed and where DNS records are added. This is often, but not always, the same company the domain was purchased from.
• CNAME record — A DNS record that points one domain/subdomain to another. SendGrid uses CNAME records to prove domain ownership and to route mail-related traffic (like link tracking) through the customer's own domain.
• TXT record — A DNS record that holds text data, commonly used for verification and email authentication policies (such as DMARC).
• DMARC (Domain-based Message Authentication, Reporting & Conformance) — An email authentication policy published as a TXT record. It tells receiving mail servers what to do with messages that fail authentication checks (e.g., reject, quarantine, or allow) and where to send reports about those messages. It builds on top of SPF and DKIM.
• DKIM (DomainKeys Identified Mail) — An authentication method that adds a digital signature to outgoing email, letting receiving servers verify the message wasn't altered in transit and genuinely came from the claimed sending domain. The s1._domainkey / s2._domainkey CNAME records set this up.
• SPF (Sender Policy Framework) — An authentication method that publishes a list of mail servers authorized to send email on behalf of a domain. Receiving servers check the sending server against this list to help catch spoofed email. SendGrid's domain authentication process handles SPF as part of the CNAME setup, so no separate SPF TXT record is needed for this flow.
• Domain authentication — SendGrid's term for the overall process of verifying domain ownership via DNS
•  records, which removes the "via sendgrid.net" text some inbox providers otherwise append to the From address.
• Link branding — An optional part of domain authentication where tracking links in emails use the customer's own domain instead of sendgrid.net. This is the "Yes/No" choice the customer makes during setup.

When this applies

Any customer creating or upgrading to a paid plan that uses SendGrid for mass email through Dispatch be required to complete this. It is a SendGrid requirement, not something Click & Pledge can bypass — the account will not finish provisioning until the domain is authenticated.

Step 1: Account set-up triggers domain authentication

When the customer enters their credit card information, the Authenticate your sending domain screen will open and must be completed before the paid marketing account can be confirmed.

They'll see:

• Domain — here they need to enter their domain (e.g., clickandpledge.com)
• Would you like to brand the link for this domain? — Yes or No

This choice determines which DNS records they'll need to add. Domain authentication itself removes the "via sendgrid.net" text some inbox providers append to the From address. Link branding additionally rewrites tracking links to use the customer's domain instead of sendgrid.net.

Step 2: DNS records — "No" (link branding off)

If the customer selects No, SendGrid still requires 4 DNS records to be added at their DNS host under Manual setup:

Here is a sample:

Note: The Host/Value pairs above are specific to this customer's domain. Every customer will see their own domain and SendGrid subdomain (wl###) values — do not reuse these values for a different account.

Step 3: DNS records — "Yes" (link branding on)

If the customer selects Yes, SendGrid requires 6 DNS records instead of 4 — the two extra CNAME records handle the link rewriting:

Here is a sample:

Note: The Host/Value pairs above are specific to this customer's domain. Every customer will see their own domain and SendGrid subdomain (wl###) values — do not reuse these values for a different account.

After the records are listed, SendGrid shows a Step 2: Confirm DNS records have been added section with an I've added these records checkbox before Continue becomes active.

Step 4: Adding the records at the DNS host

Where these records get added depends on who hosts the customer's DNS (Route 53, GoDaddy, Cloudflare, etc.) — the exact screens will differ, but the concept is the same everywhere: each row in the table becomes one DNS record at the host.

As a general reference, in a host like Amazon Route 53 this looks like:

1. Open the hosted zone for the domain.
2. Click Create record (or Add record, depending on host).
3. For each row in the table:
   • Record name — the Host value (minus the domain itself, if the host splits it out — e.g., enter em3509 if the domain clickandpledge.com is appended automatically)
   • Record type — CNAME or TXT, matching the table
   • Value — the corresponding Value from the table
4. Repeat for all rows (4 for the No path, 6 for the Yes path), then save/create the records.

⚠️ If the customer isn't sure how to add DNS records with their host, direct them to their host's documentation or support — Click & Pledge staff cannot make DNS changes on the customer's behalf.

Step 5: Verifying the domain

Once the DNS records have propagated (this can take anywhere from a few minutes to a few hours depending on the host and TTL settings) and the customer clicks Continue, SendGrid checks the records.

If everything is correct, they'll see:

Clicking Continue from this screen completes the plan change and finishes the account upgrade.

If verification fails

If the records haven't propagated yet or were entered incorrectly, the customer will not see the "It worked!" confirmation and won't be able to continue. Common causes:

• DNS changes haven't propagated yet — ask the customer to wait and retry.
• A record was entered with a typo, extra domain suffix, or trailing period.
• The wrong record type was selected (CNAME vs. TXT).

Have the customer double-check the records against the table shown on their screen (or the ones documented above, if applicable to their case) and confirm with their DNS host that the records saved correctly.

Re-checking or revisiting later 

The Manage your domain in sender authentication link at the bottom of the Authentication domain screens takes the customer to SendGrid's Settings > Sender Authentication page. This is the same authentication process, not a separate or simplified one — but it's useful for checking a domain's verification status, re-verifying after DNS changes, or picking the process back up without going through initial set-up again.
 

Related articles

• Click & Pay (Salesforce): Dispatch - Email - Mass Email
• CONNECT: SendGrid Integration (mailing list opt-in on donation forms)