[ Email sender guides ]

QuoteWerks QuoteValet SPF, DKIM and DMARC setup, step by step

By the EmailAuth research team · 10 min read

On this page

For an existing activated QuoteValet account on QuoteWerks version 24 build 4.01 or later, the documented Simple DKIM Relay uses the SPF authorization include:azure.quotevalet.com and a CNAME from qwtenant._domainkey beneath your sending domain to qwtenant._domainkey.quotewerks.com. Configure the approved Email Domain under Setup > Options > QuoteValet > Email Settings, choose Use DKIM Relay (Simple) and save with OK. Then use the native Send Test Email panel and inspect the actual received message.

These DNS constants are published by QuoteWerks for this Simple route. Your domain and authorized From address are your own inputs, not values to copy from a screenshot. DNS publication, choosing the signing mode and delivered-message authentication are separate checks.

This guide excludes Advanced DKIM Relay, private-key generation/upload, external mailbox SMTP, purchases, subscription activation and quote/payment operations. No customer DNS, account or sending tests were performed. Official QuoteValet setup instructions.

Confirm eligibility and the intended sender

The official instructions require version 24 build 4.01 or higher for DKIM Relay. This guide assumes your QuoteValet subscription and tenant connection are already activated and authorized. If the feature is absent or your version is older, establish eligibility with the account owner or QuoteWerks before proceeding; do not purchase, upgrade, enter credentials or activate a subscription merely to follow this article.

In Email Settings > General, QuoteValet distinguishes several sender behaviors:

  • Use the Sales Rep’s email address when sending automated emails from QuoteValet to the customer uses the address in the sales rep’s My Preferences. If that option is unchecked, the documentation says those emails use DoNotReply@quotevalet.com.
  • The legacy option to use a customer’s address when emailing the sales rep is explicitly not recommended by the provider. It is not part of this guide.
  • An override From address for internal sales-rep notifications is a separate setting, not permission to change every notification’s identity.

Confirm the exact authorized sales-rep address and domain for the route you intend to authenticate. The source refers to My Preferences under both Setup and Tools in different passages; use the current account’s corresponding preferences screen to inspect the address. Do not alter unrelated profiles or impersonate a customer.

Simple DKIM Relay makes authenticated branded sending possible; it does not mean every notification automatically uses your chosen brand identity. Any change to the customer-bound sales-rep option or internal override needs its own explicit owner approval. A provider-owned From that authenticates successfully is not proof that your original branded From works.

Prepare the DNS and activation change

Have the account and DNS owners approve the intended domain, native Simple relay mode and sender identity. Identify authoritative DNS, not merely the registrar or website host. Save the existing relevant TXT, CNAME and NS records, and identify direct and applicable inherited DMARC policy.

Before publishing the DKIM alias, check whether its owner already exists. A shared selector or namespace may support other services. Do not overwrite it, remove a delegation or change website/mail routing to make this guide fit. There is no MX or nameserver migration in the documented Simple workflow.

Keep these fields distinct:

Field Value or source Meaning
Email Domain Your explicitly approved sending domain User-supplied configuration, not a provider sample
SPF authorization include:azure.quotevalet.com Fixed provider-published mechanism for this route; merge safely
DKIM relative owner qwtenant._domainkey Fixed Simple-mode selector owner beneath the approved domain
DKIM CNAME target qwtenant._domainkey.quotewerks.com Fixed provider-published destination, not your own domain
Test Email FROM An authorized address whose domain matches Email Domain Required by the native test panel
Test Email TO A valid controlled recipient approved for this test A real send, not a passive lookup

Check the current Simple instructions against your account before applying these constants. If they differ, stop and resolve the discrepancy with QuoteWerks. Do not invent another selector or borrow an Advanced-mode key. Provider configuration reference.

1. Add QuoteValet to the appropriate SPF policy

The Simple instructions require this authorization in the approved domain’s SPF policy:

include:azure.quotevalet.com

This is a mechanism, not a complete TXT policy. Find the existing TXT record beginning v=spf1 at the approved owner. Add the mechanism to that single policy while preserving other legitimate senders, intended qualifiers and policy semantics. Do not replace a Google, Microsoft or other working configuration with a standalone QuoteValet example.

If no SPF policy exists at that owner, have the owner approve a complete policy appropriate to all legitimate senders before publishing it. The provider’s sample new record is not a universal organizational policy. Never add two v=spf1 policies at the same owner.

