Vendasta SPF, DKIM and DMARC setup, step by step

For a Vendasta partner’s sending domain, open Partner Center > Marketing > Email settings and copy the current domain records: one SPF TXT, two DKIM CNAMEs and one DMARC TXT recommendation. For a client’s domain, use that client’s Business App > Administration > Email configuration > Authorize a domain instead. Publish the correct account’s records, retain existing legitimate SPF authorizations and DMARC policy, then verify a message from the actual campaign or notification route. Partner verification does not authenticate every client. Vendasta’s current authentication instructions

These are documentation-based instructions, not results from an authenticated account or live test. No account setting, DNS record or message was changed or sent while preparing this guide.

Identify the account and email product

Vendasta exposes several email contexts. Begin with the system that actually sends the message, not merely the platform through which you bought the service.

Vendasta explicitly excludes Conversations from the Partner Center email-settings workflow. Its separate connect-domain article also discusses resold services, so it should not be read as a replacement for the current Partner Center record instructions. Email-settings scope, resold-service domain setup

For a form notification, record the actual From address, the website/client account and its intended recipient. For campaigns, record the selected market and whether a salesperson is assigned to the account. Those details can explain why the message does not use the sender you expected.

Prepare access, sender details and DNS ownership

Have the partner or client owner approve the intended domain, an administrator retrieve the records, and the DNS owner prepare the change. A client’s permission to use its domain is distinct from your agency’s own domain authorization.

Before editing:

• Locate the authoritative DNS host. Buying a domain, hosting WordPress and operating email can involve different providers.
• Save the existing records and identify all legitimate senders using the domain.
• Record existing SPF, DMARC, DKIM selectors and any A/TXT/CNAME at a proposed new owner.
• Confirm that the sender address is on a domain you control, rather than a public Gmail or Yahoo domain.
• Check the required sender information, business mailing address and platform-user email verification for the campaign account. Authentication alone does not complete campaign readiness. Vendasta email requirements

Do not change MX records merely to authorize outbound campaigns. Do not purchase a new domain, move nameservers or alter another client’s configuration as a shortcut around missing access.

Configure the partner domain in Partner Center

The current interface separates sender configuration from DNS detection:

1. Open Partner Center > Marketing > Email settings.
2. In Sender and reply settings, set the intended Sender name and Reply Address, then select that card’s Save.
3. In Advanced email settings, choose Use my own email domain under Sender domain, set Email address, and select that card’s Save.
4. Find the intended domain in Email domains and copy every generated record’s type, owner and value.
5. Check the domain row’s overall state and each record’s Current value. A red Not found means the expected record has not been detected.

Saving one card does not save the other. Vendasta also documents that an assigned salesperson’s name and address can override the default sender/reply settings. Inspect the resulting campaign rather than assuming the default fields always determine the message. Current email-settings procedure

The current official instructions describe SPF as TXT, not a universal CNAME-only recipe. Do not delete an SPF authorization immediately after verification because an older tutorial calls it temporary. If your account displays a different supported record set, have Vendasta confirm its route before removing any record. Current record requirements

Check the effect on partner branding

Vendasta says Marketing Email settings and Partner branding Email settings share the same sending domain. A change can therefore affect brand notifications such as Daily Digests or Executive Reports as well as campaigns. The documentation also describes market-specific sender behavior and separate markets for distinct branding. Creating additional markets requires a Custom plan; confirm that entitlement before planning separate-market sender identities. Confirm the intended market and assess both campaign and notification consequences before replacing a working domain. Partner domain and market behavior

The same page describes an automatic fallback for persistently unverified domains: administrator notices every two weeks and a rollback to a Vendasta grey-label domain after eight weeks. Treat a sudden sender change as a reason to inspect verification and administrator notices, not as proof that your DNS provider changed the From address.

Authenticate each client in Business App

Open the client’s own Business App, not your agency’s Partner Center:

1. Go to Administration > Email configuration.
2. Under Advanced email settings > Sender domain, select the custom-domain option when that is the intended sending mode.
3. Use Authorize a domain in Email domains to add the client’s domain.
4. Copy that account’s SPF, DKIM and DMARC entries and reconcile them with the client’s existing DNS.
5. Publish the records and wait for the account’s verification results before testing the relevant client message.

