HappyFox SPF, DKIM and DMARC setup, step by step

To authenticate HappyFox Managed outbound email, open your channel’s DNS Verification panel and complete ownership, SPF, DKIM and DMARC verification. Use the records displayed for that account, including the SPF alignment CNAME and all five DKIM CNAMEs. Verify a delivered support reply before treating the setup as successful. HappyFox channel setup

This guide covers the current HappyFox Help Desk Managed workflow, documented in October 2026, on plans other than Basic. Custom SMTP, Classic Channels and HappyFox Service Desk are different configuration paths. No customer account, DNS zone or delivered message was tested.

Choose the correct sending route

An email channel has two separate jobs: getting customer mail into tickets and sending replies out. A successful forwarding test proves the first, not outbound authentication. Record the channel address, outgoing method and account region before changing DNS. You need an address you own and control, permission to configure its forwarding, and access to the authoritative DNS host for outgoing setup.

For the current experience, use Channels > Email > Email Addresses, select the channel, then choose Configure under HappyFox Managed. If your channel uses Custom SMTP Server, authenticate the actual SMTP provider instead and follow its sender-authorization rules. Do not assume a Gmail or Microsoft mailbox used for incoming tickets also sends the replies. Channel setup and transport options

Older Classic Channels DKIM instructions describe two selectors with US/EU targets. Those instructions must not replace the five-record panel in the current Managed flow. If your screen differs, identify the product and channel experience with HappyFox support rather than mixing record sets.

Prepare a safe DNS change

Find the authoritative DNS host from your domain’s nameservers. The company that registered the domain is not necessarily the company serving its DNS. Export or record the current TXT, CNAME and DMARC values with their TTLs before editing.

For each proposed record, write down its full owner name, type, value and purpose. A DNS editor may append the zone automatically: a relative name such as selector._domainkey can already become selector._domainkey.example.com. Inspect the saved full name instead of repeatedly trying different forms. For a child signing domain mail.example.com, full owner selector._domainkey.mail.example.com is selector._domainkey.mail in the parent example.com zone, or selector._domainkey inside a delegated mail.example.com zone. If _domainkey.mail.example.com is independently delegated, use selector inside that zone. Follow existing NS authority; do not remove delegation to force a record into the parent zone. These are name-handling examples, not HappyFox-issued selectors. DKIM key discovery.

Keep these boundaries intact:

• One SPF policy beginning v=spf1 at each owner name, not one per sending service. Unrelated verification TXT records can coexist.
• A CNAME must not compete with a TXT or another ordinary record at the same owner. Investigate a collision before deleting anything.
• Do not change MX records to repair outbound authentication or overwrite another service’s selectors.
• Keep the existing DMARC policy and reporting destinations unless their owner approves a separate change.

Verify domain ownership

In the channel’s Domain Ownership section, copy the displayed TXT owner and complete verification token. Add it as its own TXT record, then use Verify Ownership after it is publicly visible. The token proves control of the domain to HappyFox; it is not an SPF policy or DKIM key. Ownership instructions

HappyFox allows up to 48 hours for ownership verification and recommends waiting at least 30 minutes before retrying. Do not paste that token into the SPF string. If verification fails, compare the actual public owner name and token with the panel, including any automatically appended domain suffix.

Configure SPF and its alignment CNAME

Expand SPF Verification. The current panel supplies a TXT policy and a separate alignment CNAME. Publish the CNAME exactly as shown, using DNS-only rather than proxy mode where applicable. Merge the required SPF authorization into an existing policy instead of adding another v=spf1 record. Use TTL 3600 or the DNS host’s default for the panel’s TXT and CNAME records. Click Verify SPF Records afterward. The official completed-state screenshot labels the repeat action Re-verify SPF records. Current SPF instructions

The October 22 official body illustrates include:spf.happyfox.com for US-hosted accounts and include:spf.happyfox.net for EU-hosted accounts. Confirm your panel and region before using either. Do not substitute old static IP examples or an include from a different account generation.

