+ If you do not intend to publish a brand logo, you can add a declination + record to signal that this domain deliberately opts out of BIMI. This + prevents mail clients from falling back to a parent-domain record: +
+{bimiRecord.selector}._bimi.{bimiRecord.domain}. IN TXT "v=BIMI1; l=; a="
+ + Declination record format as defined in § 4.3.1 of + draft-brand-indicators-for-message-identification. +
+{dmarcRecord.domain}
+ {fromDomain}. The record above was
+ inherited from
+ {#if isPsdFallback}
+ the Public Suffix Domain {dmarcRecord.domain} via the DMARCbis
+ DNS Tree Walk (which obsoletes the RFC 9091 PSD DMARC experiment).
+ {:else}
+ the organizational domain {dmarcRecord.domain} via the
+ DMARCbis DNS Tree Walk (compatible with RFC 7489 organizational domain
+ fallback).
+ {/if}
+ p=reject is applied as p=quarantine.
+ {:else if dmarcRecord.policy === "quarantine"}
+ p=quarantine is applied as p=none (no action taken).
+ {:else}
+ p=none is unaffected by test mode.
+ {/if}
+ Aggregate reports are still generated normally.
+ This tag replaces the deprecated pct= for gradual rollout.
+ psd=n explicitly declares
+ this as an Organizational Domain boundary. Subdomains with separate DNS
+ delegation will use their own independent DMARCbis Tree Walk.
+ np={dmarcRecord.subdomain_policy ?? dmarcRecord.policy} to match your subdomain policy.
+ np= tag is introduced by DMARCbis (draft-ietf-dmarc-dmarcbis),
+ a draft RFC updating RFC 7489. Support may vary across mail receivers.
+ pct= tag is removed in
+ DMARCbis. Many receivers already ignore it. For gradual rollout, replace it
+ with t=y (test mode); for full enforcement, simply remove
+ pct= from your record.
+ {#if dmarcRecord.percentage === 0}
+ t=y instead.
+ {/if}
+ pct=100 once you've validated your configuration.
+ messages are subject to DMARC policy. Receivers ignoring pct= will apply
+ the full policy regardless.
pct=100 for full
- protection.
+ messages are protected. Receivers ignoring pct= will apply full policy.
rf= and ri= tags that are
+ {:else if dmarcRecord.deprecated_rf}
+ the rf= tag that is
+ {:else}
+ the ri= tag that is
+ {/if}
+ removed in DMARCbis. Modern receivers will ignore
+ {dmarcRecord.deprecated_rf && dmarcRecord.deprecated_ri ? "them" : "it"}.
+ {#if dmarcRecord.deprecated_ri}
+ Aggregate reporting interval is now fixed at ≥ 24 hours regardless of
+ ri=.
+ {/if}
+ You can safely remove
+ {dmarcRecord.deprecated_rf && dmarcRecord.deprecated_ri ? "these tags" : "this tag"}
+ from your DMARC record.
+ {#if hop.with} @@ -50,6 +75,63 @@ {/if}
{/if} +
+ {#if hop.tls}
+
+ TLS
+
+ {#if hop.tls.version}
+
+ Version:
+ {hop.tls.version}
+
+ {/if}
+ {#if hop.tls.cipher}
+
+ Cipher:
+ {hop.tls.cipher}
+
+ {/if}
+ {#if hop.tls.bits}
+
+ Strength:
+ {hop.tls.bits} bits
+
+ {/if}
+ {#if hop.tls.verified !== undefined}
+
+
+ {hop.tls.verified
+ ? "Certificate trusted"
+ : "Certificate not trusted"}
+
+ {/if}
+ {:else if protocolIndicatesTLS(hop.with)}
+
+ TLS
+
+ {:else if hop.with}
+
+ No TLS
+
+ {:else}
+
+ TLS unknown
+
+ {/if}
+ {#if protocolIndicatesAuth(hop.with)}
+
+ Authenticated
+
+ {/if}
+
+ The HELO/EHLO hostname is the name the sending server announces when it connects. + Many mail servers check that this name matches the sender IP's reverse DNS (PTR) + record. A mismatch is a common spam signal and can hurt deliverability. +
+{heloHostname}
+ {ptr}
+ {heloHostname}
+ {#if ptrRecords && ptrRecords.length > 0}
+ does not match the sender's PTR record{ptrRecords.length > 1 ? "s" : ""}
+ ({#each ptrRecords as ptr, i}{ptr}{i <
+ ptrRecords.length - 1
+ ? ", "
+ : ""}{/each}).
+ {:else}
+ could not be matched against a PTR record.
+ {/if}
+ Configuring the HELO name to match reverse DNS improves deliverability.
+ | Grade | +Score | +Domain | +Date | ++ |
|---|---|---|---|---|
|
+ |
+ + {test.score}% + | +
+ {#if test.from_domain}
+ {test.from_domain}
+ {:else}
+ -
+ {/if}
+ |
+ + {formatDate(test.created_at)} + | ++ + | +
+ Replies (to the From address) and bounces (to the Return-Path) can only be delivered + if the sender's domains accept mail. A domain should publish MX records; an A/AAAA + record works as an implicit fallback but is not recommended. A domain with neither + is unreachable and silently drops replies and bounces. +
+{entry.domain}
+
+ {badgeLabel(entry.status)}
+
+ {#if entry.org_domain}
+
+ via organizational domain {entry.org_domain}
+
+ {/if}
+ {rspamd.report}
+