Resources · 34
Improve email sender trust and deliverability
Check sender identity, message classes, unsubscribe behavior and rejection causes.
· 7 min
What this guide helps achieve
- Map flows
- Authenticate domains
- Enable withdrawal
- Diagnose rejections
Quick check
- Which systems send under the domain?
- Do real messages pass the expected SPF, DKIM and DMARC checks?
- Is each message promotional or transactional?
- Does required unsubscribe work?
- Are rejections grouped by cause?
Step-by-step method
- 01
Inventory sending
Separate newsletters, automations, receipts and alerts. Record domain, provider, volume, purpose and owner for each flow.
Deliverable: flow and domain map.
- 02
Check authentication
Test SPF, DKIM, DMARC and From-domain alignment on delivered samples. An expected DNS configuration does not prove every sending path works.
Deliverable: inspected headers and authentication results.
- 03
Match recipient expectations
Check sign-up, frequency, promised content and the separation of promotional and transactional traffic. Avoid unexpected promotion in service messages.
Deliverable: rules per message class.
- 04
Test withdrawal
For applicable promotional mail, verify a visible link and one-click behavior matching provider requirements and RFC 8058. Test that removal is actually processed.
Deliverable: end-to-end unsubscribe evidence.
- 05
Watch reputation
Track permanent and temporary rejections, complaints and recipient-provider signals. Analyze by flow and provider instead of a global average.
Deliverable: non-delivery cause analysis.
- 06
Fix and retest
Address authentication, unqualified lists, technical errors and broken unsubscribe first. Raise volume gradually where the context requires it.
Deliverable: correction plan and observed result.
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Authentication | Real messages with expected SPF/DKIM/DMARC results | Fix sending path |
| Rejections | Rate and causes by flow | Clean list or repair |
| Withdrawal | Promotional requests applied | Fix headers and processing |
| Complaints | Reports tracked per campaign | Revise targeting and frequency |
Common pitfalls
- Assuming published DNS proves every flow
- Mixing transactional and promotional mail
- Confusing an open with inbox placement
- Showing an unsubscribe link that does not actually remove a recipient
Frequently asked questions
Is SPF alone sufficient?
No. Recipient requirements vary by volume and context; check DKIM, DMARC and applicable alignment too.
Does every message need one-click?
Provider rules distinguish promotional and transactional messages, so classify each flow first.
Does an open prove delivery?
No. Open metrics have their own limits and do not replace delivery outcomes.
Email security: identity, alignment and transport
Domain authentication, transport confidentiality and inbox placement are different questions. SPF, DKIM and DMARC inform domain identity; MTA-STS and DANE concern server-to-server connections; reports help observe failures. None of these signals proves a message is benign.
References and status checked on .
Which mechanism answers which question?
| Mechanism and source | What is checked | Where to find evidence | Limit to retain |
|---|---|---|---|
| SPF | Authorisation of the sending IP for the SMTP envelope domain; DMARC uses MAIL FROM. | The evaluated domain’s TXT record and receiver result. Evaluation allows 10 DNS-querying terms, rather than simply 10 network requests. | Forwarding may change the observed IP. Selecting multiple SPF records produces permerror; an SPF pass does not prove alignment with From. |
| DKIM | Cryptographic verification of signed message parts for the signature’s d= domain. | DKIM-Signature, selector s=, domain d= and key under selector._domainkey. RFC 8301 requires RSA ≥ 1,024 bits, recommends ≥ 2,048 bits and excludes rsa-sha1. | A valid signature from another domain may not satisfy DMARC. Changes to signed parts can break verification; DKIM does not encrypt the message. |
| DMARC | Links the visible From domain to at least one SPF- or DKIM-authenticated, aligned identifier. | The TXT policy discovered through _dmarc and trustworthy results produced at reception. Record alignment mode and the domain actually evaluated. | A pass neither guarantees delivery nor endorses content. Receivers retain local policy; DNS errors and non-conforming messages require separate handling. |
| DMARC aggregate / failure reports | Observation of streams using the domain: aggregate statistics and, separately, details about failing messages. | rua / ruf destinations, covered period and received reports. Their formats are now specified in separate RFCs published in May 2026. | Missing reports do not prove no mail was sent. Detailed reports may expose message data; define suitable access, minimisation and retention. |
| MTA-STS | Recipient-domain policy for SMTP TLS transport and expected MX hosts. | _mta-sts TXT, HTTPS policy at /.well-known/mta-sts.txt and certificate. Three modes: testing, enforce and none. | Applies to supporting servers and transport, without end-to-end encryption. Initial discovery and caching have their own limits. |
| TLS-RPT | Reporting of successful and failed TLS negotiation or validation between servers. | _smtp._tls TXT, reporting destinations and received JSON data, correlated with transport logs. | Observation does not enforce encryption. TLS reports and DMARC domain-identity reports describe different events. |
| DANE for SMTP | TLS transport authentication using DNSSEC-protected TLSA records. | Validated DNSSEC chain, SMTP service TLSA record and a match with the presented certificate or key. | DNSSEC validation is required on this path. DANE does not validate From or replace SPF, DKIM and DMARC. |
| ARC | Carries authentication assessments along paths involving intermediaries. | ARC header sets, chain validation and a trust decision about intermediaries. | RFC 8617 is Experimental. ARC is not a trust framework and does not automatically make a message safe or deliverable. |
DMARC in 2026: documentation changes
- Reference
- RFC 9989, published in May 2026, replaces RFC 7489 and RFC 9091. Aggregate and failure reporting are separated into RFC 9990 and RFC 9991.
- Discovery and alignment
- The specification defines DNS Tree Walk discovery. Do not infer organisational domains by naively retaining the final two labels.
- Testing a deployment
- pct is removed; the new t=y requests handling one level below the published failure policy: reject becomes quarantine, and quarantine becomes none. t=n is the default.
- Interoperability
- The standard advises against p=reject for general-purpose email domains. Inventory forwarding and mailing lists and check actual implementations before changing policy.
Publication of an RFC does not show that every provider already implements that version. Check documentation, observed results and exceptions in your own streams. These examples are educational and provide no ready-to-deploy DNS record. RFC 9989 →
Understand DMARC logic with a scenario
Simplified model: a conforming From message, an already discovered DMARC policy, one SPF MAIL FROM result and one examined DKIM signature. You supply alignment based on the evaluated domains and mode. The tool performs no DNS resolution or signature verification and predicts no delivery.
(SPF pass AND aligned) OR (DKIM pass AND aligned)
With multiple DKIM signatures, check each result / d= pair: one valid, aligned signature can suffice. Never combine one signature’s pass with an aligned domain from another failing signature. DNS discovery errors, absent policy and invalid From fields are outside this model. All choices stay in your browser.
Six educational cases, readable without JavaScript
| Scenario | SPF: result / alignment | DKIM: result / alignment | Expected interpretation |
|---|---|---|---|
| Aligned SPF is sufficient | pass — authenticated Yes | fail — observed failure No | pass — at least one authenticated and aligned path The SPF path meets both conditions. |
| Aligned DKIM is sufficient | fail — observed failure No | pass — authenticated Yes | pass — at least one authenticated and aligned path The DKIM path meets both conditions independently of the other path in this model. |
| Two passes without alignment | pass — authenticated No | pass — authenticated No | fail — no authenticated and aligned path in this scenario Two third-party domains passing technically does not validate From. |
| Aligned domains, no authentication | fail — observed failure Yes | fail — observed failure Yes | fail — no authenticated and aligned path in this scenario A matching domain does not replace successful authentication. |
| Incomplete evidence | Result not supplied Alignment not supplied | fail — observed failure No | Undetermined — complete the observations Missing evidence on one path cannot be invented. |
| Proven DKIM, unknown SPF | Result not supplied Alignment not supplied | pass — authenticated Yes | pass — at least one authenticated and aligned path One complete positive result suffices even when the other path is unknown. |
Prepare an actionable email review
| Stream | Evidence to correlate | Useful decision |
|---|---|---|
| Alerts, receipts and resets | Provider and From domain, envelope and DKIM identities, tracking ID, SMTP response and available delivery event. | Separate transport failure, authentication error and absence of reading. Define an alternative for a critical service. |
| Campaigns and newsletters | Domains and subdomains, alignment results, representative samples from every platform, withdrawal mechanism and stream-specific errors. | Repair the affected sending path before changing a global policy; do not equate authentication with recipient expectations. |
| Forwarding and mailing lists | Path before and after the intermediary, message changes, SPF/DKIM outcomes and ARC information when present. | Explain the observed break and local policy; do not assume a valid ARC chain compels acceptance. |
| Transport to MX hosts | Relevant MTA-STS policy or TLSA, certificates, DNSSEC validation for DANE, TLS reports and timestamped logs. | Associate failures with the relevant host and period. Test changes within authorised scope and retain rollback. |
Continue with domain and DNS governance →
Primary sources and publication dates
Dates below identify RFC publication months, separately from the consultation date. Descriptions and cases are editorial summaries rather than complete normative extracts.
- SPF · RFC 7208 · Proposed Standard · Publication :
§3.2, §4.5, §4.6.4 - DKIM · RFC 6376 · Internet Standard · Publication :
§3, §6 - DKIM cryptography · RFC 8301 · Proposed Standard · Publication :
§3.1–3.2 - DMARC · RFC 9989 · Proposed Standard · Publication :
§4.4, §4.7, §4.10, §5.3.5, §5.4, appendix C - DMARC aggregate reports · RFC 9990 · Proposed Standard · Publication :
§2–3 - DMARC failure reports · RFC 9991 · Proposed Standard · Publication :
§2–3; privacy considerations - MTA-STS · RFC 8461 · Proposed Standard · Publication :
§3, §5, §10.2 - SMTP TLS Reporting · RFC 8460 · Proposed Standard · Publication :
§3–4 - DANE for SMTP · RFC 7672 · Proposed Standard · Publication :
§2, §3 - ARC · RFC 8617 · Experimental · Publication :
§2, §7, appendix A.2
Official references
Continue exploring
Related analysis
