[ Transport security ]

Compare transport-policy failures with authentication failures

Distinguish SMTP transport-policy failures from SPF, DKIM and DMARC results using delivery-stage evidence and trusted observations.

By the EmailAuth research team · 8 min read

[ Key points ]

  • Transport validation and message identity authentication answer different questions.
  • A failed pre-delivery attempt may have no received-message authentication evidence.
  • Repair the failed layer and retest other unresolved layers independently.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

Use route logs and policy evidence for transport failures, trusted message results for authentication, and avoid applying a fix to the wrong layer.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Identify the failed delivery stage

A certificate problem and a selector problem require different evidence.

Next steps

  1. Capture the exact SMTP stage and response.
  2. Record policy type and relevant receiving host.
  3. Compare actual SPF, DKIM and DMARC identities only when observed.

CISO / SecOps

Preserve evidence trust boundaries

A pasted header or aggregate count is not an individual verified trace.

Next steps

  1. Use trusted receiver Authentication-Results.
  2. Keep transport and message-authentication conclusions separate.
  3. Retain cache and observation timing context.

Founder / Non-technical

Assign the right incident owner

A migration can introduce more than one failure at different stages.

Next steps

  1. Identify the affected business workflow.
  2. Track separate transport and sender-identity workstreams.
  3. Require a fresh controlled retest after each approved repair.

[ FAQs ]

Frequently asked questions

Can TLS succeed while DMARC fails?

Yes. TLS protects the connection; DMARC requires aligned passing message authentication for the visible From identity.

RFC 9989

Can a signed legitimate message be delayed by MTA-STS?

Yes. An enforce policy can prevent delivery through a candidate that fails its transport checks regardless of the message’s signature.

RFC 8461

Does a TLS-RPT failure count identify a message’s SPF result?

No. TLS-RPT aggregates transport observations, not message-authentication results for individual business messages.

RFC 8460

Will adding SPF repair an MX certificate mismatch?

No. SPF authorizes the relevant sending identity; the receiving certificate and transport route require separate investigation.

RFC 7208

Is the MX certificate also the DKIM key?

No. DKIM uses its signing domain and selector to locate the public key for the message signature.

RFC 6376

Can a bogus DNSSEC result be treated as absent DANE?

Not under RFC 7672’s error handling. Lookup failures require another candidate or delayed delivery, not a simple no-policy assumption.

RFC 7672

Can I trust any Authentication-Results header in a message?

No. Establish which trusted system added it and the relevant trust boundary. An untrusted origin can assert arbitrary results.

RFC 8601

Does a clean report period prove every route was checked?

No. Aggregate reports reflect participating senders’ observations and may omit unused backups or other traffic.

RFC 8460

[ Sources ]

Sources

  1. RFC 7208

    Sections §4. SPF Evaluation

  2. RFC 9989

    Sections Identifier Alignment

  3. RFC 6376

    Sections §3.5 DKIM-Signature Header Field · §3.6 Key Management and Representation · §6. Verifier Actions

  4. RFC 8461

    Sections §3.3 HTTPS Policy Fetching · §4. Policy Validation · §5. Policy Application · §8.1 Policy Updates

  5. RFC 8460

    Sections §3. Reporting Policy · §4.1 Report Time Frame · §4.3 Result Types · §5.2 Compression · §5.3 Email Transport · §5.4 HTTPS Transport · §5.5 Delivery Retry · §5.6 Metadata Variances · §7. Security Considerations

  6. RFC 7672

    Sections §2.1 DNS Considerations · §2.2 TLS Discovery · §2.2.1 MX Resolution · §2.2.3 TLSA Record Lookup · §3.1 TLSA Certificate Usages · §3.2 Certificate Matching · §4. Server Key Management

  7. RFC 8601

    Sections §1.2 Trust Boundary · §7. Security Considerations

[ Glossary ]

Glossary

Transport-policy failure
A failure of the applicable route or TLS validation conditions for an SMTP connection.

RFC 8461

Alignment
The required relationship between the visible From domain and a passing SPF or DKIM identity.

RFC 9989

Trusted results boundary
The context in which the consumer knows which authentication-results assertions it may trust.

RFC 8601

Cross-layer diagnosis
A proposed investigation that keeps transport and message-authentication evidence distinct.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base