Skip to main content

IETF · RFC · Email authentication

Email Authentication Standards

Built on IETF open standards — the same specifications that define how mail servers evaluate, sign, and report on message legitimacy. Full visibility into your domain’s compliance posture.

7
Standards monitored
6
Final RFCs
24/7
Continuous checking
0
Fields missed

The standards we monitor

What each RFC means for your mail path — and exactly what DMARC Shield watches.

DMARC

Policy

Domain-based Message Authentication, Reporting & Conformance

RFC 7489 — open specification (opens in new tab)

The unifying policy layer that ties SPF and DKIM together. Domain owners publish p=none, p=quarantine, or p=reject so receivers know what to do when authentication fails, and request aggregate (rua) and forensic (ruf) reports. Without DMARC, receivers apply their own heuristics inconsistently.

What we monitor

  • p= policy changes
  • pct= enforcement ramp
  • rua / ruf destinations
  • Alignment failures & volume trends

SPF

Authorisation

Sender Policy Framework

RFC 7208 — open specification (opens in new tab)

A DNS TXT record listing which IPs and servers may send mail for your domain. Receivers check the connecting IP and apply the qualifier (-all, ~all, ?all, +all). SPF hard-caps at 10 DNS lookups — exceeding it causes PermError and can silently break delivery.

What we monitor

  • Qualifier drift (~all → -all)
  • Lookup-limit breaches
  • Include-chain depth
  • PermError / TempError conditions

DKIM

Signing

DomainKeys Identified Mail

RFC 6376 — open specification (opens in new tab)

Cryptographic signatures on outgoing mail, with the public key in DNS (selector._domainkey). Receivers verify body and selected headers were not tampered with in transit. Multiple selectors support key rotation without downtime.

What we monitor

  • Selector health
  • Key rotation status
  • Signing algorithm strength
  • Body / hash mismatches

TLS-RPT

Transport

SMTP TLS Reporting

RFC 8460 — open specification (opens in new tab)

A reporting channel for SMTP transport security. When senders fail to establish TLS with your mail server — expired certificates, protocol mismatches, or MTA-STS enforcement — they send a JSON report to the rua destination in the _smtp._tls DNS record. Transport failures that would otherwise stay invisible become visible.

What we monitor

  • Report destination validity
  • Failure patterns
  • Certificate issues
  • Policy fetch errors

MTA-STS

Transport

SMTP MTA Strict Transport Security

RFC 8461 — open specification (opens in new tab)

Lets a domain require TLS for inbound SMTP. A _mta-sts DNS TXT record points senders to an HTTPS policy file listing allowed MX hosts and mode (testing, enforce, none). In enforce mode, mail is delivered over TLS only — blocking STARTTLS downgrade and MITM attacks.

What we monitor

  • Mode transitions (testing → enforce)
  • MX list changes
  • Policy file availability
  • TLS failure rates

BIMI

Branding

Brand Indicators for Message Identification

IETF Draft — open specification (opens in new tab)

Displays a brand logo next to authenticated mail in supporting inboxes. Requires DMARC at p=quarantine or p=reject plus a Verified Mark Certificate (VMC). Published via DNS TXT; still an IETF Internet-Draft, so support follows vendor adoption.

What we monitor

  • BIMI record presence
  • DMARC prerequisite status
  • VMC readiness

ARC

Forwarding

Authenticated Received Chain

RFC 8617 — open specification (opens in new tab)

Preserves authentication results through forwarders and mailing lists that would otherwise break DMARC. Intermediate servers cryptographically seal original results so the final receiver can trust forwarded mail instead of rejecting it blindly.

What we monitor

  • ARC readiness from DMARC/SPF/DKIM
  • Readiness regressions when enforcement or signing weakens

Start with a free domain scan

See SPF, DKIM, and DMARC status in seconds. Self-serve plans add email summaries and alerts. Multi-domain programmes start with a conversation.