Preserve existing legitimate senders and the intended final all qualifier. Count nested DNS-querying SPF terms: RFC 7208 limits evaluation to ten such terms, not ten top-level includes or ten DNS packets. An added include can exceed the limit through its dependencies. SPF evaluation rules

Any all mechanism causes redirect= to be ignored, and mechanisms after all cannot match. Preserve an intentional redirect-based policy instead of silently disabling it while merging. An SPF qualifier expresses an authentication result, not a guarantee of delivery. SPF all and redirect, RFC 7208 §5.1.

SPF checks the envelope MAIL FROM identity, normally reflected in Return-Path, rather than simply the visible From address. For a null reverse-path, the applicable identity is HELO. SPF identities. The alignment CNAME is therefore a separate operational requirement; a valid root-domain policy alone does not prove that a particular reply aligns.

Publish all five DKIM CNAMEs and enable signing

Expand DKIM Verification and copy every displayed CNAME key/target pair. Publish all five without deriving missing targets from examples. HappyFox specifies TTL 3600 or the DNS host’s default, and DNS-only mode for Cloudflare. Return to the panel and click Verify and Enable DKIM; the official completed-state screenshot shows Re-verify DKIM records for subsequent checks. Current DKIM instructions

For Cloudflare, keep every required literal CNAME DNS only, not Proxied. Turn the per-record Flatten option off where available. Whole-zone flatten-all must also be off if it would suppress these aliases; coordinate affected services before changing shared behavior. Per-record choices do not override whole-zone flatten-all. Apex flattening is mandatory, and same-zone targets may be flattened regardless of settings. If literal aliases cannot safely remain visible, stop and ask HappyFox for a supported alternative owner/configuration. Do not delete another service, replace NS delegation or disable security controls to get verification green. Cloudflare flattening controls, CNAME verification behavior.

These aliases let receiving systems find the signing service’s public keys. They are not private keys, and a generic online key generator cannot configure HappyFox’s managed signer. Keep the complete set even if only one selector appears on today’s test message.

HappyFox warns that an uncompleted DKIM verification can cause outgoing mail to use a generic HappyFox address instead of the channel’s custom domain. Treat that as a sender-identity failure, not proof that your custom address is authenticated.

DKIM signs selected message headers and body content; it does not encrypt the message or guarantee that a recipient trusts its content. DKIM specification

Preserve DMARC while completing verification

HappyFox checks for an existing DMARC record and does not require a specific policy value. Use Configure DMARC Policy > Verify DMARC Setting after confirming the published policy. HappyFox allows up to 48 hours for DMARC visibility and recommends a retry after at least 30 minutes. Do not replace an established p=reject or p=quarantine policy with a monitoring example to get a green check. HappyFox DMARC verification

DMARC passes when either SPF passes and aligns, or DKIM passes and aligns, with the visible From domain. Relaxed alignment allows the same organizational domain; strict alignment requires an exact match. Both SPF and DKIM passing for unrelated provider domains is insufficient. Current DMARC standard, RFC 9989

For an illustrative reply with visible From support@example.com, a passing intended HappyFox signature d=mail.example.com aligns under relaxed adkim=r when both share the same Organizational Domain, but not under strict adkim=s. Passing d=example.com aligns in both modes. An unrelated passing signature or rewritten generic From cannot satisfy custom-domain acceptance. DKIM alignment, RFC 9989 §4.4.1.

Only when no existing or inherited policy applies, and the domain owner approves a first monitoring policy, consider the following illustrative TXT record at full owner _dmarc.example.com (relative _dmarc inside example.com):

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

For child From domain mail.example.com, its full DMARC owner is _dmarc.mail.example.com: relative _dmarc.mail in the parent zone, or _dmarc inside a delegated child zone. Do not create a monitoring child exception to inherited protection. Replace the example address with an approved reporting destination. p=none requests no DMARC-based disposition; it does not guarantee delivery. Review all legitimate senders before enforcement. Do not use the obsolete pct tag as a percentage-rollout control under RFC 9989.

