MX
Who receives the domain’s email
Google: google · Microsoft 365: selector1 · Mailchimp: k1 · Brevo: mail · SendGrid: s1
SPF
Who may send on its behalf
DMARC
What to do when something does not add up
DKIM
The signature that proves it was not altered
Review
What to do
Next step
Shall we fix it for you?
Send us this result and we reply within one business day with what we would fix first, how much work it is and what you can leave as it is.
Send this result
Opens the form with the diagnosis already written. You can edit it before sending.
How to use it
01
Type the domain
The one in your email address, without "www" or "@". Paste a whole address and we keep the domain.
02
Add the selector, if you know it
DKIM lives at a name each provider chooses. Google uses "google", Microsoft "selector1", Mailchimp "k1". Without it everything else is still checked.
03
Read the four cards
Each one says whether the record exists, what it says and what it is missing. Below, the list of what to change and in what order.
The three records, one sentence each
- SPF
- Who may send email on behalf of the domain. A list of servers in a TXT record; whatever is not on the list gets flagged.
- DKIM
- A signature on every message proving it came from who it says and nobody touched it on the way. The public key lives in DNS, under a selector.
- DMARC
- What to do when SPF or DKIM fail — nothing, spam or reject — and which address receives the reports on who is sending as the domain.
Why email ends up in spam
Since February 2024, Gmail and Yahoo require SPF, DKIM and DMARC from anyone sending email in volume, and flag or reject whatever does not comply. It is not a recommendation: it is the condition for getting in.
The two failures we see most are silent. An SPF past ten DNS lookups still looks right in the panel, but to the receiver it is a permanent error. And a DMARC at p=none feels like protection when it is only watching: mail spoofing the domain is still delivered.
The third is alignment: the marketing platform signs with its own domain instead of yours, and DMARC — correctly — does not believe it.
Email sent by a system is still your email
When a system sends email for you — invoices, order confirmations, appointment reminders, alerts from an automated flow — deliverability is part of the job. A reminder that lands in spam is a missed appointment, and nobody finds out until the customer does not show up.
That is why, in every automation we deliver, we set up SPF, DKIM and DMARC for the sender, sign with the client’s domain rather than the platform’s, and watch the DMARC reports: they are the only way to know something stopped arriving before a customer says so.
Frequently asked questions
What is the difference between ~all and -all?
Both close the SPF, with different severity. With ~all ("softfail"), a message from a server not on the list is marked suspicious and the receiver decides, usually through DMARC. With -all ("hardfail") you ask for it to be rejected outright. In practice almost every provider recommends ~all and leaving the final call to DMARC, because a -all with one forgotten server rejects legitimate mail without warning.
Why does my SPF exceed ten lookups when I only have two includes?
Because every include expands. If you include your email provider and your marketing platform, each of them includes its own providers in turn, and those lookups count too: a single Microsoft 365 include costs several. The limit of ten comes from the standard and exceeding it does not grant "more permissions": it is a permanent error and the mail is treated as unauthenticated. This tool follows the whole chain to count them the way a receiver would.
Do I need DMARC if I already have SPF and DKIM?
Yes. SPF and DKIM say who sends and whether the message is intact, but not what to do when they fail, and without DMARC every receiver improvises. DMARC is also the only thing that sends you reports: without it you will not know someone is sending as your domain until a customer tells you. And since February 2024 Gmail and Yahoo require it from anyone sending more than five thousand messages a day.
Which DKIM selector do I use?
Whichever your email provider tells you: the record sits at selector._domainkey.yourdomain.com and each provider picks the name. The usual ones: Google Workspace uses "google", Microsoft 365 "selector1" and "selector2", Mailchimp "k1", Brevo "mail", SendGrid "s1" and "s2". If you do not know, look in your provider’s panel under authentication or DKIM: the exact name is there.
How do I know whether my email marketing platform signs with my domain?
Check here the selector the platform asked you to publish: if the record exists and has a key, it is signing with your domain. If the platform never asked you to publish anything, it signs with its own domain, and then DMARC sees a signature from another domain and ignores it. That is DKIM "alignment", and without it the DMARC policy can send your own campaigns to spam.
Does this query go through your server?
No. Your browser asks Cloudflare’s public resolver (1.1.1.1) directly over HTTPS, the same query any command-line tool would make. We never see which domain you checked or what records it has. It is also why JavaScript is required.
I changed a record and the old one still shows here. Why?
Because of the TTL, the time each record declares it may be cached. Public resolvers honour that value, usually an hour, although some DNS providers set it to a day. If you are in a hurry, lower the TTL before changing the record, not after: the old value stays cached for as long as it declared.
Does it work for subdomains?
Yes: type the full subdomain, such as mail.yourdomain.com. SPF and DKIM are looked up at the exact name you type. DMARC is different: if the subdomain has no record of its own, receivers apply the parent domain’s, specifically its sp= tag if present. If the subdomain sends mail on its own, it should have its own SPF.
Are your automated emails landing in spam?
It is usually a badly closed record or a signature with the wrong domain. We set it up, test it against real receivers and keep the reports watched so it does not happen again in silence.
We reply within one business dayBogotá · UTC−5