CoffeeCup SPF, DKIM and DMARC setup, step by step

Quick answer: For forms actually sent through CoffeeCup S-Drive, CoffeeCup documents include:newsletter.coffeecup.com as its SPF authorization. Add it to the appropriate existing SPF policy, not a second policy. Use a From address on a domain you control. This does not configure DKIM: the reviewed instructions do not establish a native S-Drive customer-domain DKIM issuance or activation procedure. Confirm that separately with CoffeeCup before promising complete branded authentication.

This guide is based on provider documentation and protocol standards. No customer account, DNS change, form submission or delivered message was tested.

First identify which CoffeeCup route sends the message

A form's appearance does not identify its mail transport. Use this distinction before changing DNS:

CoffeeCup's sending-rules article, distinguishes S-Drive authorization from Email Designer's external-provider route. This guide deliberately covers the former, not every CoffeeCup application or hosting arrangement. Plan, region and administrator-role restrictions are not established by that article; check your account's actual capabilities rather than inferring them from a product name.

Prepare both form email paths

A submitted form can produce two different messages: a confirmation to the visitor and a notification to the form owner. Test them independently. A confirmation appearing on the webpage is not proof that either email was sent or authenticated.

In Web Form Builder, CoffeeCup's form-settings guide shows Settings → Confirm Email and Notification controls. Its screenshots distinguish the visitor's address used as a recipient or Reply-To from the From field. Use an approved address on your own domain as From. Do not impersonate the visitor's Gmail, Yahoo or corporate address as the sender merely to make replies convenient. Where the notification's Reply-To control is available, use the visitor field there instead, with appropriate validation.

Confirmation email is optional: in Confirm Email, select the visitor email field in To to enable it. An empty dropdown can mean the form has no email element, or that the element is behind a display rule. Resolve that form configuration before diagnosing a missing confirmation as an SPF failure.

After an approved change to the form's identity or email settings, save the project, confirm its S-Drive destination under Form Publishing, and use the Publish toolbar control to update that published form before testing. Do not test an older published copy and assume it contains your edits. A DNS-only policy edit does not itself require republishing an unchanged form.

The settings guide is an older interface reference, not a guarantee of current button placement. If your version differs, obtain current instructions from CoffeeCup rather than changing unrelated mail settings. Preserve the form project and its published configuration before editing. Use a controlled, non-payment test form with synthetic data and authorized recipients so testing cannot trigger an order, charge, mailing-list subscription or customer notification.

Confirm the SPF identity and DNS owner

SPF checks the SMTP MAIL FROM, often represented after delivery by Return-Path, rather than automatically checking the visible From address. HELO applies in the relevant empty-envelope case. CoffeeCup's instructions ask for an owned From domain but do not establish a universal S-Drive envelope domain. Obtain that detail from a representative received message or current CoffeeCup guidance before treating an SPF edit as a verified remedy.

If the evaluated domain belongs to CoffeeCup, adding SPF at your own domain cannot change the SPF result for CoffeeCup's domain. Ask how the intended custom-domain route is supported. Do not invent a custom return-path setting or claim that a successful DNS lookup proves the form uses that identity.

For a confirmed customer-controlled SPF owner, locate its authoritative DNS host and export the current policy. The website host, registrar and DNS host may be different. Record the approved change, owner, TTL and rollback plan. Preserve other authorized services and unrelated TXT records.

For example, if the approved SPF owner is forms.example.com, a relative-name editor for the example.com zone normally uses forms. In a separately delegated forms.example.com zone it uses the apex representation, often @ or blank. A full-name editor uses forms.example.com. These are naming examples, not a claim that S-Drive always uses this subdomain. SPF does not inherit from a parent domain.

Publish the native S-Drive SPF authorization

The provider's documented mechanism is:

include:newsletter.coffeecup.com

It is an SPF mechanism, not a DKIM key, standalone DNS hostname or CNAME target. The provider's fresh-policy example is:

v=spf1 include:newsletter.coffeecup.com -all

Use that complete example only if the intended owner has no SPF policy, CoffeeCup is its only authorized sender, and the domain administrator approves that policy ending. Otherwise merge the mechanism into the existing policy while preserving all legitimate senders and approved qualifiers. Do not paste an example over an established policy.