These controls are described in the Business App email-configuration guide; Vendasta’s partner authentication reference explicitly identifies this as the separate client-domain workflow.

Business App can also use its default shared authenticated domain. A Gmail address can be a Reply Address without becoming an authenticated custom sending domain. Do not mistake a successful shared-domain message for proof that the client’s branded domain is ready.

If sender fields cannot be changed, the Business App documentation says to sign in directly rather than access it through a link that opens it on your behalf. Resolve the access context before generating replacement DNS records. Keep one verification record per client/account in your change inventory.

Publish SPF and DKIM without breaking other senders

Reconcile SPF at the exact owner

An SPF policy starts with v=spf1. Multiple unrelated TXT records are normal, but two separate SPF policies at the same owner cause SPF PermError. If the account’s required authorization belongs at an owner with an existing policy, merge the authorized terms into that one policy while preserving other current senders. Do not paste a second complete v=spf1 string. SPF record selection

Use the authorization shown for the current account, not a generic string copied from another organization. Preserve intentional qualifiers and redirect arrangements until the DNS owner has reviewed the entire policy. An all mechanism causes redirect in that same policy to be ignored, regardless of order; adding all to a redirect policy changes its behavior. Do not append an authorization after all. Never use +all to make a check look successful. RFC 7208 section 5.1

The SPF limit is ten evaluated DNS-dependent terms across the evaluation, including nested chains, not ten includes written in the top-level record. The terms are include, a, mx, ptr, exists and redirect. Check the complete chain before adding another provider. Avoid one-time manual flattening unless someone owns ongoing updates to provider IP ranges. SPF evaluation limits

Changing terminal ~all to -all cannot repair a message that already obtained an SPF pass from an earlier matching mechanism. Neither setting guarantees inbox placement. Diagnose the envelope identity, DKIM and DMARC rather than using a stricter suffix as a spam-folder cure.

Publish both DKIM aliases

Copy each generated selector owner and CNAME target exactly. Do not assume that every account uses the same selector name, account number or SendGrid-style destination. Both documented DKIM records are required even if one test message uses only one selector. Vendasta record inventory

Check whether the DNS host automatically appends the domain. If it does, enter the relative label rather than a full name that becomes duplicated. Publish at the actual delegated zone where applicable. For illustrative owner ISSUED_SELECTOR._domainkey.mail.example.com, use ISSUED_SELECTOR._domainkey.mail in zone example.com, ISSUED_SELECTOR._domainkey in separately delegated mail.example.com, or ISSUED_SELECTOR in delegated _domainkey.mail.example.com. Replace the placeholder with the account-issued selector. Preserve NS delegations and publish with their authoritative operator; parent-zone data cannot override a delegated child. No private signing key belongs in DNS.

For an account-requested SPF TXT owner example.com, the relative owner is blank/@ in that zone. For mail.example.com, use mail in parent zone example.com or blank/@ in delegated mail.example.com. Match the actual account requirement and observed SPF identity; these examples do not establish a universal Vendasta Return-Path.

If a requested owner already has an A, TXT or CNAME record, first identify the application using it. A CNAME cannot coexist with ordinary data at the same owner. Obtain a supported alternative or an approved migration; do not delete a website record or another sender’s key just to satisfy the new form. DNS CNAME rules

With Cloudflare, keep authentication CNAMEs DNS only. Check both the record-level Flatten control and the zone-wide CNAME flattening for all CNAME records setting: either can hide a required alias. Turn a relevant per-record Flatten control off when available and ensure applicable whole-zone flatten-all behavior does not suppress the issued literal CNAME answers. Mandatory apex or same-zone flattening can still apply: if a required alias cannot remain visible, stop and coordinate a supported configuration rather than inventing an override. See Cloudflare's controls and exceptions. Coordinate any shared zone-setting change with the DNS owner and assess other services first. If the subdomain is delegated to another DNS host, preserve that delegation and publish at its authoritative host rather than deleting the NS record. Cloudflare’s verification troubleshooting