Aggregate reporting requires an authorized receiving destination and a privacy decision. If the report destination is in a different Organizational Domain from the policy domain, the receiving report generator must check external-destination authorization before sending reports. A destination within the same Organizational Domain is the exception. An rua address alone does not grant external authorization; use the actual Organizational Domain determination, not a last-two-label guess. External report authorization, RFC 9990 §4. Failure reports can expose message information; keep that separate from approval for aggregate reports.

Check public DNS, then a real support reply

Replace these illustrative names with full names from the panel. Repeat the CNAME query for the alignment owner and every DKIM owner:

dig TXT example.com +short
dig CNAME alignment-owner.example.com +short
dig CNAME selector._domainkey.example.com +short
dig TXT _dmarc.example.com +short

Expect one SPF policy at its intended owner, exact CNAME targets, and one applicable DMARC policy. Follow the DKIM CNAME chain to the public-key TXT answer. Several quoted chunks on one TXT answer line can be one logical record; concatenate its component strings without inserting spaces, not as separate independent TXT records. DKIM TXT syntax. Empty short output is inconclusive: run the query without +short to distinguish no data from NXDOMAIN, SERVFAIL or a timeout. Check the authoritative server and a public resolver if they disagree; cached old data can remain until its TTL expires.

Then send a harmless reply through the actual channel to an external mailbox you control. Inspect the raw message using the final trusted receiver’s Authentication-Results, not an arbitrary earlier header that a sender could supply. Establish the receiving service’s actual processing boundary using its documentation or administrator-confirmed mail path, including how it removes or distinguishes forged incoming result fields. An authserv-id string or topmost position alone is not proof of origin. If provenance is uncertain, obtain receiver-admin confirmation before accepting the test. Retain this acceptance checklist:

1. The visible From address is the intended support address, not a generic fallback.
2. spf=pass identifies the actual smtp.mailfrom domain; compare it with From using the effective aspf mode.
3. dkim=pass identifies the expected signing domain (header.d or signature d=), with a selector matching a published record.
4. dmarc=pass applies to the intended header.from domain. At least one authenticated identity aligns under the actual policy.
5. A customer reply reaches the expected ticket, separately confirming incoming routing.

For custom-domain completion, require the intended branded DKIM signature to pass and align with the visible From under the effective adkim mode, as well as receiver-confirmed dmarc=pass. DMARC success carried only by SPF does not prove that DKIM setup is complete. Investigate the actual envelope identity and sending IP if SPF returns fail, permerror or temperror, even when aligned DKIM allows DMARC to pass. Distinguish a forwarding-related SPF failure from an incorrect original-sender policy, and distinguish persistent syntax/lookup errors from temporary DNS failures. Authentication-Results trust boundary

For interpreting a raw passing signature separately from its policy alignment, see raw DKIM results versus aligned DKIM policy results.

Repeat for other channels, brands and automated notification paths you use. A provider verification badge cannot certify all of them, and a passing message does not guarantee inbox placement.

Troubleshoot the failing layer

SPF verifies but DMARC fails: compare the envelope domain and signing domain with the visible From. Check the alignment CNAME and strict alignment settings before adding more SPF includes.

DKIM remains pending: check all five owners, exact targets, DNS-only status and suffix duplication. HappyFox allows up to 72 hours for DNS propagation; waiting will not repair a typo or conflicting owner. Escalate persistent failure with record names and verification screenshots, not credentials.

Mail arrives from a generic address: revisit DKIM activation and the channel’s outgoing selection. Keep the intended custom From as an explicit acceptance condition.

Tickets arrive but replies fail: forwarding and outbound delivery are independent. If Custom SMTP is selected, inspect provider authorization, permitted From addresses and connection errors rather than replacing Managed DNS records.

Authentication passes but mail lands in spam: inspect receiver feedback, content, recipient expectations and sending reputation. Do not weaken DMARC as a general spam-folder fix.

For recovery, restore only the records changed in this work after checking intervening edits. Pause the affected sending path if needed; do not delete the whole channel or downgrade domain-wide policy as a first response.