proton.me
Receivers are told to send to spam mail that fails authentication for this domain.
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.
136 DNS queries · 8493 ms
- 1No aggregate report address (rua=)Add 'rua=mailto:<address>' to the record.
- 2CAA has no reporting addressAdd a record such as: 0 iodef "mailto:[email protected]"
- 3BIMI has no Verified Mark CertificateObtain a VMC from an authorised issuer and add it as the a= tag.
- 4No explicit subdomain policy (sp=)Consider adding 'sp=reject' if no subdomain sends mail.
Identity ·Sending services detected
Read from your SPF includes and MX hosts, then checked for a published DKIM key.
Identity ·DMARC
- Policy
- quarantine
- Coverage
- 100%
- Alignment
- dkim=s spf=s
Identity ·DKIM
111 selectors probed
protonmailProton MailRSA 2048protonmail2Proton MailRSA 2048Identity ·SPF
Worst-case evaluation across every include.
- include:_spf.protonmail.ch
- include:_spf2.protonmail.ch
Findings (7)
HighNo aggregate report address (rua=)›
Without rua= you receive no aggregate reports, which means you have no way to see who is sending mail as your domain, whether it authenticates, or what would break if you moved to p=reject. This is the single biggest blocker to enforcement.
Add 'rua=mailto:<address>' to the record.
RFC 7489 s7
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.
Move to p=reject once reports show no legitimate mail failing.
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.
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.
Once your aggregate reports show no unexplained legitimate sources, tighten to '-all'.
LowBIMI has no Verified Mark Certificate›
Gmail requires a VMC (the a= tag) before it will display a BIMI logo. Without one, only a handful of receivers will show it.
Obtain a VMC from an authorised issuer and add it as the a= tag.
LowCAA has no reporting address›
You have restricted which authorities may issue certificates, but nobody is told when one refuses a request. An iodef address turns an attempted mis-issuance into an alert instead of a silent event.
Add a record such as: 0 iodef "mailto:[email protected]"
RFC 8659
LowStrict SPF alignment is enabled (aspf=s)›
With aspf=s, the envelope sender domain must match the From domain exactly. Subdomain bounce addresses, which most ESPs use by default, will fail alignment.
Use aspf=r (relaxed) unless you have a specific reason not to.
Show 10 passing checks
PassSPF lookup count is healthy (2/10)›
Worst-case evaluation stays within the limit with headroom to spare.
PassProton Mail's DKIM keys are published at protonmail._domainkey, protonmail2._domainkey›
Detected via SPF include:_spf.protonmail.ch, MX mail.protonmail.ch, MX mailsec.protonmail.ch. A valid public key for this service is published at protonmail._domainkey.proton.me, protonmail2._domainkey.proton.me.
Pass2 DKIM key(s) published›
Found at: protonmail, protonmail2.
PassSelector 'protonmail' uses a 2048-bit RSA key›
Key length meets current guidance.
PassSelector 'protonmail2' uses a 2048-bit RSA key›
Key length meets current guidance.
PassMTA-STS is in enforce mode and covers every MX host›
The policy at https://mta-sts.proton.me/.well-known/mta-sts.txt is in enforce mode and its mx patterns match all 2 MX hosts. A sender that implements MTA-STS delivers only over TLS, with a valid certificate, to a host the policy lists.
RFC 8461 s5
PassTLS reporting is configured›
A TLS-RPT record at _smtp._tls.proton.me asks sending servers that support TLS reporting to send reports on failed TLS connections to https://reports.proton.me/reports/smtptls.
PassZone is signed and validates›
A validating resolver reported this zone's answers as authenticated. Resolvers that validate DNSSEC reject a tampered answer for your SPF, DKIM and DMARC records rather than pass it on. This also makes DANE available to you.
PassCertificate issuance is restricted by CAA›
Only letsencrypt.org, sectigo.com may issue certificates for this domain, so a certificate for your mail hosts or your MTA-STS policy endpoint from any other authority would be a mis-issuance.
RFC 8659
PassDANE is published and protected by DNSSEC›
Senders that support DANE verify your mail servers' certificates against the TLSA records in your signed zone, which defeats both downgrade attacks and certificate substitution.
RFC 7672
Transport and zone
Where your mail lands, and whether the DNS carrying your records can be trusted.
This is the configuration. It is not the whole picture.
A DNS scan cannot tell you whether proton.me’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.