Quentn SPF, DKIM and DMARC setup, step by step

To authenticate Quentn email with your own domain, confirm the sender address, add the domain under Email → Verified domains, and publish the DNS records shown for that domain. Return to Quentn to check verification, then inspect a delivered campaign for a passing DKIM signature aligned with your intended From domain. Address confirmation, DNS verification and message authentication are separate checks. Quentn sender setup, domain verification.

Choose the Quentn sending route first

This guide covers Quentn newsletters and automated marketing email using a domain your organization controls. It also explains the separate Quentn-domain sender option. It does not authenticate your employee mailbox service or mail sent independently by WordPress, membership software or another application.

In Emails → Senders, add a sender email. Choose Default for an address at your own domain, complete its details, save it and confirm the message sent to that inbox. The Quentn domain choice instead supplies an address under quentn-mail.de and asks for a forwarding destination, which must also be confirmed. Owning a Gmail or other freemail inbox does not give you permission to publish DNS for that provider's domain. Sender types and confirmation.

For the branded route, write down the exact From address, domain, campaign owner and reply destination. Check the sender selected in existing campaigns, not just the account default. A successful authentication test does not prove that replies reach the right team, so include a harmless reply test in your implementation plan.

For the separate Quentn-domain forwarding option, obtain the mail owner’s approval of the exact forwarding recipient before selecting or activating it. Mailbox confirmation proves access, not approval to forward organizational replies. Match the configured destination to the approved recipient and stop on a mismatch; keep the branded sender route separate.

You need access to Quentn's domain-verification area and an administrator who can edit the authoritative DNS zone. Find that DNS host before preparing changes. It may differ from your registrar, website host or previous provider.

Get the current domain-specific DNS instructions

Open Email → Verified domains → + Create domain, enter the intended domain and create it. Open the domain's blue verification/edit control to see the DNS instructions. Record each owner name, record type and complete target or value. After publication, use the displayed verification check and confirm the domain's resulting status. Quentn verification workflow.

The official guide's current example screen shows two DKIM CNAME owners, qdkim1._domainkey and qdkim2._domainkey, an additional qrxemh CNAME, and a DMARC TXT suggestion. These illustrate the workflow, not a universal record set. Targets are partly cropped in the image: copy the complete values from your account, not the screenshot. Publish every required generated record, including both DKIM records when shown. Official verification screenshot.

A DKIM CNAME delegates public-key lookup to the supplied target. You do not paste a new independently generated public key into that CNAME, and you never publish a private key. Do not infer the additional CNAME's exact runtime identity merely from its label; verify the envelope domain in a received message.

If your account shows a different record set, that account's instructions govern. A collision with existing DNS, an unavailable verification control or an unclear requirement is a reason to ask Quentn Support for account-specific clarification, not to invent a selector or delete another sender's record.

Publish DNS at the correct owner name

Save the existing records and TTLs before editing. In a DNS editor, the host/name identifies where the record lives; the value/target is the data Quentn supplied. A hostname does not include https://, an email address or a URL path.

These are owner-name examples only. Use them if the account actually issues the illustrated selector, and substitute your domain:

The second selector follows the same construction. If Quentn supplies qrxemh for mail.example.com, its full owner is qrxemh.mail.example.com: enter qrxemh.mail in the parent zone or qrxemh in the delegated child zone. An editor that requires full names uses the full owner instead. Avoid creating qdkim1._domainkey.example.com.example.com through a doubled suffix.

At an existing delegated _domainkey.mail.example.com authority, full owner qdkim1._domainkey.mail.example.com maps to relative qdkim1. Apply the same mapping to the actual second issued selector; preserve NS delegation and other selectors. These are owner examples, not replacement account values. Relative DNS names.

Keep CNAME records DNS-only if your DNS host offers an HTTP proxy. A CNAME owner must not also carry incompatible TXT, A, MX or other data. Preserve other selectors and unrelated verification records. Where a supplied TXT value is split into quoted chunks in DNS output, distinguish one record containing multiple strings from multiple independent records. DNS alias rules, DKIM key retrieval.

Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

Do not change nameservers or replace the domain's MX records just to complete Quentn verification. Apply only the documented records for the intended sending route.

Configure SPF for the actual envelope identity

SPF evaluates the SMTP MAIL FROM domain, usually visible after delivery in Return-Path and the receiver's smtp.mailfrom result. It does not check the visible From: domain. Therefore, adding an include to example.com cannot repair SPF for an unrelated provider-owned envelope domain. SPF identity.

Quentn's general authentication article contains an SPF example, while the verification workflow supplies the current account's records. Do not treat an example include, region label or ?all ending as a standard policy for every Quentn installation. Do not add a simply because you have a WordPress website: the website may send through a separate SMTP provider rather than its public web-server address. Inventory the actual outbound routes first. Quentn's general authentication guidance.

Use this decision sequence:

1. Establish the envelope domain expected for this Quentn route, then confirm it in a delivered message.
2. If the current instructions delegate that name through a CNAME, publish the supplied delegation. Do not add a second SPF TXT record at the CNAME owner.
3. If Quentn specifically requires an SPF TXT change at a customer-controlled owner, merge only its approved authorization into the existing policy. Preserve other active senders and the intentionally chosen final qualifier.
4. If the envelope domain belongs to the provider, investigate provider-side SPF failures with Quentn. Editing your visible From domain will not fix them.

There must be one SPF policy per evaluated owner, not one per service. Check the ten DNS-lookup-causing-term limit across nested includes and redirects. Do not replace managed includes with copied IP addresses without a maintenance plan. SPF publication and limits. If duplicate policies already exist, use the safe SPF merge procedure.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Retain DMARC protection and add useful reporting

Keep an existing approved DMARC policy. Do not replace p=quarantine or p=reject with Quentn's monitoring example, and do not add a second DMARC record alongside the first.

For a domain with no existing applicable policy, the domain owner can plan a monitored rollout. This example is illustrative and requires a working, approved reporting mailbox:

Publish this first monitoring example only when no direct or applicable inherited policy exists and the domain owner explicitly approves the monitoring and review plan. Preserve any established protection and use a provisioned, approved reporting recipient; planning a rollout alone is not authorization to publish it.

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

For the apex From domain example.com, enter _dmarc in a zone-relative editor for the example.com zone. For a From domain of mail.example.com, the explicit policy owner is _dmarc.mail.example.com. In the example.com zone its relative name is _dmarc.mail; in a separately delegated mail.example.com zone it is _dmarc. Review the organizational-domain policy and inherited behavior before creating a child policy.

DMARC passes when SPF or DKIM both passes authentication and aligns with the visible From domain. Relaxed alignment allows the applicable organizational-domain relationship; strict alignment requires an exact domain match. For this setup, require the intended branded DKIM signature to pass and align even if SPF already supplies a DMARC pass. Domains using p=reject must not rely on SPF alone. DMARC alignment and deployment considerations.

p=none is monitoring, not spoofing enforcement. A rua request is needed for aggregate reports. An external reporting service can receive them when the required destination authorization is in place; reporting is not restricted to same-domain mailboxes. Keep report access controlled and investigate absent reports rather than assuming no mail was sent. Aggregate reporting, missing-report diagnosis.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Do not tighten a shared domain's policy based only on a Quentn campaign. Include employee mail, website forms, password resets, billing, forwarding and mailing-list use in the review.

Verify public DNS, then verify a delivered campaign

Check each published record

The following read-only examples assume the illustrated selectors for mail.example.com. Replace every example name with the exact account-issued name. They are commands to run during implementation, not results observed for this article.

dig +short NS example.com
dig +short NS mail.example.com
dig @ns1.dns-host.example qdkim1._domainkey.mail.example.com CNAME +noall +answer
dig @1.1.1.1 qdkim1._domainkey.mail.example.com CNAME +noall +answer
dig @1.1.1.1 qdkim1._domainkey.mail.example.com TXT +noall +answer
dig @1.1.1.1 qdkim2._domainkey.mail.example.com TXT +noall +answer
dig @1.1.1.1 qrxemh.mail.example.com CNAME +noall +answer
dig @1.1.1.1 _dmarc.mail.example.com TXT +noall +answer
dig @1.1.1.1 _dmarc.example.com TXT +noall +answer

Replace ns1.dns-host.example with an actual authoritative nameserver. If mail.example.com is not delegated, its records may be served by the parent zone; an empty child NS answer alone does not mean the records are missing. Check all generated entries, follow CNAMEs to the public-key TXT response and compare authoritative answers with recursive answers after cache expiry. Query the actual observed envelope domain's TXT record as well.

A CNAME pointing to the wrong tenant target is not success. Neither is a key at the wrong selector. For an empty answer, distinguish absent data from NXDOMAIN, SERVFAIL and a timeout before blaming propagation. A DNS response proves availability of data, not that Quentn signed a message with it.

Inspect the message from the intended workflow

Have an authorized campaign owner send harmless content to a controlled external mailbox using the real campaign or automation route. Open the raw message and use the receiving system's trusted Authentication-Results, not a sender-inserted assertion. Authentication-results trust.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Capture the following without exposing recipients or message content:

A passing provider-domain signature does not substitute for the branded signature you configured. Similarly, DMARC can pass through SPF while the intended DKIM setup is still broken. Use the selector-from-message guide if multiple signatures make the result unclear.

Repeat with a representative automation as well as a newsletter if both matter. Keep the time, route, account state, DNS evidence and redacted header results together. No single sample proves every future campaign or recipient path.

Troubleshooting Quentn authentication

Quentn itself distinguishes technical setup, data quality and content in its spam troubleshooting guidance. If a change breaks a working route, pause that route, compare the saved DNS state and restore only the affected change after checking dependencies. Recheck and retest; keep old DKIM records while delayed mail may still need them.

Documentation and verification limits

This is a documentary setup guide, not a customer-account test. No Quentn configuration, DNS change or test send was performed. Your current generated values, public records, campaign selection and recipient-side results must be checked during implementation.