1. Confirm S-Drive is the authorized sending route and identify the exact owner discussed above.
2. Query its TXT records and locate the existing v=spf1 policy, if any.
3. Have the domain administrator review the consolidated policy, including nested dependencies and any managed-SPF service.
4. Publish one SPF TXT policy at that owner. Leave unrelated TXT records intact. Put authorized mechanisms before the terminal all mechanism; do not append them after it.
5. Recheck authoritative DNS and independent recursive resolvers, allowing old cached answers to expire.
6. Test fresh confirmation and notification messages through the same published S-Drive form.

RFC 7208 limits evaluated DNS-dependent mechanisms and modifiers to ten, including nested processing; it is not simply a limit of ten visible includes. An all mechanism causes redirect to be ignored. If the existing policy uses a managed redirect, stop and coordinate the change with that policy's administrator rather than inserting all or replacing the redirect blindly. -all means SPF fail for unmatched sources; it does not dictate every receiver's final delivery decision.

Do not add TXT at an owner already occupied by a CNAME, remove an NS delegation, change MX, or disable DNSSEC to make an example fit. Resolve a naming or delegation conflict with the relevant administrators. This native SPF procedure requires no guessed DKIM selector or customer-created signing key.

If ordinary employee mail also uses Google Workspace, retain its authorization and review EmailAuth's Google Workspace guide for that separate route. A working employee-mail test does not certify an S-Drive notification.

DKIM remains a separate question

The reviewed S-Drive SPF article supplies no customer DKIM selector, public key, CNAME packet or signing-activation workflow. That is an evidence limit, not proof that the service cannot support DKIM. Ask CoffeeCup specifically:

• Can this S-Drive form route sign with a domain aligned to our intended From domain?
• Who issues its exact public DNS records, and who verifies publication and activates signing?
• What envelope identity will each form-email type use, and is a custom envelope identity supported?
• What account or plan conditions and rollover procedures apply?

Do not borrow another customer's key, generate a key that CoffeeCup has not agreed to use, or treat a signature under CoffeeCup's domain as proof of your own domain's alignment. If CoffeeCup supplies a supported DKIM procedure, handle it as a separate approved change with exact records and provider activation instructions. A newly configured branded DKIM route is complete only when its intended signature passes and aligns and the trusted receiver reports DMARC pass. SPF-only DMARC pass does not prove DKIM works.

Verify received messages, not just DNS

Submit the controlled form after the approved change. Record separate results for visitor confirmation and owner notification. Inspect the authentication results produced inside the receiving service's known processing boundary, using its documented handling of externally supplied Authentication-Results. Header position or a familiar server-name string alone cannot establish trust. Ignore attacker-supplied result headers; RFC 8601 explains this boundary.

Under RFC 9989, relaxed alignment compares Organizational Domains, while strict alignment requires identical domains. For example, bounce.example.com and example.com can align under relaxed SPF alignment but not strict alignment. Those are hypothetical identities, not S-Drive values. An SPF pass under an unrelated provider domain cannot by itself authenticate your visible From for DMARC.

Preserve any existing direct or inherited DMARC policy and authorized report destinations. Do not weaken enforcement to get a form delivered. The CoffeeCup article's fo= explanation should not be used as an authentication switch: failure-report options do not turn SPF or DKIM checking on or off. This guide intentionally supplies no replacement DMARC policy or reporting address.

If adding aggregate reporting later, obtain the domain owner's approval for sharing and retention. A destination in a different Organizational Domain from the policy domain requires DNS authorization checked by the report-generating receiver; a destination within the same Organizational Domain is excepted from that external authorization requirement. DNS authorization does not replace privacy approval. See RFC 9990, section 4.

Troubleshoot the failed observation

For escalation, supply CoffeeCup the product/version, S-Drive form location, affected email type, test timestamp, sanitized error and relevant authentication identities. Avoid sending visitor submissions, credentials or private keys. Roll back only the specific mistaken change under the saved plan, preserving concurrent authorized edits; removing the CoffeeCup authorization can affect other S-Drive forms sharing that policy.