Defaults.Exposed › Fixes

Fix your domain security: free, step-by-step guides

Plain-English guides to fixing every issue we grade, SPF, DKIM, DMARC, DNSSEC, TLS, certificates and HTTP security headers. Each one explains what it is, what it can cost your business, and exactly how to set it up on your provider.

• BIMI (Brand Indicators for Message Identification)
  BIMI is what puts your logo next to your emails in customers' inboxes, the little brand mark that shows up in Gmail, Yahoo, Apple Mail and Fastmail beside your name. It only works if your email is already properly authenticated, and in the two biggest inboxes it also needs a paid certificate that proves your logo is yours. Done right, it lifts trust and open rates; done half-way, nothing appears at all.
• CAA records
  A CAA record is a short instruction in your domain settings that names which certificate companies are allowed to issue the 'padlock' security certificate for your website. With it switched on, no other company can quietly create a valid certificate in your name.
• CDN / WAF & hosting
  Two reads of the plumbing behind your website: whether you sit behind a protective shield (a CDN with a Web Application Firewall, like Cloudflare) that filters attacks and absorbs traffic spikes, and a map of who runs your DNS, website and email. Both are informational on our scoring, they do not move your grade, but they describe how exposed your origin server is to attack and outage, and how tangled your providers are. A shield in front and a sensibly split set of providers is what resilient businesses look like.
• Clickjacking protection (X-Frame-Options)
  A one-line instruction that tells browsers not to let other websites secretly load your site inside their own. Without it, a scammer can hide your real, logged-in pages behind a fake page and trick your customers into clicking things they never meant to, approving a payment, changing a password, granting access.
• Content-Security-Policy (CSP)
  A Content Security Policy is a safety rule your website hands to every visitor's browser, telling it exactly which code is allowed to run. Without one, if anything malicious ever lands on a page (through a comment box, a hacked plugin, or a third-party script) the browser will run it freely, including code that quietly skims your customers' card numbers and passwords as they type, with the padlock still showing.
• Cross-origin isolation headers (COOP / CORP / COEP)
  Three optional browser instructions that control how other websites are allowed to interact with yours, opening it in popups, embedding its images and scripts, or pulling its resources into their own pages. They are modern hardening, not a basic must-have, and on our scoring they are informational: missing them does not lower your grade. But the two safe ones close a quiet phishing and bandwidth-theft gap, and a careful buyer's IT team will notice when they are present.
• DANE (DNS-based Authentication of Named Entities)
  DANE is a way for your domain to publish the fingerprint of your own encryption certificate in DNS, so the other side can check the cert is yours before trusting it. In practice this is mostly used between mail servers: it stops an attacker (or a rogue certificate authority) from silently intercepting inbound email with a fake-but-valid-looking certificate. DANE only works if DNSSEC is already switched on, without DNSSEC it protects nothing at all.
• DKIM
  DKIM is the invisible tamper-proof seal on every email your business sends. It lets the receiving mail provider confirm the email came from you and arrived unchanged. Without it, your mail is easier to fake, easier to alter, and far more likely to land in spam.
• DMARC (Email Spoofing Protection)
  DMARC is the one setting that tells the world's mail providers to BLOCK emails that fake your business's name. SPF and DKIM check the locks; DMARC decides what happens when a forgery fails the check, bin it, flag it, or wave it through. Set wrong, your domain is fully forgeable; set right, impersonation stops at the inbox.
• DNSSEC
  DNSSEC is a digital seal on your domain's address book. It lets the internet prove that the answer to 'where does this domain live?' came from you and wasn't tampered with on the way. Without it, the answer can be forged, and your visitors quietly sent somewhere else.
• HSTS (Strict-Transport-Security)
  HSTS is a one-line instruction your website gives every browser: 'always come back to me over the secure, encrypted connection, never the insecure one.' Without it, your padlock can be quietly stripped away on shared WiFi, and the very first visit to your site is exposed.