Preserve DMARC and confirm the real alignment path

Vendasta explicitly says its displayed DMARC record is a recommendation: an existing valid DMARC policy can satisfy verification. Do not replace your approved policy or reporting arrangement with a suggested p=none record. Keep a single DMARC policy at the applicable _dmarc owner. Existing-policy compatibility

Only if there is no direct or applicable inherited policy, the domain owner approves, and a named owner has a monitoring/follow-up plan should a first monitoring policy use a shape such as this. Replace the owner and reporting mailbox; it is not a record supplied for your account. Never override inherited protection with a weaker child policy.

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX

Replace YOUR_APPROVED_REPORT_MAILBOX with the mailbox address only, not another mailto: prefix. For apex From example.com, _dmarc.example.com maps to relative _dmarc. For From mail.example.com, _dmarc.mail.example.com maps to _dmarc.mail in parent zone example.com, or _dmarc in delegated mail.example.com. These are alternative zone mappings, not instructions to publish duplicate records. p=none does not turn failed authentication into a pass or guarantee delivery.

For a report destination in a different Organizational Domain from the policy domain, the report-generating receiver must check destination DNS authorization. A destination within the same Organizational Domain is excepted: different hostnames alone do not make a destination external. Coordinate required authorization with the destination operator. RFC 9990 section 4 This DNS check does not replace domain-owner approval to share aggregate traffic data and identifiers. Keep recipient, access and retention decisions with that owner; do not remove reporting merely to silence volume or add failure reports without separate privacy approval.

DMARC compares the visible From domain with authenticated identities:

• SPF uses the SMTP MAIL FROM domain, usually shown by Return-Path and smtp.mailfrom. It does not authenticate Reply-To. For a null reverse-path, SPF uses HELO. SPF identity definitions
• DKIM uses the signature’s d= signing domain; s= identifies its selector. DKIM verification
• At least one mechanism must both pass and align. Relaxed alignment accepts the same organizational domain; strict aspf=s or adkim=s requires exact equality for that mechanism. DMARC alignment

For a hypothetical passing DKIM signature, visible From offers@example.com and d=mail.example.com align relaxed but not strict; d=example.com with that same From aligns in both modes. Apply the comparison to the actual intended Vendasta signature, not a guessed account identity. Likewise, a child envelope domain may align with an apex From under relaxed SPF alignment but not strict.

A provider-domain SPF pass alone may be unaligned with the client’s From domain. An aligned branded DKIM signature can still satisfy DMARC. Confirm what the actual message used; a green DNS row cannot answer that question.

Domain-wide enforcement is a separate decision from onboarding Vendasta. Inventory and test other legitimate senders first. RFC 9989 requires valid DKIM signatures for domains publishing p=reject, not sole reliance on SPF, and warns about indirect-mail interoperability. DMARC enforcement considerations

Verify public DNS, then finish platform verification

Use these read-only command templates after replacing uppercase placeholders. AUTH_NS is an authoritative nameserver for the relevant zone. Run the DKIM queries for each supplied selector.

dig NS YOUR_DNS_ZONE +short
dig @AUTH_NS SPF_OWNER TXT +noall +answer
dig @1.1.1.1 SPF_OWNER TXT +noall +answer
dig @AUTH_NS DKIM_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 DKIM_CNAME_OWNER CNAME +noall +answer
dig @1.1.1.1 DKIM_CNAME_TARGET TXT +noall +answer
dig @1.1.1.1 _dmarc.YOUR_FROM_DOMAIN TXT +noall +answer

The expected evidence is one valid SPF policy at the intended owner, both DKIM owners resolving to the issued targets and then public keys, and the intended DMARC policy. Follow CNAME chains rather than treating the alias alone as a key. For subdomains, check applicable parent-policy discovery if no explicit DMARC record is present. DMARC policy discovery

An empty filtered result is not a diagnosis. Rerun without +noall +answer, distinguish a missing record from SERVFAIL or a timeout, and compare authoritative and recursive answers. Several quoted chunks within one TXT record are not necessarily multiple records.

