What the email check covers
Whether a message lands in the inbox, in spam or nowhere at all comes down to four DNS records. The email check queries them at the authoritative name server and rates each one the way Gmail, Outlook and Yahoo do on receipt.
- MX: which servers accept mail for the domain, do they resolve, is the priority right?
- SPF: which servers may send on behalf of the domain, does the record stay within the ten DNS lookup limit, how strict is the closing qualifier?
- DKIM: is there a valid key under the common selectors (google, selector1, selector2, default, k1, dkim …) and is it long enough?
- DMARC: does a policy exist, is it none, quarantine or reject, and do reports go to an address?
The Google and Yahoo sender requirements
Since February 2024 Google and Yahoo require anyone sending more than 5,000 messages a day to their users to have SPF and DKIM, a DMARC policy of at least p=none, alignment between the visible sender and the authentication, and one-click unsubscribe for newsletters. Microsoft followed for Outlook.com in May 2025. Below the threshold, mail without SPF or DKIM now regularly ends up in spam as well.
The email check maps exactly these requirements: green means all four records exist and look plausible. Yellow means something is missing or too lax, such as DMARC at p=none or SPF ending in ~all. Red means mail is likely to be rejected or the domain is open to spoofing.
Fix in this order
If several items are red or yellow, follow the order in which the records build on each other:
- MX first: without resolvable mail servers nothing arrives, however good the rest looks.
- Then SPF: list every sender (mail provider, newsletter tool, CRM, website forms), count the lookups, close with ~all.
- Then DKIM: enable it at the mail provider and publish the TXT or CNAME record shown. DKIM survives forwarding, SPF does not.
- Finally DMARC: start with p=none and a rua address, move to quarantine and then reject after four to eight weeks of reports.
Typical setups
Microsoft 365 with a newsletter tool: SPF needs include:spf.protection.outlook.com plus the newsletter tool's include, DKIM is enabled separately for both (Microsoft via selector1 and selector2 as CNAME, the tool via its own selector), DMARC covers both.
Google Workspace: SPF with include:_spf.google.com, DKIM via the google selector from the admin console, MX on smtp.google.com. The check detects all three automatically.
Shared hosting at IONOS, STRATO or ALL-INKL: SPF with the host's include or simply mx, DKIM is enabled in the customer menu and published automatically when the host runs the name servers. If DKIM is missing in the check, it is usually not enabled there.
Monitor email records continuously
These four records change more often than you would think: a new newsletter tool, a hosting move, a colleague who "tidies up" the TXT records. DomainWarn checks MX, SPF, DKIM and DMARC of all client domains regularly and alerts you when a record disappears, becomes invalid or the DMARC policy is weakened, before the first messages land in spam.
Frequently asked questions
- Why is the blacklist check not part of the email check?
- Querying the DNS blacklists takes up to half a minute depending on the list. To keep the email check answering within seconds, the blacklist check runs as its own tool.
- DKIM is not found although it is set up.
- The check tries the common selectors. If your provider uses a custom selector, check it directly in the DKIM checker with the selector filled in.
- Is a green result enough for delivery to Gmail?
- It meets the technical requirements. Reputation, content and complaint rates matter as well; newsletters additionally need one-click unsubscribe.
- Does the email check count as one or four requests?
- As one. The partial results are cached for five minutes and are then available instantly in the individual tools too.