Website fixes: email and domain
Getting your email delivered.
DNS is the internet's address book: settings attached to your domain that tell browsers where your website is, and tell mail servers where to deliver your email and which emails really come from you. A mistake here can take your site offline, lose your email, send it to spam, or make it easier for scammers to send email in your name.
The domain doesn't exist in DNS
What it means. When the check asked DNS about your address, the answer was "no such domain". As far as the internet is concerned, the name isn't registered, or isn't set up.
Why it matters. Nobody can reach your site at this address. If the domain itself is missing, not just a name in front of it like www, email to it stops arriving too.
How to fix it. Work through these in order:
- Check the address for a typo.
- Check the domain is still registered and paid up. A failed renewal payment, or a reminder sent to an old email address, can let it lapse. Log in where you bought it, or look it up in a WHOIS search (the public register of domains).
- A .au domain can also be suspended if the owner's details or eligibility (such as the ABN) no longer check out. The company you registered it with can tell you.
- Check the nameservers, which say which company holds the domain's DNS records. If they name a company you no longer use, nothing answers.
- If only www fails, that name needs a record of its own (see no address).
How the check spots it: the check asks Google Public DNS for the address's A record (its IPv4 address). An answer of "no such domain" is listed under Fix first, and the email checks are skipped. Because DNS services are occasionally wrong, this only appears when your site didn't answer the check either.
The domain doesn't point to a server
What it means. Your domain exists, but DNS doesn't say where its website lives. That takes an A record (an IPv4 address, four numbers like 203.0.113.10), an AAAA record (the longer IPv6 kind) or a CNAME (an alias for another name). None is set for this address.
Why it matters. Browsers have nowhere to go, so visitors see an error saying the site can't be found.
How to fix it. Add the record your host or platform gives you, wherever your domain's DNS is managed: usually the company you registered the domain with, your web host or Cloudflare.
- This often follows a move to a new host or new nameservers, when the old records weren't copied across. The new host's setup guide lists what to add.
- Wix, Squarespace and Shopify each publish the exact records for connecting a domain.
- If only www is missing, add a record for it, often a CNAME to the address your host gives you. Changes can take a while to reach everyone.
How the check spots it: the check asks Google Public DNS for the address's A, AAAA and CNAME records. If the A and AAAA lookups both answer and none of the three finds anything, it's listed under Fix first. As with a domain that doesn't exist, this only appears when your site didn't answer the check either.
The contact email on the page may not be receiving mail
What it means. The page links to an email address at your own domain (a mailto: link), but the domain has no MX records. MX (mail exchange) records tell other mail servers where to deliver email for your domain.
Why it matters. Without them, email to that address usually bounces or never arrives, and people who write to you may think you're ignoring them. The email standard lets senders fall back to the domain's website address, but web servers rarely accept email; hence "may".
How to fix it. Send a test email to the address from a different account. If it arrives, the address works, though proper MX records are still wise. If it doesn't:
- Add the MX records from your email provider (Google Workspace, Microsoft 365, your host, or whoever runs your mailbox) wherever your DNS is managed. The usual cause is a move: the website or DNS changed company, and only the website's records came across.
- If nobody uses the address any more, change the link to one that works.
- Once email works, set up SPF, DKIM and DMARC too.
How the check spots it: the check collects the email domains in the page's mailto: links. If one is your own domain (your address without www.) and DNS answered that it has no MX records, it's listed under Fix first. Addresses written as plain text, or at other domains, aren't checked.
The SPF record is missing or set up wrong
What it means. SPF (Sender Policy Framework) is a TXT record in your domain's DNS, starting v=spf1, that lists the services allowed to send email for your domain: your mailbox provider, plus anything else that sends as you, such as a newsletter tool, booking system or online shop. The check found one of three problems: no SPF record; more than one, which the standard doesn't allow; or +all, which approves every server in the world.
Why it matters. Gmail, Outlook and others use SPF, with DKIM and DMARC, to judge whether an email claiming to be from you is genuine. Without a working record, your real emails are more likely to land in spam, and scammers find it easier to send emails that look like yours. Two records make SPF fail for every email, and +all makes it meaningless.
How to fix it. Your email provider gives you the exact record, which looks something like v=spf1 include:… ~all. Add it as a TXT record on the domain itself (not on www), wherever your DNS is managed.
- Keep to one record. For several services, combine them: one
v=spf1at the start, each service'sinclude:in the middle, one~allor-allat the end. ~allasks receivers to treat other senders as suspicious,-allto reject them. Both are common; never use+all.- A domain that never sends email can use
v=spf1 -all.
How the check spots it: the check reads the TXT records on your email domain (your address without www.). No SPF record is listed under Worth fixing if the domain has MX records (it receives email), or Nice to have if not. More than one is Worth fixing; +all is Fix first. A subdomain with no MX records and no SPF record is left alone. If the record looks right, the check goes on to its includes and lookups.
The SPF record includes a domain that has no SPF record
What it means. SPF records bring in other services' lists with include:, as in include:_spf.example.com, meaning "whatever this service's SPF record allows". One of the domains your record includes has no SPF record, so there's nothing there to include.
Why it matters. Under the SPF standard (RFC 7208), that makes your whole record an error. Mail servers treat it as broken, so your emails can fail SPF and land in spam, and DMARC can fail when it relies on SPF.
How to fix it. Look at the domain named in your report.
- If it's a service you no longer use, remove that
include:. - If it's a typo, such as a missing letter or a dropped underscore at the front, correct it from your provider's instructions.
- If the service has changed its SPF address, get the current one from its help pages.
- Afterwards, email yourself at a Gmail address and choose "Show original" from the message's menu. It shows whether SPF, DKIM and DMARC passed.
How the check spots it: when the record passes the first SPF checks, the check looks up each domain it names with include: or redirect=, a level at a time, making up to 10 lookups of its own. An included domain with no SPF record, or that doesn't exist, is listed under Worth fixing. When it finds one, it reports this instead of counting lookups.
The SPF record needs more than 10 DNS lookups
What it means. To check your SPF record, a mail server has to look up every part that names another domain: each include:, a, mx, ptr, exists and redirect=, plus the same parts inside every record you include. The SPF standard caps this at 10, and your record needs more.
Why it matters. Mail servers stop at 10 and treat a record that needs more as broken, so your email can fail SPF and land in spam even though every service in it is genuine. It creeps up as each new tool (a newsletter, CRM, help desk or invoicing system) adds another include:.
How to fix it. Slim the record down. Section 4.6.4 of the SPF standard sets out exactly what counts.
- Remove services you no longer send email through.
- Remove
aandmxonly if nothing sends email from your website's server or mail server; a contact form that emails you often relies ona. - Move a sending service to a subdomain, such as news.yourdomain, with its own SPF record. Many newsletter tools support this.
- Swapping includes for a service's IP addresses ("flattening") only works until it changes servers, so do it only with a tool or person that keeps it up to date.
How the check spots it: the check counts those parts in your record and in the records it includes (a redirect= only when there's no all, as the standard says), up to five levels deep and with at most 10 lookups of its own. Once the count passes 10, it stops and lists this under Worth fixing, as "at least" that many. If a lookup fails, or an include depends on the sender (an SPF macro, %{…}), it gives no count.
There's no DMARC policy, or it only monitors
What it means. DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record named _dmarc in front of your domain, as in _dmarc.example.com.au. It tells receiving mail servers what to do with email that claims to be from you but fails SPF and DKIM, or passes them only for some other domain. That ties the checks to the From address people see, which SPF alone doesn't look at. The policy, p=, can be none (deliver and report), quarantine (send to spam) or reject (refuse). Your domain has no DMARC record, or uses p=none.
Why it matters. Without DMARC, or with p=none, a fake email using your exact address can still reach inboxes; quarantine or reject tells Gmail and Outlook to stop it. Gmail, Yahoo Mail and Outlook.com now require DMARC from bulk senders. A small business may not be one, but the record protects your name either way.
How to fix it. Tighten it in steps, so you never block your own email. Google's email sender guidelines describe what Gmail expects.
- Start with
v=DMARC1; p=none; rua=mailto:…, using an address that can receive reports. - Over the following weeks, use the reports to check that every service sending as you passes, from your mailbox and newsletter to website forms and invoicing. Fix any that fail with SPF or DKIM.
- Then move to
p=quarantine, and later top=reject. A domain that never sends email can go straight top=reject, alongsidev=spf1 -all.
How the check spots it: the check looks up the TXT record at _dmarc on your email domain. No record is listed under Worth fixing if the domain has MX records, or Nice to have if not; A record with no valid policy (p= missing, or not none, quarantine or reject) is treated the same way, since mail servers may ignore it. p=none is Nice to have; quarantine and reject pass. A subdomain with no record of its own gets the parent domain's subdomain policy (sp=) or, failing that, its p=, as mail servers do.
No DKIM key found for your email provider
What it means. DKIM (DomainKeys Identified Mail) adds a digital signature to each email you send. The matching public key sits in your DNS under a name your provider chooses (called a selector), so receiving servers can check the email came from a service you authorised and wasn't changed on the way. Your email runs on Google Workspace or Microsoft 365, and the check couldn't find their key on your domain.
Why it matters. Google Workspace and Microsoft 365 sign your email with their own domain until you turn DKIM on for yours, and DMARC only counts a signature from your own domain. Without it, DMARC relies on SPF alone, which often breaks when an email is forwarded, so genuine messages are more likely to land in spam.
How to fix it. Turn it on in your provider's admin settings and add the records it gives you to your DNS; the provider may take a while to see them.
- Google Workspace: in the Admin console, open Gmail's "Authenticate email" setting, generate a key, add the TXT record it shows, then start authentication. Google's DKIM guide walks through it.
- Microsoft 365: in the Microsoft Defender portal's DKIM settings, add the two CNAME records it shows (selector1 and selector2), then turn signing on.
- Newsletter and booking tools that send as you usually offer DKIM records too, often under "domain authentication".
How the check spots it: a DKIM key can only be found if you know its selector, so the check covers just these two providers, recognised from your MX records, because their default selectors are fixed. It looks for a key at google._domainkey, or at selector1._domainkey and selector2._domainkey. If those lookups answer and none holds a key, it's listed under Nice to have. It can't see a Google prefix other than "google", and says nothing about other providers.
DMARC reports aren't sent anywhere
What it means. A DMARC record can name an address for reports with rua=. Gmail, Outlook and other large providers then send summaries, usually daily, of the email they received claiming to be from your domain: which servers sent it, and whether it passed SPF and DKIM. Your record has no rua=, so nobody receives them.
Why it matters. The reports show which services send as you, whether any of them fail, and whether someone is faking your address. Without them, tightening your DMARC policy is guesswork: you could block your own newsletter or invoices without knowing.
How to fix it. Add rua=mailto: and an address, so the record reads something like v=DMARC1; p=none; rua=mailto:….
- Reports arrive as data files (XML) that are hard to read by hand. A DMARC report service turns them into summaries; some are free, and Cloudflare offers one for domains whose DNS it manages.
- Use a separate mailbox or alias, since reports arrive every day from several providers.
- An address at another domain only works if that domain publishes a record agreeing to receive them. Report services set this up for their own addresses.
How the check spots it: when your domain has its own DMARC record and receives email (it has MX records), the check looks for rua= in it. If there's none, this is listed under Nice to have, whatever the policy.