• HTTPS & forced-secure redirect
  HTTPS is the padlock in the browser bar, it encrypts everything that travels between your website and your customers so it can't be read or tampered with in transit. The forced-secure redirect makes sure visitors land on that encrypted version automatically, even when they type your address without 'https://'. Together they are the baseline a website needs to be considered safe at all.
• IPv6 support
  IPv6 is the newer, much larger version of the internet's addressing system, brought in because the old one (IPv4) has run out of room. Adding IPv6 support means your website and email can be reached over the modern network as well as the old one. On our scoring this is informational, not having it does not lower your grade, but it is a real-world reach issue: a growing slice of mobile and overseas customers connect over IPv6-only networks, and they reach you smoothly only if you support it. The fix is free and lives in your DNS and hosting setup.
• MIME-sniffing protection (X-Content-Type-Options)
  A one-line header that stops browsers from guessing what a file is. Without it, a file someone uploads to your site, or a file on your own pages, can be mis-read by the browser and run as code, which is exactly how some attacks turn a harmless-looking upload into a way to steal your customers' sessions.
• Modern encryption (TLS version & ciphers)
  TLS is the lock that scrambles the data flowing between your visitors and your website. Two things make that lock trustworthy: using a modern version of TLS (not the old, broken ones), and using strong ciphers (the actual scrambling recipe). This page covers both, plus a few related settings that don't affect your grade but are worth knowing about.
• MX records (mail setup)
  An MX record is the signpost that tells the rest of the world where to deliver email addressed to your domain. If it's missing or broken, every message sent to your business (customer enquiries, password resets, invoices, contracts) bounces straight back to the sender. No MX, no inbox.
• Nameserver setup (diversity & SOA)
  Your nameservers are the directory that tells the whole internet where to find your website and email. If they all sit on one network and it goes down, your business vanishes from the internet at the same moment (no site, no email, nothing) and a sloppy clock setting on those servers can leave changes you make stuck for days.
• Referrer-Policy
  A Referrer-Policy is a one-line instruction your website hands to every visitor's browser, controlling how much of your web address travels with them when they click a link to another site. Without it, the full address of whatever page they were on (search terms, account numbers, reset links, internal page paths and all) is quietly handed to the next site they land on, including advertisers, analytics firms, and anywhere else a link points.
• Reverse DNS (PTR)
  Reverse DNS is the ID badge for the server that sends your business email. When a receiving provider like Gmail or Microsoft 365 looks up who's behind the sending address and gets a name that checks out, your mail looks legitimate. When there's no badge, or the name and number don't agree, your perfectly real invoices and quotes get treated as suspicious and quietly junked or rejected.
• SPF (Sender Policy Framework)
  SPF is the line in your domain's settings that lists which mail services are allowed to send email as your business. Without it, anyone in the world can send email that looks like it came from you, and your own genuine email is more likely to land in customers' spam.
• TLS certificate health
  Your SSL/TLS certificate is the digital ID card that proves a visitor is talking to your website, not an impostor, and powers the padlock in the browser. This check looks at whether that certificate is valid and trusted, not about to expire, and built with strong, modern cryptography.

Common situations

One page per error string, bounce code or provider migration, with the record to publish.

• 550-5.7.26 This email has been blocked because the sender is unauthenticated
  Gmail sends 550-5.7.26 when a message fails both SPF and DKIM. Get either one passing for the sending domain and the block clears once DNS is visible.
• Contact form emails going to spam
  Your web server sends form mail unauthenticated, with no SPF authorisation and no DKIM signature. Route it through authenticated SMTP and the spam stops.
• DKIM "body hash did not verify"
  Body hash did not verify means something rewrote your message after it was signed; find the gateway, appliance, list or relay that edits it and sign after that hop.
• DKIM broke after switching email tools
  Your DNS panel appended your own zone to the new tool's CNAME target, or the old tool's selectors went before its mail drained. Check both with dig.
