What “ready for support email” actually means
A support address has two jobs. It has to receive: when a customer writes to support@yourdomain, their mail server needs to know where to deliver. And it has to reply: when you answer, the customer’s provider (usually Gmail, Outlook or Yahoo) decides whether your reply looks genuine before it reaches the inbox. Both jobs are decided by a handful of public DNS records, and that’s what this checker reads.
- MX handles receiving. It names the servers that accept mail for the domain. No working MX, no incoming support mail. MX checker
- SPF lists the servers allowed to send mail for the domain. SPF checker
- DKIM publishes the public key that proves a message was signed by your domain and not altered on the way. DKIM checker
- DMARC ties SPF and DKIM to the From address your customer sees, and tells receivers what to do when a message fails. DMARC checker
The checker looks all four up at once, for up to ten domains, and gives each domain a single verdict: Ready for branded support email when nothing fails, or Needs fixes when at least one record is missing or broken.
How to read the results
Every record gets one of three statuses. Pass (green) means it’s present and correct. Warning (amber) means it works today but is weaker than it should be, or the checker couldn’t confirm something. Fail (red) means receivers will reject it or ignore it, or mail can’t be delivered at all. Under each status you’ll find a plain explanation, the record exactly as it’s published, and, when the fix is mechanical, a corrected record you can copy straight into your DNS provider.
Two results deserve a closer look because they’re often misread:
- DKIM “No key at common selectors” is a warning, not a failure. DKIM keys live under a name (the selector) that you can’t discover from DNS alone. The checker tries the fixed selectors used by Google Workspace, Microsoft 365, SendGrid, Mailchimp and Fastmail. If you send through Amazon SES, Postmark, Zoho, Resend or a similar service, your selector is unique to your domain, so check it in the DKIM checker.
- DMARC “p=none” is also a warning. The record exists and meets the mailbox providers’ minimum, but it asks receivers to take no action against fakes. It’s the right first step, not the last one.
What a healthy setup looks like
Here’s a typical domain whose mailboxes are on Google Workspace and whose support replies are sent by a helpdesk:
- MX records pointing at Google’s mail servers, all of which resolve.
- One SPF record:
v=spf1 include:_spf.google.com include:[your helpdesk’s SPF domain] ~all, using well under 10 lookups. - A DKIM key at
google._domainkeyfor Workspace, and the helpdesk’s own DKIM key at its selector, both 2048-bit. - A DMARC record such as
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain, reached after a few weeks at p=none with reports showing nothing unexpected.
Your providers will differ, but the shape is the same: mail comes in through MX, and every service that sends as you is covered by SPF, signs with DKIM, and is checked by DMARC.
Common mistakes, and how to fix each
The helpdesk sends, but nobody told SPF
Adding a new tool that sends replies, invoices or password resets as your domain, without adding it to SPF, is the most common cause of support replies landing in spam. Find the include the service documents and add it to your existing SPF record. Don’t publish a second SPF record: two records make SPF fail for everything.
DKIM was never switched on
Some providers publish nothing until you turn DKIM on. Google Workspace, for example, needs you to generate a key in the Admin console and add it to DNS, and it recommends a 2048-bit key with the default selector google (Google: set up DKIM). Until then, Workspace mail isn’t signed with your own domain.
No DMARC record at all
Without DMARC, receivers have no instructions for mail that fails SPF and DKIM, you get no reports, and you miss a requirement that Gmail, Yahoo and Outlook now set for bulk senders. Publishing v=DMARC1; p=none; rua=mailto: plus an address you read takes a minute and changes nothing about delivery while you watch the reports.
MX records left at the registrar default
A new domain often has MX records pointing at the registrar’s forwarding service, or none at all. If customers write to support@ and get a bounce, check the MX result first. If the domain should never receive mail, publish a null MX instead (see below).
Replies sent from a subdomain nobody configured
Some tools send from an address like support@help.yourdomain. That subdomain needs its own SPF record (SPF isn’t inherited) and the tool’s DKIM key under the subdomain. DMARC is inherited from the parent unless the subdomain publishes its own record. Run the subdomain through the checker too.
Why this matters for support replies
Support mail is low-volume, one-to-one and wanted, but mailbox providers check it like any other mail, and the rules have tightened:
- Gmail has required every sender to use SPF or DKIM since February 1, 2024. Anyone sending more than 5,000 messages a day to personal Gmail accounts also needs both SPF and DKIM, a DMARC record (p=none is acceptable), and a From domain that aligns with SPF or DKIM. Gmail asks for DKIM keys of at least 1024 bits and recommends 2048 (Gmail email sender guidelines).
- Yahoo asks all senders for SPF or DKIM at a minimum, and bulk senders for both plus a DMARC policy of at least p=none that passes, with relaxed alignment accepted (Yahoo Sender Hub best practices).
- Outlook.com (including hotmail.com and live.com addresses) requires domains sending more than 5,000 messages a day to pass SPF and DKIM and to publish DMARC of at least p=none, aligned with SPF or DKIM. Since May 5, 2025, Microsoft has routed non-compliant mail from those domains to Junk, and it has said rejection will follow (Microsoft announcement).
A small support inbox won’t hit 5,000 messages a day, but the domain it shares with your newsletters, receipts and app notifications might. The volume counts per domain, not per tool. And even below the threshold, a missing or broken record is one of the clearest signals a spam filter has. A reply that never reaches the customer looks, from their side, exactly like being ignored.
Domains you don’t use for email
If a domain has no MX records, the checker also shows how to lock it down. A domain that never sends or receives mail can still be forged in the From line. Three records stop that, as recommended by the industry anti-abuse group M3AAWG (Protecting Parked Domains): a null MX (MX 0 ., defined in RFC 7505) so mail to it fails straight away, v=spf1 -all so no server may send as it, and v=DMARC1; p=reject; so receivers refuse anything claiming to come from it. Only use them on domains that really carry no email.