How to set up DMARC/DKIM/SPF for SDR Force
SDR Force needs three layers working together: SPF authorizes SDR Force's sending infrastructure for your envelope sender, DKIM signs each message with your domain, and DMARC tells receivers how to handle mail that fails alignment. I set this up by adding the sending domain in SDR Force, publishing the DNS records SDR Force gives me, then checking real outbound mail until SPF or DKIM passes DMARC alignment.
Use SDR Force's in-app records
Public SDR Force authentication examples are not consistently published, so the DNS values inside your SDR Force workspace are the values to trust. The record shapes below show what to expect, but the exact hosts and targets need to come from SDR Force.
Add your domain
Start inside SDR Force, not DNS. I only add DNS records after SDR Force has generated the domain verification, SPF, return-path, and DKIM values for the exact domain that will appear in the visible From address.
- Open settings: Sign in to SDR Force as an admin and open the area named Domains, Sending Domains, Email Accounts, or Deliverability.
- Add domain: Enter the organizational domain, such as example.com, unless SDR Force tells you to authenticate a dedicated subdomain.
- Choose sender: Connect the mailbox or outbound identity that SDR Force will use for sequences and replies.
- Copy records: Keep the SDR Force DNS panel open and copy each hostname, record type, and value exactly.
- Wait to verify: Do not click final verification until DNS has propagated for the verification TXT record and DKIM records.
SDR Force screen for adding a sending domain before DNS verification.
The domain you add here needs to match the domain in the From address used by SDR Force. If SDR Force sends from sales.example.com, authenticate that subdomain. If it sends from jane@example.com, authenticate example.com.
|
|
|
|---|---|---|
TXT | Root | SPF |
CNAME | DKIM | Signing |
TXT | _dmarc | Policy |
CNAME | Bounce | Alignment |
Compact DNS map for SDR Force authentication records.
Set up SPF
SPF for SDR Force matters because SDR Force supports return-path alignment. That means the envelope sender can use a domain you control, so SPF can pass and align with the visible From domain under DMARC.
- Find SPF: In SDR Force, open the sending domain and locate the SPF or return-path record.
- Check existing: Look for an existing SPF TXT record at the root of your domain before adding anything.
- Merge senders: Add SDR Force's include to the existing SPF record instead of creating a second SPF TXT record.
- Keep limit: Stay under the 10 DNS lookup limit after adding SDR Force and the rest of your senders.
- Verify path: Send a test email and confirm the Return-Path domain aligns with your From domain.
SPF pattern when SDR Force provides an includeDNS
v=spf1 include:spf.sdrforce.com include:_spf.example.net -all
Use the exact include or CNAME that SDR Force shows. The example above is only the shape of a merged SPF record. If SDR Force gives you a custom bounce or return-path CNAME instead, publish that CNAME as shown and keep your root SPF focused on providers that send directly as your domain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After the SPF checker can see one valid SPF record, send a real SDR Force message and inspect the authentication results. SPF alone is not enough for DMARC unless the envelope sender domain aligns with the From domain.
SDR Force SPF and return-path record screen for a sending domain.
Do not publish two SPF records
Two SPF TXT records at the same hostname cause SPF permerror. Merge SDR Force into the existing record, then remove the duplicate.
Set up DKIM
DKIM is the main authentication mechanism I rely on for SDR Force because it survives forwarding better than SPF and gives DMARC a clean aligned pass when the DKIM signing domain matches your From domain.
- Open DKIM: In the SDR Force domain screen, expand DKIM and copy every selector shown.
- Create records: Add each DKIM CNAME or TXT record in DNS exactly as SDR Force displays it.
- Avoid nesting: If your DNS provider auto-appends the domain, enter only the host prefix SDR Force gives you.
- Keep both: If SDR Force provides two selectors, publish both so key rotation and redundancy work.
- Verify header: Send a message and confirm the DKIM d= domain matches or sits under your From domain.
DKIM CNAME patternDNS
sdrforce1._domainkey.example.com. CNAME sdrforce1._domainkey.sdrforce.com. sdrforce2._domainkey.example.com. CNAME sdrforce2._domainkey.sdrforce.com.
The selector names above are examples. In production, I copy the selectors from SDR Force and then confirm that the outbound message has a DKIM-Signature header with the same selector and an aligned signing domain.
SDR Force DKIM selector records for a sending domain.
Good DKIM result
- Pass: The DKIM signature validates against the public key in DNS.
- Aligned: The DKIM signing domain matches your visible From domain under relaxed alignment.
- Stable: Both SDR Force selectors resolve and can survive key rotation.
Bad DKIM result
- Missing: The selector host does not resolve because the DNS name was entered twice.
- Unaligned: The DKIM d= domain belongs to SDR Force instead of your domain.
- Broken: A mail gateway changes the message body after SDR Force signs it.
Set up DMARC
DMARC belongs at _dmarc on the same domain used in the visible From address. For a new SDR Force rollout, start with p=none so you can collect reports before enforcing. If your domain already uses p=quarantine or p=reject successfully, keep that stronger policy and fix SDR Force until it passes.
Starter DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use the DMARC record generator if you need to build the TXT value with reporting addresses, subdomain policy, or percentage rollout. Keep the first SDR Force test simple: one aligned SPF pass or one aligned DKIM pass makes DMARC pass.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After the record resolves, send SDR Force mail to a mailbox that exposes authentication headers. The result you want is DMARC pass, with either SPF aligned or DKIM aligned. DKIM aligned is the stronger signal for SDR Force because it does not depend on the bounce path surviving every hop.
SDR Force domain authentication overview after DNS records verify.
DMARC pass condition
SDR Force mail passes DMARC when SPF passes with aligned return-path, or DKIM passes with an aligned signing domain. You do not need both to pass, but I prefer both for resilience.
Verify and troubleshoot
Do not stop at green DNS checks inside SDR Force. I verify with a real outbound message because DNS can be correct while the actual message still signs with the wrong domain, uses the wrong return-path, or routes through a mailbox provider before SDR Force applies authentication.
- Send test: Send a live SDR Force email from the same mailbox and domain used in outreach.
- Read headers: Check Authentication-Results for SPF, DKIM, and DMARC verdicts.
- Check alignment: Confirm SPF uses your return-path domain or DKIM uses your signing domain.
- Fix DNS: Correct doubled hostnames, duplicate SPF records, missing DKIM selectors, and stale cached values.
- Retest mail: Send a fresh SDR Force message after each fix instead of reusing an old header.
The quickest verification path is to send a test message to an email tester and read the full diagnosis. This checks the live message, not just DNS.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
When SDR Force supports return-path alignment, SPF failures need attention. If SDR Force ever sends a flow that does not support return-path alignment, expect SPF alignment errors on that flow and rely on aligned DKIM instead.
Authentication target before enforcement
Use this benchmark after SDR Force has sent real mail for several days.
Ready
98-100%
Legitimate SDR Force mail passes DMARC consistently.
Investigate
90-97%
Some SDR Force mail passes, but one flow or mailbox still fails alignment.
Do not enforce
Below 90%
Major SDR Force flows still fail SPF and DKIM alignment.
Common SDR Force failure patterns
- SPF permerror: Your domain has duplicate SPF records or too many DNS lookups.
- DKIM none: The selector host is wrong or DNS has not propagated.
- DMARC fail: SPF or DKIM passes, but the passing domain does not align with the From domain.
- Header mismatch: The mailbox connected to SDR Force sends through another provider first.
Get alerted when it breaks
SDR Force authentication can break after a DNS cleanup, mailbox change, sender rotation, SPF edit, or DKIM key change. Manual checks catch setup mistakes, but they miss the day a working sender starts failing.
- Watch sources: Track SDR Force as a verified sending source and separate it from mailbox, CRM, and billing mail.
- Alert fast: Trigger notifications when SDR Force DMARC pass rates drop or new IPs appear.
- Detect drift: Compare source IP, DKIM selector, return-path, rDNS, and policy results over time.
- Check reputation: Monitor blocklist (blacklist) hits for domains and IPs tied to SDR Force campaigns.
This is where Suped's product is the strongest practical choice for most teams. It brings DMARC monitoring, SPF and DKIM diagnostics, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist and blacklist monitoring, and actionable alerts into one workflow.
For SDR Force, I care most about alerts that name the failing source and show the fix path. A generic daily XML report is too slow when outbound campaigns are running every business day.
Manual monitoring
- Slow: You inspect DNS and headers after someone notices a problem.
- Fragmented: SPF, DKIM, DMARC, and reputation data sit in separate places.
- Reactive: Campaign problems surface after failed delivery or poor engagement.
Suped monitoring
- Actionable: Issues include the affected source and the steps to fix it.
- Unified: DMARC, SPF, DKIM, MTA-STS, and reputation checks sit together.
- Scalable: MSPs and agencies can monitor many SDR Force customer domains from one dashboard.
Secure your domain with p=reject
Do not move to p=reject the same day you add SDR Force. I enforce only after every legitimate source, including SDR Force, passes DMARC consistently and unknown sources have been identified or removed.
- Start none: Use p=none while SDR Force sends enough real volume to prove alignment.
- Authorize sources: Confirm every legitimate sender has aligned SPF or aligned DKIM.
- Fix SDR Force: Resolve any SDR Force return-path, SPF lookup, DKIM selector, or signing-domain issue.
- Stage policy: Move to quarantine first if your domain has complex mail flows.
- Reject fully: Publish p=reject after legitimate failure volume is low and explained.
Policy rollout path
A practical enforcement path after SDR Force authentication is stable.
DMARC pass rate
Suped's hosted DMARC makes this policy staging easier because the policy can be managed without repeated DNS edits. Suped also flags the specific source causing the failure, which matters when SDR Force shares the domain with mailbox, support, and transactional mail.
Do not enforce over unknown failures
If SDR Force still appears as an unverified source or fails both SPF and DKIM alignment, p=reject can block legitimate outreach. Fix the source first, then enforce.
