Skip to content
Signet

notion.so

Non-sending domain

Receivers are told to send to spam mail that fails authentication for this domain.

Partial enforcement

Forged mail is being filtered to spam rather than rejected, or the policy applies to only a share of messages. Most of the protection is there; the last step is not.

122 DNS queries · 683 ms

Fix these first
  1. 1
    Non-sending domain is not fully locked down
    Publish 'v=spf1 -all', a DMARC policy of 'p=reject; sp=reject', a null MX record, and a wildcard '*._domainkey' record of 'v=DKIM1; p='.
  2. 2
    No DKIM key found at 111 selectors
    Add your selectors manually -- your provider's DNS setup page names them. Connecting aggregate reports is better still: they name the exact selector used by every source that signs mail as you.
  3. 3
    No CAA record
    Publish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"
  4. 4
    No explicit subdomain policy (sp=)
    Consider adding 'sp=reject' if no subdomain sends mail.

Identity ·DMARC

v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected];
Policy
quarantine
Coverage
100%
Alignment
dkim=r spf=r

Identity ·DKIM

111 selectors probed

No key at the 111 selectors we tried. Selectors cannot be listed from DNS, so this is not proof DKIM is missing.

Identity ·SPF

Worst-case evaluation across every include.

v=spf1 ~all
DNS lookup budget0 / 10

Findings (8)

MediumDMARC policy is p=quarantine›

Failing mail is delivered to spam rather than rejected. A meaningful improvement over none, but spoofed mail still reaches the recipient's mailbox.

What to do

Move to p=reject once reports show no legitimate mail failing.

MediumNon-sending domain is not fully locked down›

notion.so sends no mail and receives none, but it is not sealed. Unused domains are attractive precisely because nobody watches them.

What to do

Publish 'v=spf1 -all', a DMARC policy of 'p=reject; sp=reject', a null MX record, and a wildcard '*._domainkey' record of 'v=DKIM1; p='.

LowNo explicit subdomain policy (sp=)›

Subdomains inherit p=, which is usually what you want. Setting 'sp=reject' explicitly protects unused subdomains even while the parent is still at p=none.

What to do

Consider adding 'sp=reject' if no subdomain sends mail.

LowSPF ends in '~all' (softfail)›

Softfail is the correct setting while you are still discovering senders, but it asks receivers to accept unauthorised mail and merely note it.

What to do

Once your aggregate reports show no unexplained legitimate sources, tighten to '-all'.

LowNo DKIM key found at 111 selectors›

Selectors cannot be enumerated from DNS, and we could not fingerprint a known sending service from your SPF or MX records, so we had only a generic wordlist to go on. This is not proof that DKIM is missing. A deep scan additionally tries long-tail and date-stamped selector names.

What to do

Add your selectors manually -- your provider's DNS setup page names them. Connecting aggregate reports is better still: they name the exact selector used by every source that signs mail as you.

RFC 6376 s3.6.2.1

LowNo CAA record›

Any certificate authority in the world may issue a certificate for this domain. A mis-issued certificate can be used to intercept mail on the wire and to impersonate your domain over HTTPS.

What to do

Publish a CAA record naming your certificate authority, for example: 0 issue "letsencrypt.org"

RFC 8659

InfoDomain has no MX records›

This domain does not receive mail. That does not make it safe to ignore: attackers routinely spoof parked and non-mail domains precisely because nobody monitors them.

What to do

Lock the domain down: a null MX record, an SPF record of 'v=spf1 -all', and a DMARC policy of 'p=reject'.

RFC 7505

InfoZone is not signed with DNSSEC›

This is the common case and not a misconfiguration -- most working mail domains are unsigned. It is worth knowing because your authentication records are only as trustworthy as the DNS answers carrying them, and because DNSSEC is the prerequisite for DANE.

What to do

If your DNS provider supports one-click DNSSEC, enabling it is low risk. If it does not, this is not worth changing providers over.

RFC 4033

Show 4 passing checks
PassAggregate reporting is configured›

Aggregate reports are requested at: [email protected].

PassExternal report destination inbound.dmarcdigests.com is correctly authorised›

Authorised by notion.so._report._dmarc.inbound.dmarcdigests.com

PassSPF lookup count is healthy (0/10)›

Worst-case evaluation stays within the limit with headroom to spare.

PassBIMI is published with a certificate reference›

The record at default._bimi.notion.so names a logo and a Verified Mark Certificate (a=), and DMARC is enforcing, which BIMI requires. We read the record only; the logo and certificate themselves were not fetched or checked.

Transport and zone

Where your mail lands, and whether the DNS carrying your records can be trusted.

MXnone publishedThis domain does not receive mail.
MTA-STSnot published
TLS-RPTnot published
BIMIpublished
DNSSECzone not signedCommon and not a misconfiguration.
CAAno record · any CA may issue
DANEno TLSA records

This is the configuration. It is not the whole picture.

A DNS scan cannot tell you whether notion.so’s mail actually aligns, because alignment is decided per message at the receiver. Collect DMARC aggregate reports to see every source sending as this domain.

notion.so scores B for SPF, DKIM and DMARC · Signet