• DKIM no key for signature means the selector is missing
  No key for signature means the receiver queried s._domainkey.yourdomain and found nothing. Read the s= tag off a real message, publish that record.
• dkim=pass, dmarc=fail: when the signing domain belongs to your provider
  DKIM passes and DMARC fails because the signature belongs to gappssmtp.com or onmicrosoft.com, not your From domain. Turn on custom-domain signing to align it.
• DKIM signature not valid
  A DKIM signature that is not valid means the key was found and the check failed. Read the header wording, then the published key, then the signer.
• DMARC fails but SPF and DKIM pass
  DMARC fails while SPF and DKIM pass because both passed on someone else's domain. Compare header.from with smtp.mailfrom and header.d, then align one leg.
• p=none, p=quarantine, p=reject: what each one tells a receiver
  p=none reports and delivers, p=quarantine sends failures to junk, p=reject refuses them. Move up in that order, one free DNS edit at a time.
• DMARC quarantine/reject policy not enabled: answering the scanner finding
  The warning means no DMARC record or a record at p=none. Publish v=DMARC1; p=none; rua= today, read the reports, then step to quarantine and reject.
• Mail forwarding breaks SPF, and what survives it
  Forwarded mail fails SPF because the forwarder sends from an IP you never listed; no record fixes that, and DKIM signed with your own domain is what survives.
• Gmail 550-5.7.1 message blocked
  Gmail 550-5.7.1 is a policy block. The sentence after the code names the cause: your own DMARC, missing reverse DNS on IPv6, or spam filtering.
• Is .com safer than .net or .org? The measured answer with the denominator stated
  On the September 2026 census .net carries the highest F share of the legacy three and .com the lowest; the gap measures who buys each ending.
• Set up SPF, DKIM and DMARC on a new domain
  A new domain needs one SPF record naming your provider, custom-domain DKIM signing, and DMARC p=none with a rua address. About 20 minutes of DNS work.
• Newsletter emails failing DMARC
  Your platform signs as itself, so nothing aligns with your From domain. Turn on its custom domain authentication, add the DKIM CNAMEs, set the bounce domain.
• No SPF record found: what the checker means and what to publish
  No SPF record found is urgent if your domain accepts mail. Check MX, count the v=spf1 lines at the authoritative nameserver, then publish one or merge to one.
• Not secure: the five things that put that label on your site
  Not secure means the browser couldn't trust the page: no HTTPS, an expired, mismatched or untrusted certificate, or one http:// asset on a valid HTTPS page.
• Outlook rejecting your email, 550 5.7.515 and 5.7.509
  Consumer Outlook bounces unauthenticated high-volume senders with 550 5.7.515. Exchange Online returns 5.7.509 when your own DMARC policy says reject.
• What is an SOA record
  An SOA record sits at the top of your zone and names the primary nameserver, a contact and five timers. Read yours field by field.
• Someone is sending emails from my domain
  Read the From address character by character first. An exact-domain forgery is a DNS fix, a lookalike is a takedown, and they share no steps.
• SPF broke after switching email provider
  The new provider's record went in next to the old one. Two v=spf1 records are a PermError, so merge to one, delete the rest, verify at your nameservers.
• SPF failing for a SaaS sender in Europe: alignment or the lookup cliff
  When a SaaS tool fails SPF, read Return-Path against Authentication-Results: usually SPF passed on the vendor's domain and DMARC failed alignment.
• SPF PermError: too many DNS lookups, and how to get back under ten
  Past ten DNS lookups a receiver returns PermError and voids your whole SPF record. Count the resolved chain, prune dead includes, use subdomains.
• 554 5.7.9 Message not accepted for policy reasons
  554 5.7.9 is Yahoo's permanent policy rejection: SPF or DKIM must pass for a domain matching your From address. Test four causes in order, then fix DNS.
• Your connection is not private: which of the five certificate faults you have
  The browser can't trust the site's certificate. Match the NET::ERR_ code under the warning to one of five faults, then fix that one, free, in an afternoon.