Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Prepare the domain that appears in From
FireDrum requires custom-domain authentication before progressing beyond the Content step of an email. Its documentation excludes free-provider addresses such as Gmail and Yahoo as the From address. Begin with an address on a domain your organization controls, an authorized DNS administrator and a campaign owner who can test the final message.
Inventory existing SPF, DMARC and DKIM records before editing. FireDrum's setup is an addition to your sending ecosystem, not permission to erase other mail services. Agree a test campaign, a small controlled recipient set and a recovery decision before making the change. Keep a record of the exact current DNS state.
Add the domain and configure DKIM first
References: RFC 6376 §3.6.2.
Open Account > Settings and locate Authenticated Domains. Choose Add Domain. The provider displays the DKIM CNAME after the domain is added. Its documented pattern uses fd._domainkey under your domain and the target dkim.firedrumemailmarketing.com. Compare the account's current output with the public instructions and use the supplied values for your domain.
Publish the CNAME at the authoritative DNS host. Check whether the editor appends the zone name automatically, so the final owner does not contain your domain twice. Check for existing data at the selector before adding or replacing anything. Return to FireDrum and choose Authenticate after the DNS record is present.
The documented workflow reveals the remaining SPF and DMARC instructions after this DKIM stage. If those values are not yet visible, resolve the first stage rather than inventing values to force progress. Preserve a copy of the final account-generated record set for review.
Merge authentication records safely
References: RFC 7208 §3.2, RFC 9989 §4.10, RFC 9989 §4.4.
FireDrum's SPF instructions identify include:mtas.firedrumemailmarketing.com. If the relevant owner already has an SPF policy, integrate the permission into that single policy while preserving other authorized senders and the approved terminal policy. Do not paste a second v=spf1 policy alongside it. The documentation's sample contains other mechanisms too; review the complete policy rather than assuming a sample is suitable for every organization.
For DMARC, the provider explicitly says not to create another record if one already exists, and that an existing record need not be changed to use the application. Keep established enforcement and reporting decisions intact. If the domain has no policy, arrange a reviewed initial policy and a real reporting destination instead of publishing an example mailbox that nobody monitors.
A monitoring policy and successful setup checks do not guarantee inbox delivery. SPF authorizes an envelope identity; DKIM validates a signing identity. DMARC requires a passing identity to align with the visible From domain under the applicable mode. Authentication is one input into receiver decisions, not a promise of placement.
Interpret the ordered test correctly
Use Test DNS Records in Authenticated Domains. FireDrum tests DKIM first, then DMARC, then SPF, and stops at the first failure. An absent SPF result after a DKIM failure is therefore not evidence that SPF passed or that its record is missing. Fix the failing stage, confirm authoritative DNS and rerun the test to expose the next stage.
The provider advises allowing time for DNS changes. Distinguish caching delay from a record published at the wrong owner or inactive DNS host. Waiting cannot correct a typo or a conflicting CNAME. Compare the saved account output with authoritative answers before repeatedly changing the configuration.
Verify an actual campaign after DNS passes
References: RFC 9989 §5.3.5.
Send through the intended campaign workflow to a mailbox where original headers are available. Record visible From, envelope domain, every DKIM signing domain and selector, and the trusted receiving system's verdicts. Verify which successful path is aligned instead of inferring alignment from the dashboard's green result.
Illustrative case, not a FireDrum observation: From is news@example.com, SPF passes for unrelated.vendor.example.net and a valid DKIM signature uses d=example.com. DMARC has an exact aligned DKIM path even though the SPF identity is unrelated. If the signature fails, the unrelated SPF pass is insufficient. This distinction prevents unnecessary broadening of SPF when the real defect is signing.
Close the change with an owner and recovery plan
If the test message lacks the expected signature, investigate the actual campaign transport and account configuration before editing unrelated records. If authentication passes but mail is filtered, retain evidence and investigate recipient policy, content and reputation separately. Keep prior DNS values and the approved sending fallback until acceptance is complete.
This guide uses retained first-party procedures and protocol reasoning. No live tenant configuration, DNS publication or delivered campaign was tested. The received-message record, human review and production sign-off remain outstanding; do not label the documentary example a successful customer deployment.