Executive's DNS Intelligence Brief

Change your DMARC policy from p=none to p=quarantine (then p=reject). Review your DMARC aggregate reports first to ensure legitimate senders pass authentication.

Publish an MTA-STS DNS record and host a policy file at https://mta-sts.item.org/.well-known/mta-sts.txt. This tells senders to require TLS when delivering mail to your domain.

Your SPF record uses ~all (softfail) and no DKIM signing was detected. Without DKIM, SPF is your only line of defense — upgrading to -all (hardfail) instructs receivers to reject unauthorized senders outright. Verify all legitimate sending sources are included before switching. If you configure DKIM, ~all becomes the industry-standard best practice because DMARC evaluates both SPF and DKIM alignment (RFC 7489 §10.1).

DKIM selectors were not discoverable via common selector names. This does not confirm DKIM is absent — your provider may use custom or rotating selectors that cannot be enumerated through DNS (RFC 6376 §3.6.2.1). Check your email provider's DKIM settings to confirm signing is enabled.

Publish CAA DNS records to restrict which Certificate Authorities can issue TLS certificates for your domain. Specify your preferred CA (e.g., letsencrypt.org, digicert.com). CAA is advisory — CAs must check it before issuing, but absence means any CA can issue.

TLS-RPT (TLS Reporting) sends you reports about TLS connection failures when other servers try to deliver mail to your domain. Helps diagnose MTA-STS and STARTTLS issues.

DNSSEC (DNS Security Extensions) cryptographically signs DNS responses, preventing attackers from forging DNS answers. Contact your DNS hosting provider to enable DNSSEC signing.