Authenticate your FireDrum From domain with its DKIM CNAME, finish the account's authentication step, and review the SPF and DMARC records it supplies. Then verify a real campaign's branded DKIM signature and DMARC result. FireDrum requires custom-domain authentication before you can advance beyond the Content step; a free mailbox domain is not a substitute for a domain you control. FireDrum domain authentication
This guide covers FireDrum Email Marketing campaigns using your own From domain. It does not configure your employees' mailboxes, change incoming mail routing or authorize an unrelated application that happens to use the same address.
Prepare the domain and preserve existing mail
Identify the exact domain in the campaign's From address, the FireDrum account using it and the authoritative DNS host. The registrar, web host and DNS operator can be different companies. Obtain permission to edit the correct zone and save the current SPF, DMARC and DKIM records before making changes.
For each sending stream, keep a short worksheet: application, From address, account owner, intended DKIM domain, record names, activation state and latest message-test result. Include other platforms using the domain. This inventory protects invoice delivery and employee mail when a marketing authentication change is made.
If the campaign uses news.example.com, do not assume records for example.com also cover it. Likewise, the website address www.example.com is not normally the domain in newsletter@example.com. Use the sender domain, not the address copied from a browser's location bar.
Add the domain and publish FireDrum DKIM
Open Account → Settings → Authenticated Domains → Add Domain. FireDrum displays the CNAME for the domain. The documented record is:
Type: CNAME
Owner: fd._domainkey.example.com
Target: dkim.firedrumemailmarketing.com
Replace example.com with your actual sender domain and compare the result with the account's record. This is a DNS alias to provider-managed key material, not a TXT public key to paste at the alias owner. FireDrum DKIM procedure
In an editor that automatically appends example.com, use fd._domainkey for that root domain. For From news.example.com inside the parent zone, the relative owner would be fd._domainkey.news. Check the complete saved hostname. A doubled domain suffix will put the record somewhere the receiver never queries.
For an issued signing domain such as news.example.com, a full owner fd._domainkey.news.example.com is fd._domainkey.news relative to the parent example.com zone, or fd._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is fd. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
Keep the alias DNS-only if the DNS service offers web proxying, and exclude it from CNAME flattening. Cloudflare warns that flattening can hide the CNAME required for third-party verification. Cloudflare CNAME flattening Do not add a TXT, A record or second CNAME at the same owner. If fd._domainkey is already occupied, identify the existing service and arrange a supported selector/domain migration rather than replacing it blindly. Other selectors elsewhere in the zone remain untouched. CNAME exclusivity
For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, 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 DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.
Do not copy a public key resolved today into a static TXT record as a shortcut. The CNAME lets FireDrum manage its target. Publish only the requested public DNS information, never account passwords or private keys.
Complete authentication before looking for the remaining records
Return to FireDrum and select Authenticate. The SPF and DMARC entries become available after this stage. Next use Test DNS Records for the domain. It checks DKIM, then DMARC, then SPF, stopping at the first failure. A later result that has not appeared is untested, not necessarily missing from DNS. Authentication and test order
Treat the three checks as dependencies. Resolve the first reported problem, allow relevant caches to expire and rerun the test until all three have results. Do not repeatedly create SPF records because the interface has not reached its SPF check.
The provider allows for DNS delays of 24 hours or more and suggests retrying after an hour. That is not a reason to ignore a wrong authoritative answer: inspect the owner, type and target immediately. Waiting can refresh a cache, but cannot repair a hostname entered incorrectly.
Merge SPF without changing unrelated authorization
FireDrum documents the following example:
Owner: example.com
Type: TXT
Value: v=spf1 mx include:mtas.firedrumemailmarketing.com ~all
Its service authorization is include:mtas.firedrumemailmarketing.com. Merge that mechanism into an existing SPF policy before the terminal all; do not publish another v=spf1 record. The example's mx also authorizes your domain's MX hosts, so retain or add it only when that is part of the approved sending architecture. FireDrum SPF instructions
Preserve existing legitimate senders and the current final qualifier. A guide showing ~all does not authorize weakening an established -all policy. Conversely, do not switch to -all just because a different guide uses it. Keep a single version marker and avoid appending mechanisms after all, where they cannot authorize traffic.
SPF evaluates the envelope MAIL FROM domain, normally visible as smtp.mailfrom in trusted receiver results. It does not directly authenticate the address readers see in From. Query the actual envelope domain when diagnosing a message, even if FireDrum also asks you to publish a policy at your branded domain. SPF policies do not automatically inherit from a parent domain. SPF identities and policy evaluation
The reviewed FireDrum guide does not document a universal customer-configurable Return-Path procedure. Do not invent one. A provider-owned envelope domain may pass SPF without aligning to your brand. Publishing the include at your apex does not change that envelope identity; branded DKIM must be checked independently.
Before saving a merge, evaluate the entire recursive policy. SPF permits at most ten DNS-query-causing terms during evaluation, including nested includes and relevant modifiers. A short top-level string can still exceed this limit. Never remove an active sender or flatten provider IP ranges without understanding the resulting maintenance obligation.
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
Preserve DMARC and set up useful reporting
Read the existing policy for the From domain and any applicable parent policy. Keep established enforcement, reporting addresses and subdomain settings. FireDrum explicitly says an existing DMARC record need not be replaced for its service. Do not add a second policy or use a child p=none record to sidestep inherited protection. FireDrum's existing-policy guidance
For a domain with no established or inherited policy, an approved monitoring rollout can start with this template:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the domain and mailbox with a real, approved reporting destination. At the example.com zone root, the relative owner is _dmarc. A deliberate policy for From news.example.com belongs at _dmarc.news.example.com, entered as _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. Publish one policy at the intended owner.
p=none requests monitoring rather than quarantine or rejection. DMARC passes when at least one passing SPF or DKIM identity aligns with From. Relaxed alignment allows a shared organizational domain; strict alignment requires an exact match. For example, d=news.example.com can align with From example.com under relaxed DKIM alignment, but not strict adkim=s. Current DMARC standard
Make sure reports can actually be received and reviewed. A mailbox name inside a TXT record does not create a mailbox. If the reporting destination is external, complete its required DNS authorization; the report receiver normally supplies or hosts this configuration. Restrict report access because reports reveal sending infrastructure and traffic patterns. Aggregate reporting and external destinations
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
Review all legitimate senders before tightening policy. A successful FireDrum campaign cannot establish that payroll, support or staff mail is ready for enforcement. Current DMARC no longer defines the legacy pct percentage rollout; do not base a new plan on it.
Check DNS before testing a campaign
These are read-only examples. Replace example.com, and use your actual authoritative nameserver for the last query:
dig +short NS example.com
dig +short CNAME fd._domainkey.example.com
dig +short TXT dkim.firedrumemailmarketing.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig @ns1.dns-provider.example CNAME fd._domainkey.example.com
Expect the selector alias to match the account and its target to return a usable DKIM public key, with nonempty p=. Do not compare that changing provider-managed key with an old screenshot. At the SPF owner, expect exactly one SPF policy, although unrelated TXT records may coexist. At the DMARC owner, expect the intended single policy.
An empty +short response is not a diagnosis. Repeat without +short and inspect the status: a timeout or SERVFAIL differs from a name that does not exist. Compare authoritative answers with a recursive resolver. If only cached answers differ, wait for their TTLs; if the authoritative data is wrong, correct the approved record instead.
Require a delivered branded DKIM pass
After account and DNS checks succeed, send a controlled new campaign through the normal sending route to a mailbox where you can inspect its original headers. Test each From domain and separately configured automation or triggered stream you use. A preview, an old message or a green account badge cannot establish current production behavior.
Use the receiving system's trusted Authentication-Results, not a sender-supplied field. Record its spf result and smtp.mailfrom, each relevant dkim result and header.d, plus dmarc and header.from. Match the intended signature to d= and s= in DKIM-Signature; the documented selector here is fd. Authentication-Results trust boundary, DKIM identity and selector
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Accept the setup only when:
- The campaign used the intended From domain and FireDrum route.
- The intended branded DKIM signature passes and aligns under the published
adkimmode. An unrelated passing provider signature is insufficient. - The trusted receiver reports
dmarc=passfor that From domain. - SPF's actual result is understood. A pass for an unaligned provider envelope can be expected architecture;
fail,softfail,permerrorortemperrorneeds investigation rather than being excused by DKIM.
Keep a redacted sample and date for each route. If an actual SPF error remains, record the affected identity, owner and corrective action and keep that part open. DMARC passing through DKIM does not repair broken SPF.
Troubleshoot the result that actually failed
FireDrum stops at DKIM: check the complete fd._domainkey name, alias target, conflicting records and the Authenticate step. Query the target for usable key material; a CNAME alone is not the complete resolution path.
The next failure is DMARC: inspect the exact From-domain owner, inherited policy and syntax. Do not replace an established enforcing record with the example merely to obtain a green check. Escalate the precise validator error if correct policy is not accepted.
SPF fails in delivered mail: inspect the envelope domain and connecting IP. fail or softfail can indicate an unauthorized source; permerror points to issues such as duplicate policies, malformed syntax or lookup limits; temperror points to a DNS/processing failure. Repair the evaluated domain if you own it, or give FireDrum the redacted evidence if it is provider-managed. Check a direct delivery to separate forwarding effects.
DKIM passes for the wrong domain: verify the campaign's account and From selection and whether custom authentication is active. Do not count dmarc=pass through SPF as completion of the intended DKIM setup.
Direct delivery passes but forwarded mail fails: compare the two paths. Forwarding can change the IP evaluated by SPF, and intermediaries can alter signed content. Avoid authorizing an arbitrary forwarder's IP as a first fix.
Documentation and testing limits
No customer account, DNS zone or live campaign was changed or tested for this guide. Complete the account, DNS and delivered-message checks for your own setup. Authentication does not guarantee delivery or inbox placement.