Outbound CompassSPF: authorize sending systems
SPF is a DNS record that lists which systems may send mail for a domain. Receiving servers compare the sending path with that policy. It is especially important when multiple services send on behalf of the same domain because each legitimate source must be represented without creating an invalid record.
SPF does not encrypt the message, prove the sender is a good actor, or guarantee inbox placement. It is one identity signal. Common mistakes include publishing multiple SPF records, exceeding lookup limits through excessive includes, or forgetting that a new sending provider changed the actual source path.
DKIM: sign messages so receivers can verify integrity
DKIM adds a cryptographic signature to outgoing mail. The public key is published in DNS under a selector, and the receiving system can use it to check that the signed portions of the message were not altered and that the sender controls the corresponding key.
DKIM failures often come from a provider not signing at all, using the wrong selector, stale DNS after a migration, or an intermediary modifying signed content. Check real message headers after setup. A DNS record can exist while outbound mail is still not being signed correctly.
DMARC: connect authentication to the visible domain
DMARC evaluates whether SPF and/or DKIM align with the domain shown to the recipient and lets the domain owner publish a policy. It can also send aggregate reports that reveal which systems are using the domain. Alignment is the key concept: passing SPF or DKIM on an unrelated domain is not the same as authenticating the visible From domain.
DMARC should be introduced deliberately. Reporting can help uncover forgotten senders before a strict policy disrupts legitimate mail. The correct policy depends on the whole domain's mail ecosystem, not just the cold-email tool.
How the three protocols fit together
| Protocol | Main job | What it cannot prove |
|---|---|---|
| SPF | Authorize sending infrastructure | Message quality or recipient interest |
| DKIM | Sign and validate message integrity/domain control | That recipients want the mail |
| DMARC | Evaluate alignment and publish policy/reporting | Inbox placement by itself |
Authentication lowers ambiguity about who sent the message. Reputation and recipient behavior determine whether that authenticated sender is trusted. Treating authentication as a deliverability hack misses this distinction.
Basic validation workflow before launch
- Confirm every legitimate sending service for the domain.
- Inspect the published SPF record and make sure it represents those sources.
- Enable DKIM in the actual mailbox provider and publish the correct selector.
- Publish or review DMARC with an appropriate reporting/policy strategy.
- Send a real test message through the exact cold-email path.
- Inspect headers for SPF, DKIM, and DMARC pass/alignment results.
- Re-test after migrations, new sending tools, domain changes, or DNS edits.
Do not rely only on a screenshot taken during setup. The live path is the thing that must authenticate.
What to verify when authentication passes but placement is poor
Passing SPF, DKIM, and DMARC means the message is authenticated; it does not mean the domain has healthy reputation, the list is good, or the message is relevant. Next inspect bounce patterns, account age, volume changes, blacklist/reputation signals, provider-specific placement, content, and recipient responses.
Sources & verification
Product details can change. We used first-party sources for unstable claims on this page.