In Partner Center, confirm all four rows have Current value entries, the domain’s overall state is verified and the authorization warning has cleared. Vendasta allows up to 72 hours for Partner Center verification; the Business App guide describes usual 24–48-hour DNS propagation. Investigate a wrong name or missing second selector immediately rather than repeatedly waiting or recreating records. Partner verification, client verification

Test campaigns and client notifications separately

Have the authorized owner send harmless content to a controlled external mailbox using the exact intended route. Test a partner campaign, any affected partner notification and each relevant client notification separately. Where a client WordPress form is the problem, use an approved controlled submission through that form, not a partner marketing preview.

Keep the provider/account, selected market, sender, message type and timestamp with these observations:

Use the receiving system’s trusted Authentication-Results, not a header supplied by an unknown upstream sender. A DKIM key in DNS does not prove the message was signed with it. Redact customer content before sharing evidence. Trusted authentication results

A client form can show Delivered in WordPress Hosting Email History because the recipient server accepted it, yet still be in junk or quarantine. The official troubleshooting workflow directs you to authenticate the client domain in Business App. Do not count an agency-domain verification badge as that client’s result. Website-form delivery diagnosis

If DMARC passes through aligned SPF but branded DKIM fails, record the DMARC outcome and fix DKIM rather than declaring the entire setup complete. If all authentication passes but the message is junked, investigate content, reputation, consent and receiving policy separately. No authentication result guarantees placement.

Decide whether this route is ready

For this branded DKIM-enabled setup, accept the route only when the intended branded DKIM signature passes and aligns, the trusted receiver reports DMARC pass, and the observed From is the originally intended identity. A substituted grey-label/provider From or a default shared-domain message does not prove branded success. This operational acceptance bar is stricter than DMARC’s minimum rule, which can be satisfied by either aligned mechanism.

Inspect SPF independently even if aligned DKIM supplies DMARC pass. An SPF pass that is unaligned is an identity-design observation, not an SPF failure; record it and confirm the intended envelope configuration. Actual fail, softfail, permerror or temperror needs investigation of the real envelope domain, authorization and DNS evaluation. Specifically, fail means authorization failed for that evaluated sender; temperror is a transient evaluation/DNS problem to investigate and retry; permerror means an invalid policy/evaluation such as duplicate SPF, malformed syntax or exceeded lookup budget. Keep these separate from simple lack of alignment. SPF result definitions A passing DKIM result does not repair an SPF error. Resolve the problem or record an explicitly accepted, understood route-specific exception before rollout. Do not broaden SPF authorization indiscriminately.

To establish which authentication result is trustworthy, confirm with the receiving mail administrator or provider documentation where authentication is evaluated and how externally supplied Authentication-Results fields are stripped or distinguished. A familiar authserv-id, a convincing hostname or its position near the top of the message alone is not sufficient proof of origin. If that trust boundary is unknown, keep the result unverified and request receiver-side evidence. RFC 8601 forged-header precautions

An illustrative client-form case makes the boundary concrete: an agency is verified in Partner Center, but info@client.example belongs to an unverified client Business App. Email History says Delivered, while folder and received authentication results are unknown. The client owner must authorize its domain and inspect a controlled notification. Neither agency verification nor Delivered closes the client setup. This is a written example, not an executed test.

Keep one handoff row per account/domain/route with business and DNS owners, approved change, intended and observed From, envelope/SPF result, each DKIM d=/s= result, active alignment mode, receiver boundary, timestamp, platform state, placement and next action. Mark missing evidence unknown, not pass. See raw DKIM versus aligned policy results.

Troubleshooting and safe recovery

When a change fails, pause the affected campaign or notification and restore only the approved previous configuration if necessary. A known-good shared-domain mode may be an option only if the owner accepts its changed sender identity and it is supported for that route. Do not silently switch a client’s branding.

Retain DNS keys needed by queued messages or other applications. Never remove the entire SPF or DMARC policy to undo one integration. After rollback, test both the repaired route and any previously working route touched by the change. Preserve the redacted evidence and unresolved questions for the account owner and Vendasta support.