cloudflare.com
Receivers are told to reject mail that fails authentication for this domain.
Receivers are told to reject mail that fails authentication for this domain. Keep watching aggregate reports so a new sending service does not silently start failing.
Score held up: DMARC is enforcing at p=reject, so nobody else can send as this domain. That is the hard part, and it is done. What is left below is about your own mail arriving, not about anyone spoofing you -- and some of it may be costing you delivery.
149 DNS queries · 363 ms
- 1Zendesk can send as your domain but publishes no DKIM keyEnable DKIM signing in Zendesk and publish the public key it gives you.
- 2p=reject may be costing you mail from 1 of your own sendersBest: turn DKIM signing on at Zendesk and publish the key -- that fixes it without weakening anything, and the findings above link each provider's own guide. If it will take weeks and mail is already going missing, moving to p=none while you fix it is not a defeat: an enforcing policy you cannot support is worse than an honest monitoring one. Either way you are guessing until aggregate reports tell you which senders are actually affected and how much mail is involved.
- 3Could not verify DKIM signing for Google WorkspaceConfirm DKIM is switched on in Google Workspace, then add your selector here so every future scan can verify it directly.
- 4Could not verify DKIM signing for Salesforce Marketing CloudConfirm DKIM is switched on in Salesforce Marketing Cloud, then add your selector here so every future scan can verify it directly.
Identity ·Sending services detected
Read from your SPF includes and MX hosts, then checked for a published DKIM key.
Identity ·DMARC
- Policy
- reject
- Coverage
- 100%
- Alignment
- dkim=r spf=r
Identity ·DKIM
111 selectors probed
mandrillMailchimp TransactionalRSA 1024k1Mailchimp / MailgunRSA 1024s1SendGridRSA 2048smtpapiSendGridRSA 1024m1MarketoRSA 2048Identity ·SPF
Worst-case evaluation across every include.
- include:_spf.google.com
- include:spf1.mcsv.net
- include:spf.mandrillapp.com
- include:mail.zendesk.com
- include:stspg-customer.com
- include:_spf.salesforce.com
Findings (9)
HighZendesk can send as your domain but publishes no DKIM key›
Zendesk was detected via SPF include:mail.zendesk.com, so it is authorised to send mail as cloudflare.com. It always publishes DKIM at fixed selectors (zendesk1, zendesk2), and none of them has a key published. Without one, no DKIM signature it adds for your domain can verify, so its mail has only SPF to align on -- and SPF does not survive forwarding.
Enable DKIM signing in Zendesk and publish the public key it gives you.
RFC 6376
Highp=reject may be costing you mail from 1 of your own senders›
Being at p=reject is the right place to be, and reaching it is the hard part -- nobody else can send as cloudflare.com. The problem is that Zendesk is authorised to send as this domain and publishes no DKIM key, so that mail has only SPF behind it. SPF does not survive forwarding, and a receiver honouring your policy will have it rejected. Nothing here lets anyone else in; it is your own mail at risk.
Best: turn DKIM signing on at Zendesk and publish the key -- that fixes it without weakening anything, and the findings above link each provider's own guide. If it will take weeks and mail is already going missing, moving to p=none while you fix it is not a defeat: an enforcing policy you cannot support is worse than an honest monitoring one. Either way you are guessing until aggregate reports tell you which senders are actually affected and how much mail is involved.
MediumCould not verify DKIM signing for Google Workspace›
Google Workspace was detected via SPF include:_spf.google.com, so it is authorised to send mail as cloudflare.com. We checked the selectors it uses by default (google, google2048) and found no key. Google Workspace lets you choose your own selector name, so this may simply mean yours is custom. If signing genuinely is not enabled, mail through this service will fail DMARC once forwarded.
Confirm DKIM is switched on in Google Workspace, then add your selector here so every future scan can verify it directly.
RFC 6376
MediumCould not verify DKIM signing for Salesforce Marketing Cloud›
Salesforce Marketing Cloud was detected via SPF include:_spf.salesforce.com, so it is authorised to send mail as cloudflare.com. We checked the selectors it uses by default (sfmc1, sfmc2, exacttarget) and found no key. Salesforce Marketing Cloud lets you choose your own selector name, so this may simply mean yours is custom. If signing genuinely is not enabled, mail through this service will fail DMARC once forwarded.
Confirm DKIM is switched on in Salesforce Marketing Cloud, then add your selector here so every future scan can verify it directly.
RFC 6376
MediumSelector 'mandrill' uses a 1024-bit RSA key›
1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.
Rotate to 2048-bit at your next key rotation.
RFC 8301
MediumSelector 'k1' uses a 1024-bit RSA key›
1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.
Rotate to 2048-bit at your next key rotation.
RFC 8301
MediumSelector 'smtpapi' uses a 1024-bit RSA key›
1024-bit is the RFC 8301 floor, not a good target. 2048-bit is the current recommendation and is universally supported.
Rotate to 2048-bit at your next key rotation.
RFC 8301
MediumMTA-STS is advertised but the policy file cannot be fetched›
The DNS record at _mta-sts.cloudflare.com promises a policy, but mta-sts.cloudflare.com does not resolve to any address. A sender that cannot fetch a policy delivers as though the domain had not deployed MTA-STS (RFC 8461 s5).
Serve a valid policy at https://mta-sts.cloudflare.com/.well-known/mta-sts.txt using a certificate valid for that hostname.
RFC 8461
InfoMail exchangers do not have forward-confirmed reverse DNS›
The addresses behind mxa-canary.global.inbound.cf-emailsecurity.net, mxb-canary.global.inbound.cf-emailsecurity.net, mxa.global.inbound.cf-emailsecurity.net, mxb.global.inbound.cf-emailsecurity.net either have no PTR record or have one that does not resolve back to the same address. This is reported rather than scored, because reverse DNS is checked against the address a server connects *from*: it matters if these hosts also send your outbound mail, and does not if they are inbound-only gateways. Several large providers run inbound MX with no PTR quite deliberately.
If these hosts also send mail, ask whoever operates them to publish a PTR record for each address that resolves back to the same address. If they only receive, no action is needed.
RFC 8601
Show 14 passing checks
PassAggregate reporting is configured›
Aggregate reports are requested at: [email protected], [email protected].
PassExternal report destination dmarc-reports.cloudflare.net is correctly authorised›
Authorised by cloudflare.com._report._dmarc.dmarc-reports.cloudflare.net
PassDMARC policy is p=reject›
Mail failing authentication is rejected outright. This is the correct end state.
PassSPF lookup count is healthy (7/10)›
Worst-case evaluation stays within the limit with headroom to spare.
PassSPF ends in '-all' (hard fail)›
Unauthorised hosts are explicitly rejected. This is the correct end state.
PassMailchimp Transactional (Mandrill)'s DKIM key is published at mandrill._domainkey›
Detected via SPF include:spf.mandrillapp.com. A valid public key for this service is published at mandrill._domainkey.cloudflare.com.
Pass5 DKIM key(s) published›
Found at: k1, m1, mandrill, s1, smtpapi.
PassSelector 's1' uses a 2048-bit RSA key›
Key length meets current guidance.
PassSelector 'm1' uses a 2048-bit RSA key›
Key length meets current guidance.
PassTLS reporting is configured›
A TLS-RPT record at _smtp._tls.cloudflare.com asks sending servers that support TLS reporting to send reports on failed TLS connections to mailto:[email protected].
PassBIMI is published with a certificate reference›
The record at default._bimi.cloudflare.com 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.
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 comodoca.com, digicert.com, letsencrypt.org, pki.goog, ssl.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. Wildcard certificates are limited separately, to comodoca.com, digicert.com, letsencrypt.org, pki.goog, ssl.com.
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 cloudflare.com’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.