Fix guides

The selector exists with an empty p= tag, which RFC 6376 defines as revocation. Any message still signed with it fails DKIM outright.

RFC 7208 §5.2 makes this a PermError: when a receiver evaluates the include and finds no SPF record there, the entire SPF check fails, not just that one mechanism.

The record does not parse against RFC 7489, so receivers will skip it.

Your rua= or ruf= address is on a different organizational domain, and that domain has not published the authorization record RFC 7489 §7.1 requires. Receivers are discarding your reports.

RFC 7489 §6.6.3 requires receivers to ignore the domain entirely when more than one DMARC record is present. Your policy is not being applied.

RFC 7208 requires exactly one. Two or more is a PermError and most receivers discard all of them, which means your SPF effectively does not exist.

Without DMARC, receivers have no instruction for handling mail that fails authentication, and you get no visibility into who is sending as your domain. Google, Yahoo and Microsoft require it from bulk senders.

Nothing tells receiving servers which hosts may send mail using this domain, so anyone can forge it and legitimate mail has one fewer way to authenticate.

+all authorizes the entire internet to send mail as this domain. It is strictly worse than having no SPF record and is almost always a typo or a copied example.

RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS-lookup terms. Past that, receivers return PermError and treat the record as if it were not there — silently, with no bounce.

Keys below 1024 bits are considered forgeable and some receivers ignore signatures made with them. 2048 bits is the current norm.

Monitoring only. Receivers are told to take no action on mail that fails authentication, so the record provides visibility but no protection against spoofing.

Failing mail is sent to the spam folder rather than rejected. One step short of full enforcement — and spam folders still get read, so a convincing spoof can still land.

No rua= address, so nobody receives aggregate reports. You have a policy with no feedback loop, which makes it unsafe to tighten.

DKIM selectors cannot be enumerated from DNS, so this is not proof that DKIM is absent — only that none of the common provider selectors answered. Pin your selector to check it directly.

Without a trailing all, unmatched senders produce a neutral result, which receivers treat almost identically to having no SPF policy.

A single TXT character-string cannot exceed 255 octets. A longer one must be split into multiple quoted strings, which receivers concatenate.

RFC 7208 §5.5 deprecates ptr: it is slow, it costs a DNS lookup, and receivers are explicitly permitted to ignore it.

The sp= tag is weaker than p=, so your subdomains can be spoofed even though the apex is enforced. Attackers routinely target invented subdomains for exactly this reason.

More than two lookups returned nothing at all, usually from includes pointing at decommissioned vendors. RFC 7208 caps void lookups at 2 and PermErrors past that.

Your SPF, DKIM and DMARC records are unsigned, so a resolver cannot detect if they were tampered with in transit. Optional, but it is what the records above rest on.

Your logo will not appear beside your messages in supporting inboxes. BIMI requires DMARC at quarantine or reject first, so it is an end-state reward rather than a starting point.

Nothing requires sending servers to use TLS when delivering to you, so a downgrade attack on inbound mail is possible.

This domain cannot receive mail. That is correct for a send-only or parked domain, and a problem if anyone expects to reply to it.

You receive no reports about failed TLS connections to your mail servers, so a downgrade or certificate problem would go unnoticed.