Site AI Audit Email Checks: SPF, DKIM, DMARC and MX

Short answer: One of the four areas in a Site AI Audit report is e-mail. It reads the DNS records of your domain and checks SPF and its lookup limit, DKIM signatures, the DMARC policy and MX records. Missing or wrong records send your mail to spam and let others send mail that looks like yours. The report explains each finding in plain words and says how to fix it.

Why e-mail is part of a website audit

A website and its e-mail share one domain, and customers judge them together. A contact form that sends notifications, an order confirmation or a newsletter all depend on mail reaching the inbox. If your domain has no proper authentication, Gmail and other providers may send your messages to spam or reject them, and criminals can send fake invoices in your name. These faults are invisible when you look at the website, which is why the audit checks them separately.

Site AI Audit describes the e-mail area as the question “Do your e-mails reach the inbox?” It lists four checks on its home page: SPF and its lookup limit, DKIM signatures, the DMARC policy and MX records. The audit does this from outside, by reading public DNS records, so there is nothing to install and no access to your mailboxes is needed. The checks appear in the run after the crawl, as the step called e-mail authentication.

SPF: who may send for your domain

SPF is a DNS record listing the servers and services allowed to send mail for your domain. A receiving server compares the sender with the list. The audit checks whether the record exists, whether it is correct and whether it stays within the lookup limit. SPF allows ten DNS lookups when it is evaluated, and a record that includes too many services goes over the limit and fails, which is a very common fault in domains that use many tools. See SPF explained and the ten lookup limit.

Typical findings are no SPF record at all, two records instead of one, a record that ends in a permissive setting, or a record over the limit. Fixing them means editing one TXT record at your DNS provider. If there are two records, merge them as described in multiple SPF records.

DKIM: a signature on every message

DKIM adds a digital signature to outgoing messages. The matching public key is published in DNS, so the receiver can check that the message really came from your domain and was not altered. The audit looks for DKIM signatures for the domain. Because the record sits under a name chosen by your mail provider, the exact name differs from one provider to another, and the right value comes from your provider’s settings. If the report says that no DKIM record was found, check the provider’s instructions and publish the record exactly as given. The guide to DKIM setup walks through the steps, and DKIM failures helps when it does not pass.

DMARC: what to do when checks fail

DMARC builds on SPF and DKIM. It tells receivers what to do with messages that fail the checks and where to send reports. The audit checks whether a DMARC policy exists. The home page gives an example of a finding: “No DMARC record. Anyone can send e-mail that looks like it comes from you, and Gmail may reject your mail.” The suggested fix is to add a TXT record named _dmarc with the value v=DMARC1; p=none; and then tighten the policy after two weeks.

The policy none means monitor only, so nothing is blocked while you learn who sends mail for you. Later you can move to quarantine and then reject. The article on DMARC explained shows how the policies work, and moving to reject describes a safe path. Bulk senders have additional requirements, see Gmail and Yahoo requirements.

MX: where your mail arrives

MX records tell the world which servers receive mail for your domain. If they are missing or point to a server that does not exist, mail sent to you is lost or bounces. The audit checks that your MX records exist. Typical causes of problems are a change of hosting that removed the old records, a typing error in a server name or leftover records from a former provider that conflict with the new one. See MX records explained. Note that a domain that deliberately sends no mail can publish a special record to say so, as in null MX for domains without e-mail.

How to read the severity

The report ranks findings by impact. In the e-mail area, a missing DMARC record is a warning, because mail may be rejected or spoofed. Missing MX records on a domain that should receive mail would be more serious, since mail cannot arrive at all. Start with what stops mail, then what lets others impersonate you, then improvements. The free check shows every finding and gives full instructions for the three most important ones. Paid plans explain every finding in full. See the guide to reading your report for how the score and the four areas fit together.

A sensible order of fixes

MX. Make sure mail can arrive at all.
SPF. Publish one record that lists every service that sends mail for you, within the lookup limit.
DKIM. Turn on signing at each service and publish the keys.
DMARC with p=none. Start collecting reports and confirm that all your senders pass.
Tighten. After a period of clean reports, move to quarantine and then reject.
Re-check. Run the audit again to confirm that the findings are gone.

Be careful with records you do not understand. A wrong change can block legitimate mail. If you are unsure, take a copy of the current record before you edit it, make one change at a time and test with a real message afterwards, as in testing email deliverability.

Keep watching your mail records

E-mail settings break quietly. A new marketing tool is added without DKIM, a host change drops a record or the SPF record grows past the limit. Paid plans include monitoring: Monitor checks weekly, and Business adds daily SSL and e-mail checks with alerts to your team. The article on monitoring and alerts explains what you receive. For comparison of plans, see the four plans compared or the pricing page.

Domains that send mail through several services need extra care. A typical small company uses a mailbox provider for staff, a newsletter tool, an invoicing system and the website itself for form notifications. Each of these must be covered by SPF or DKIM, and each should sign with the company domain so that DMARC passes. When the report shows a failure after you add a new tool, the cause is nearly always that the new service was never authenticated. Keep a list of every sender with the date it was added and the date it was verified. When the audit reports a change, the list tells you immediately where to look.

Remember also the domains you do not use for mail. A parked domain or an old brand still receives spoofing attempts. Publishing a restrictive SPF record and a DMARC policy for it takes only minutes and prevents criminals from using it in fake messages. The article on protecting parked domains explains how.

A worked example

A small online shop runs its first free check. The report shows an overall score of 74. In the e-mail area there are three findings: no DMARC record, an SPF record that includes eleven lookups and a DKIM record missing for the newsletter service. Order confirmations from the shop have been landing in spam for some customers. The owner follows the instructions for the top issues. She removes two services that she no longer uses from the SPF record, which brings it under the limit. She turns on DKIM in the newsletter tool and publishes the key. She adds a DMARC record with p=none and reads the first reports with her web developer. After two weeks, with all senders passing, she moves the policy to quarantine. A re-check shows no e-mail findings, and customers stop reporting missing confirmations.

The quickest way to know where you stand is to look at your own report. Run a free check of your website and open the e-mail area.

The bottom line

The e-mail area of the audit looks at the four records that decide whether your mail arrives and whether others can fake it: SPF, DKIM, DMARC and MX. Fix them in that order, tighten DMARC slowly and check again after each change.

KKK

What does the e-mail check read?

The public DNS records of your domain: SPF and its lookup limit, DKIM signatures, the DMARC policy and MX records.

Do I need to give access to my mailboxes?

No. The audit works from outside and reads only public records.

Which DMARC policy should I start with?

Start with p=none to collect reports without blocking mail, then tighten it after about two weeks of clean results.

Why does the report say my SPF has too many lookups?

Each included service adds lookups, and SPF allows ten. Remove services you no longer use or restructure the record.

How can I be warned when a record breaks?

Paid plans include monitoring with alerts. Monitor checks weekly, and Business adds daily SSL and e-mail checks.