Evaluate the entire resulting policy against SPF’s limit of ten evaluated DNS-dependent terms, including nested mechanisms. This is not merely ten include strings. An all mechanism causes redirect to be ignored, so appending a redirect after all is not a way to extend that policy. Qualifiers alone do not guarantee rejection or inbox placement. SPF specification, RFC 7208.

SPF authenticates the actual SMTP MAIL FROM domain, or HELO in relevant cases, not automatically visible From. Follow the provider’s domain-authorization requirement, then inspect the actual envelope identity on the delivered test. The public Simple instructions do not establish a customer Return-Path configuration procedure; do not invent one.

2. Publish the Simple-mode DKIM CNAME

For the illustrative sending domain example.com, the complete DNS relationship is:

Type: CNAME
Full owner: qwtenant._domainkey.example.com
Target: qwtenant._domainkey.quotewerks.com

Replace only the illustrative sending domain with your approved Email Domain. The qwtenant selector and the quotewerks.com target above are provider-published constants for Simple mode, not placeholders or per-tenant values.

Map the full owner to the authoritative zone correctly. For an approved sending domain of sales.example.com:

  • In a suffix-appending editor for the parent example.com zone, use qwtenant._domainkey.sales.
  • If sales.example.com is separately delegated, edit that child zone and use qwtenant._domainkey.
  • If _domainkey.sales.example.com is separately delegated, use qwtenant in that authoritative namespace.

Some editors accept full names instead. Check the resulting published full owner rather than assuming the input convention. Preserve NS delegations, other selectors and shared dependencies. Do not accidentally create example.com.example.com or edit the parent when the child is authoritative.

A CNAME owner cannot also contain conflicting TXT, A, AAAA, MX or another CNAME. If the required owner is occupied, stop for a supported resolution; do not delete a working record or choose a new selector without provider support. Simple mode uses this CNAME, not an additional DKIM TXT key at the same owner.

Keep the literal CNAME answer visible. Use DNS-only rather than an HTTP proxy. If a relevant per-record flattening control hides the alias, turn it off where supported and approved; check applicable zone-wide, apex and same-zone behavior too. Do not disable flattening globally without an assessed change. If mandatory behavior prevents the required answer, stop and coordinate a supported setup. For Cloudflare, consult its current flattening controls and exceptions.

Inspect authoritative and public DNS after publication. The CNAME must resolve to the published target, but successful DNS does not prove the application selected Simple mode or signed a message.

3. Select Simple DKIM Relay and save

In QuoteWerks, open Setup > Options > QuoteValet > Email Settings. Under QuoteValet DKIM Relay, select Use DKIM Relay (Simple) and enter the approved Email Domain. The documented default is Do NOT use DKIM relay, so publishing DNS alone is not the complete activation procedure.

Before saving, review the surrounding General sender settings. Do not copy every checked option in the screenshot: it includes a legacy customer-as-From option that the source itself discourages. Do not enable that option or broadly allowlist inbound QuoteValet messages as part of DKIM setup. Preserve unrelated notification, reminder, payment and security settings.

After the approved DNS and sender configuration is ready, persist the intended Simple-mode change with OK. The full settings screenshot notes that some settings may require logging off and on to take effect; follow the actual application’s requirements if applicable rather than assuming every change needs a restart.

The documentation does not establish a separate Verified, Active or Start signing badge/button for Simple mode. Do not invent one. Confirm the saved mode/domain, then inspect a native test message. Official Simple-mode instructions and screenshots.

4. Use Send Test Email, not a customer quote

The Simple panel has a Test your settings section with Email FROM, Email TO and Send Test Email. Its From-field instruction explicitly requires the address’s domain to match the DKIM domain above.

With approval for the actual send:

  1. Confirm Simple mode and the saved Email Domain.
  2. Enter an authorized Email FROM address in that exact domain. Do not use a customer’s address or a screenshot’s sample user.
  3. Enter one approved, controlled Email TO mailbox whose original-message headers you can inspect.
  4. Select Send Test Email. Use this dedicated test, without uploading a customer document, accepting a quote, converting an order, processing a payment or triggering reminders.
  5. Retrieve the original message and retain the actual From, envelope identity, DKIM signature and trusted receiver results.

For Gmail, QuoteWerks documents opening the test message, selecting the ellipsis menu and choosing Show Original. Read the actual identities and results, not just a screenshot’s PASS labels. Receipt alone is not proof of authentication.

