A cold outbound team can publish SPF, DKIM, and DMARC, run an SPF DKIM DMARC test, see three green indicators, and still watch replies disappear. Gmail may place the messages in Promotions while Outlook sends them to Junk, even though the DNS records look correct. The missing check is usually alignment, not whether SPF and DKIM pass in isolation.
That distinction changes the troubleshooting process. A useful test follows the message from DNS to the receiving mailbox, then uses Authentication-Results and DMARC aggregate reports to confirm that the authenticated domains match the visible From domain. The sections below apply that workflow to the failures that routinely survive basic validators.
When Authentication Is Set Up but Emails Still Go to Spam
A cold email team launches a new sequence from [email protected]. The domain has an SPF record, the marketing platform has enabled DKIM, and DMARC exists with p=none. A basic validator returns green checkmarks, so the team blames the subject line, the offer, or the copy when reply rates fall.
The more useful question is what the receiving server saw. The platform may send with an envelope domain such as mail.example.net, while the visible From header remains [email protected]. DKIM might also sign with the vendor's domain instead of example.com. SPF and DKIM can each pass their own technical checks, yet neither result aligns with the address shown to the recipient. DMARC then fails.
Practical rule: A green SPF or DKIM result isn't enough. The authenticated identifier must align with the visible From domain.
This is why deliverability troubleshooting shouldn't stop at record publication. A DNS checker confirms that records exist and parse correctly. It doesn't prove that the final message uses the intended envelope sender, DKIM d= domain, selector, or From header combination. Those values can change after a campaign platform rewrites the message or routes it through a different sending configuration.
A practical investigation starts with the live message, not the campaign copy. The receiving mailbox's headers reveal the result that matters, including the authenticated domains and the receiver's DMARC decision. Aggregate reports then show whether the issue affects one platform, one subdomain, or the entire sending estate.
Teams reviewing broader inbox placement factors can also consult this guide to improve email deliverability, but authentication should be diagnosed at the receiver before content changes become the default response. The rest of the workflow separates record existence, protocol success, alignment, and policy enforcement so each failure has a clear next action.
What SPF, DKIM, and DMARC Actually Check
SPF is a DNS TXT record that identifies hosts and IP addresses permitted to send mail for a domain. During the SMTP transaction, the receiving server evaluates the envelope sender, also called the return-path or MAIL FROM domain, and compares the connecting server with the published SPF policy. SPF doesn't authenticate the visible From address that appears in the recipient's mailbox.
DKIM adds a cryptographic signature to the message headers. The signature includes a signing domain in the d= tag and a selector in the s= tag. The recipient retrieves the matching public key from DNS and verifies the signature against the signed headers and body. A passing result confirms that the signature can be validated, but the signing domain may still differ from the visible From domain.
DMARC is the policy and reporting layer, not a replacement for either protocol. It evaluates whether SPF or DKIM passes and whether at least one authenticated domain aligns with the domain in the visible From header. NIST describes the logic as requiring only one of SPF or DKIM to succeed, provided the result is aligned. That “or” matters, but it doesn't remove the need to test both paths because forwarding, vendor routing, and message modification can affect them differently. NIST's technical note on DMARC measurement documents why real mail testing should distinguish SPF-only and DKIM-only outcomes rather than assume SPF carries every message.
DMARC also tells receiving systems how to handle failures through p=none, p=quarantine, or p=reject, and it can request aggregate reports through rua. A record with p=none provides observation, not blocking. A record with enforcement can reduce spoofing exposure, but only after legitimate sources authenticate and align consistently.
For teams building a deeper working library, it's useful to browse email authentication posts alongside this more operational explanation. A protocol overview is helpful, but the decisive field in a real test remains the relationship between header.from, SPF's authenticated domain, and DKIM's header.d value. More background on the individual records is available in this SPF, DKIM, and DMARC explanation.
Running the First Round of Tests
A practitioner usually tests in layers. DNS comes first because a missing or malformed record makes every later result difficult to interpret. Live headers come next because they show how the sending platform configured the message.
Start with the published records
Use a DNS lookup tool or a terminal command with +short:
- SPF:
dig TXT example.com +short - DKIM:
dig TXT selector._domainkey.example.com +short - DMARC:
dig TXT _dmarc.example.com +short
Replace the domain and selector with the values used by the sending service. The SPF lookup should return one usable SPF policy, the DKIM lookup should return the public key for the selector shown in the message, and the DMARC lookup should return a policy record at the _dmarc host. Multiple SPF records, a missing selector, or a DMARC record with invalid syntax should be fixed before deliverability conclusions are drawn.
An online validator can combine these checks into one SPF DKIM DMARC test and expose syntax problems more clearly than a raw DNS response. It can also flag issues such as multiple SPF records, unresolved includes, or a selector that doesn't exist. Those tools are useful for configuration hygiene, but they still don't replace a received-message inspection.
Inspect the receiver's headers
Send a controlled message through every legitimate platform, including marketing, transactional, support, and sales tools. In Gmail, open the message, choose Show original, and find the Authentication-Results header. Outlook on the web exposes equivalent information through View message source.
Look for fields resembling:
spf=passwith the authenticated envelope domaindkim=passwith the signingheader.ddomaindmarc=passordmarc=failheader.from=example.com
The raw pass values aren't the finish line. Compare the domains in the SPF and DKIM portions with header.from. A message can show spf=pass and dkim=pass while showing dmarc=fail because the authenticated domains don't align.
At this stage, defer policy changes and reputation theories. First identify the exact From domain, envelope domain, DKIM selector, signing domain, and receiver-side result. The next step is aggregate-report analysis, where those isolated messages become a map of all sources claiming to send for the domain. Teams needing a broader delivery workflow can use this practical guide to test email deliverability.
Why SPF and DKIM Can Pass and DMARC Still Fail
DMARC uses the visible From domain as its anchor. SPF authenticates the envelope sender, while DKIM authenticates the domain in the signature's d= value. DMARC passes when at least one of those authenticated domains both passes its protocol check and aligns with the visible From domain.
Consider a message with these values:
- The envelope sender uses
mail.example.com. - DKIM signs with
d=example.net. - The visible From header uses
[email protected].
SPF can pass for mail.example.com, and DKIM can pass for example.net. The cryptographic and sending-server checks are valid for those domains. DMARC still fails because neither authenticated identifier aligns with example.com under the receiver's alignment rules.
Subdomains make the comparison less obvious
DMARC supports relaxed and strict alignment. Relaxed alignment permits the authenticated domain and visible From domain to share the same organizational domain, while strict alignment expects an exact match. A sender using a subdomain can therefore behave differently depending on the domain relationship and the alignment mode published in DMARC.
Third-party ESPs often create this gap by handling transport and signing under their own domain while allowing the customer to display a branded From address. Some platforms offer custom return-path and DKIM signing configuration. Others require separate domain verification or a dedicated sending subdomain. The fix isn't to add more unrelated SPF mechanisms. The fix is to configure the sender so SPF or DKIM authenticates a domain aligned with the visible From address.
The pct tag controls how broadly a DMARC policy applies to failing messages, but it doesn't repair alignment. A lower rollout percentage can reduce the immediate impact of enforcement while the configuration is corrected. It can't turn an unaligned SPF or DKIM pass into a DMARC pass.
The operator's useful question isn't “did SPF and DKIM pass?” It's “which authenticated domain passed, and did that domain align with the final From address?”
Aggregate reports expose this difference at scale. Raw pass counts can make a vendor look healthy, while the alignment fields show that its traffic would fail once the domain moves from monitoring to enforcement.
Reading DMARC Aggregate Reports Like an Operator
A DMARC aggregate report, or RUA report, is an XML summary of messages that claimed to use a domain. The file typically contains report metadata, the published policy, and one or more records grouped by source IP. The useful work is mapping each record back to a legitimate platform, relay, subdomain, or unknown sender.
Read the file in four passes
Start with report_metadata. The org_name identifies the reporting receiver, while the report email and date range show who produced the file and which reporting window it covers. Next inspect policy_published, which shows the domain policy the receiver evaluated, including the policy mode and alignment settings.
Each record then provides the operational evidence:
- Source identity: Read
source_ipand the message count, then map the address to a known ESP, relay, or internal service. - Authentication results: Check the SPF and DKIM result blocks. A pass alone doesn't establish DMARC success.
- Identifiers: Compare the envelope or SPF domain and DKIM domain with the visible From domain.
- Receiver action: Read
policy_evaluated, especiallydisposition,spf, anddkim, to see whether the receiver appliednone,quarantine, orreject.
A healthy source has a recognizable origin and a passing, aligned SPF or DKIM path. A suspicious source may have an unknown source_ip, meaningful volume, repeated SPF failure, or DKIM results that pass for an unrelated domain. A legitimate vendor can also appear unhealthy if its traffic passes technically but fails alignment.
To calculate a source pass rate over the reporting window, divide the number of messages from that source with an aligned DMARC pass by the source's total message count. Keep the calculation separate for each source and date range. A domain-wide average can hide one broken platform behind a large volume of healthy transactional traffic.
| Field | What It Tells You | Red Flag |
|---|---|---|
org_name | Which receiver generated the report | An unexpected reporting organization or missing context |
source_ip | The server or relay that delivered the message | Unknown origin or an address not mapped to a known sender |
count | How much traffic came from that source | High volume from an unapproved platform |
policy_published | The policy and alignment settings evaluated | Policy differs from the intended DNS configuration |
identifiers | The visible From domain and authenticated domains | Domains don't share the expected alignment |
policy_evaluated | SPF, DKIM, and receiver disposition results | Passes that don't produce DMARC alignment |
disposition | What the receiver did with failing mail | Unexpected quarantine or reject affecting legitimate traffic |
RUA reports are more valuable than a one-off validator because they reveal sources the sending team may not know about. They can surface an old application, an unapproved SaaS platform, or spoofing activity that never appears in the controlled test mailbox.
Common Test Failures and How to Fix Each One
Most failures are configuration problems rather than broken cryptography. The fastest diagnosis pairs the symptom with one header, DNS record, or report field.
| Failure | Root Cause | Fix |
|---|---|---|
| SPF returns a permanent error | Nested vendor includes push the evaluation beyond SPF's 10-DNS-lookup limit, or more than one SPF record exists | Inspect the complete SPF evaluation, remove obsolete mechanisms, consolidate records, or delegate senders to dedicated subdomains |
| SPF fails for a new platform | The vendor's sending service isn't authorized in the envelope domain's SPF record | Compare the smtp.mailfrom or return-path value in Authentication-Results with the SPF policy, then add the vendor's approved authorization |
| DKIM fails despite a published key | The selector in the message doesn't match the selector published in DNS | Read DKIM-Signature: s= and d=, then check that exact selector and signing domain in DNS |
| DKIM fails after key rotation | The sender switched keys before the receiver could resolve the new public key, or the old selector was removed too soon | Publish the new public key first, confirm live verification, then retire the previous selector after the transition |
| Forwarded messages fail SPF | Forwarding changes the connecting server and may rewrite the envelope sender | Preserve an aligned DKIM signature where possible, then inspect receiver-side results instead of treating SPF failure alone as proof of spoofing |
| Vendor subdomain isn't covered | SPF policies are published per sending domain, and the vendor may use a subdomain or separate return path | Test the exact envelope domain and configure SPF and DKIM for the domain the platform actually uses |
| DMARC reports never arrive | The rua address is absent, invalid, or unable to receive reports | Check the _dmarc TXT record and send a test report destination through the chosen monitoring workflow |
| The test tool passes but the receiver reports DMARC failure | An upstream system rewrote the From header, return path, or signing identity after the tool's test | Inspect the final Authentication-Results header in Gmail or Outlook and compare header.from, SPF domain, and DKIM d= |
| DKIM passes but alignment fails | The platform signs with its own domain while displaying the customer's domain | Enable customer-domain signing or configure an aligned custom return path |
| SPF and DKIM both pass but DMARC fails | Neither authenticated identifier matches the visible From domain | Treat alignment as the defect, then correct the envelope or DKIM signing domain rather than adding unrelated records |
The first test that catches each failure differs. DNS lookups find missing records and syntax faults. A combined validator finds duplicate SPF policies and unresolved selectors. A live header exposes rewriting and alignment. RUA reports identify unknown senders and show whether the same defect affects real traffic over time.
A common remediation sequence is to inventory every legitimate source, verify DNS syntax, map each platform to its SPF include and DKIM selector, and re-check alignment in aggregate reports before changing policy. Troubleshooting guidance from DMARC Report on aggregate-report issues supports that source-by-source approach.
From Test Results to a Working Authentication Policy
A test result matters only when it changes the domain's policy. Use the evidence to decide whether the domain remains in monitoring, moves to quarantine, or reaches reject. The practical gap is alignment: SPF and DKIM can pass while DMARC still fails if neither authenticated identity matches the visible From domain.
Keep p=none while known senders still fail SPF or DKIM in RUA data, alignment changes between platforms, or unfamiliar systems appear in the reports. Monitoring does not block spoofed mail, but it gives the team time to identify legitimate services and repair their authentication path. The European Commission Joint Research Centre research summarized here illustrates the difference between publishing authentication records and enforcing protection. A DNS record can exist while the mail flow remains exposed.
Set p=quarantine after known sources pass and align across the agreed reporting cycles. The supplied operating threshold is two consecutive weekly RUA cycles with all known sources passing, no spoofing volume above baseline, and stable alignment at 99% or higher. These conditions support a controlled change, not a guarantee. High-volume senders should use pct= to limit the initial impact.
Set p=reject after 30 days of clean quarantine data, review of the reporting address with legal or contractual stakeholders, and confirmation that SPF remains under the 10-lookup limit. Full enforcement is still uncommon. A 2026 global benchmark found 11.6% of domains using a reject policy for full DMARC protection, while 68.4% had no effective DMARC protection, according to the adoption research cited above. The operational lesson is clear: publishing DMARC and enforcing DMARC produce different outcomes.
Before enforcement, check:
- Reporting visibility: Confirm
rua=reaches an address that receives and processes aggregate reports. - Subdomain scope: Review
sp=so subdomains inherit the intended policy. - Rollout pacing: Use
pct=when a high-volume sender needs a gradual policy change. - Final alignment: Compare receiver-side
header.from, the SPF domain, and DKIMd=values instead of relying only on validator status. - Source ownership: Identify every unknown source before classifying its traffic as legitimate.
Teams that do not want to operate DNS, warm-up, reputation monitoring, and reply handling internally can assess managed options. Eludic provides cold email infrastructure support, including SPF, DKIM, and DMARC configuration, inbox warming, sender reputation monitoring, campaign sending, reply handling, and meeting coordination.
Eludic can configure and monitor the authentication layer for a B2B cold email program, then connect those checks with sending, replies, and meeting booking. Visit Eludic to share the company, audience, and pipeline brief and discuss a managed outbound setup.