A successful dedicated test establishes evidence for that tested route and identity. It does not certify every customer notification or sales-rep override. Any later test of a specific workflow must be separately approved and use harmless controlled data; do not trigger real commercial commitments to complete an authentication checklist.

5. Check the intended DKIM signature and alignment

Use Authentication-Results produced inside the known receiving service’s processing boundary, with its documented treatment of externally supplied result headers. A familiar authserv-id string or header position alone is not trustworthy evidence. Ignore attacker-supplied or otherwise untrusted result fields.

For newly configured branded DKIM, require:

  • dkim=pass for the intended QuoteValet Simple-route signature, keeping its d= domain and s= selector together. A different passing signature is insufficient.
  • Alignment between that signing domain and the intended visible From under the effective DMARC adkim mode. Relaxed alignment compares Organizational Domains; strict alignment requires exact equality.
  • Trusted receiver dmarc=pass for the intended unchanged From. A DMARC pass supplied only by aligned SPF does not prove this DKIM configuration works.

The vendor reports experience with strict-alignment domains, but that is not a guarantee for your account. Check the actual signature domain and current policy. Separately evaluate SPF against the actual MAIL FROM. Relaxed aspf permits an Organizational Domain match; strict aspf requires the exact From domain. A child envelope identity does not promise strict SPF alignment.

Do not accept a rewritten DoNotReply@quotevalet.com From as successful authentication of your own brand. See raw DKIM versus aligned DKIM results, RFC 6376 and the current DMARC standard, RFC 9989.

Keep existing DMARC protection

QuoteWerks says DMARC changes are generally unnecessary for this setup. Preserve existing direct and applicable inherited policy and approved report destinations. Do not downgrade enforcement, add duplicate DMARC or copy third-party reporting addresses to make a test look successful.

Only when no applicable direct or inherited policy exists, the domain owner approves an initial monitoring policy, and someone will assess results, this minimal example may be appropriate:

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

This is illustrative, not a QuoteValet requirement. For a direct policy on sales.example.com, the full owner is _dmarc.sales.example.com, normally _dmarc in that child zone’s suffix-appending editor. An empty direct lookup does not prove there is no inherited policy. The example includes no report destination; add one only under an approved monitoring and data-sharing plan.

When the report destination’s Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. See RFC 9990, section 4. Protocol authorization does not replace the owner’s privacy approval to share report data.

Troubleshooting

Observation What to check
Simple mode is unavailable Existing subscription/tenant activation and version 24 build 4.01 or later. Do not purchase or change credentials as an automatic fix.
CNAME does not resolve correctly Full owner, authoritative delegation, exact fixed target, collisions, DNS-only and flattening behavior. Preserve other services.
Message still uses provider From Saved relay mode, Email Domain, authorized user preferences and the specific General sender setting. Do not enable legacy customer impersonation.
DKIM absent or failing Intended native route and saved mode/domain; selector/key resolution and possible message modification. DNS publication alone is insufficient.
DKIM passes but DMARC fails Intended signature’s d= versus actual From and effective adkim. A raw pass can be unaligned.
SPF fail Actual envelope policy did not authorize the sending host. Correct the approved policy/route discrepancy. Aligned DKIM can still pass DMARC, but SPF remains a distinct issue.
SPF temperror Temporary DNS evaluation failure; investigate resolution and retry after recovery.
SPF permerror Duplicate policies, syntax or evaluated DNS-term budget, including nested terms. This is not merely propagation.
Authentication passes but delivery differs Actual rejection/filtering diagnostics and message content. Do not disable receiver protections; authentication does not guarantee inbox placement.

Give support only approved, redacted diagnostic details. Do not share credentials, private keys, sensitive quotes, payment information or entire customer messages by default.

[ FAQs ]

Frequently asked questions

Does Simple mode require a private key?

No. This guide uses the provider-published CNAME route. Advanced mode’s private-key workflow is separate and excluded; do not generate or upload a private key for this procedure.

Can I add a second SPF record just for QuoteValet?

No. Reconcile include:azure.quotevalet.com into the single approved SPF policy at the relevant owner, preserving other legitimate senders and the evaluated lookup budget.

Is publishing DNS enough to enable signing?

No. Select and save Use DKIM Relay (Simple) with the approved Email Domain, then test the actual native route. No separate verified badge is documented.

Does this guide certify a live configuration?

No. It is a documentary content foundation, not an automated configuration tool or a live customer test. Actual account state, approved DNS changes and received-message evidence still need verification.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base