Check the DNS behind bounced messages, authentication failures and spam-folder delivery. See what is wrong, what is still unknown and the safest next step—before you change a record.
Enter the domain you send email from. We inspect its public MX, SPF, DMARC and BIMI records. Add a DKIM selector—or paste headers from a problem message—for a more useful diagnosis. Nothing is changed, and no account is required.
Choose the issue you want to resolve. We verify it again before payment and build a private, domain-specific Fix Pack—never a generic copy-and-paste record.
Each record answers a different delivery question. We show the evidence without turning it into a misleading score.
SPF lets a receiving server check whether an IP address is authorised to send for the envelope sender domain. That domain may differ from the visible From address.
Check for more than one SPF record at the same DNS name, missing sending services and too many DNS lookups during evaluation. Several unrelated TXT records are normal; multiple records beginning with v=spf1 are the problem.
Keep a list of legitimate senders before merging or replacing an SPF record.
DKIM uses a signature on the message and a public key published in DNS. Your sending service creates the signature; publishing a DNS record alone does not enable signing.
A check needs the signing domain and selector. Find d= and s= in a message's DKIM-Signature header, or use the values supplied by your email provider.
An unknown selector means DKIM has not been checked. It does not prove DKIM is missing.
DMARC checks whether the visible From domain aligns with a domain that passes SPF or DKIM. A message can pass SPF for another domain and still fail DMARC.
Look up the record at _dmarc.yourdomain.com. A monitoring policy of p=none is valid. Moving straight to p=reject can disrupt legitimate mail if the senders are not ready.
Domain Impersonation Protection: use p=none to monitor, p=quarantine when aligned legitimate mail is stable, and p=reject only after every real sender is verified.
BIMI lets a sending domain publish a logo reference in DNS for supporting mailbox interfaces to consider after the message passes the provider's authentication requirements.
It is optional. A BIMI record normally lives at default._bimi.yourdomain.com and references a hosted SVG logo; some providers also require a VMC or CMC.
BIMI can improve brand recognition in compatible inboxes, but it does not guarantee logo display or inbox placement.
Authentication is one part of delivery. Reputation, complaints, message content and recipient filtering also affect where an email lands.
The same symptom can have different causes. Start with the evidence instead of replacing records blindly.
| What you see | Where to start |
|---|---|
| Multiple SPF records | Identify every authorised sender. Build one valid SPF record for that DNS name without dropping services you still use. |
| SPF permerror | Read the full error. Check syntax, duplicate SPF records and the lookup limit before deciding on a fix. |
| DKIM record not found | Confirm the provider's selector and signing domain. A lookup using the wrong selector cannot establish whether DKIM is configured. |
| DMARC fails, SPF passes | Compare the envelope sender domain with the visible From domain. Also check whether an aligned DKIM signature passes. |
| Gmail error 5.7.26 | Read the complete bounce: this code covers authentication and policy failures. Check the specific reason Google reports and the affected sender. |
The free check explains the current setup. When the issue is supported, the Fix Pack turns it into a careful action plan you can apply yourself or with our help.
See whether the problem is in your public email DNS before you spend money or change anything.
No account and no DNS access. Run it again whenever you need a fresh view.
Move from “something is wrong” to a safe, domain-specific plan you can act on.
We confirm that the selected issue is supported before PayPal checkout. Apply it yourself or request our assistance. No subscription. No inbox-placement or BIMI-display promise.
You pay only after a fresh server-side check confirms the scope. PayPal processes the one-time payment; your recovery link opens the private package without creating an account.
A safe fix is more valuable than a perfect-looking score or a record copied from a generic example.
It can resolve authentication failures, but it cannot guarantee inbox placement. Sending reputation, complaints, content and the recipient's filters still matter. A DNS check cannot tell you where a particular message was delivered.
No. It is a valid monitoring policy. Whether it is suitable depends on your goal and the requirements that apply to your sending. Check your legitimate senders and alignment before moving to a stricter policy.
p=none provides reporting and visibility but does not ask receivers to block failing messages. Once every legitimate sender consistently passes aligned SPF or DKIM, p=quarantine asks receivers to treat failures as suspicious, while p=reject provides the strongest enforcement against unauthorised use of your exact From domain. Roll out gradually when needed. DMARC does not stop attackers registering a similar-looking domain and does not guarantee inbox placement.
Not comprehensively. DKIM keys are published under selectors chosen by sending services. A reliable lookup needs the selector and signing domain. Verifying a signature also needs the original message.
BIMI is a DNS-published brand indicator: compatible mailbox providers may show your logo beside authenticated messages after their own DMARC, reputation and certificate checks. It can improve brand recognition and make legitimate messages easier to recognise, but it does not change delivery or guarantee that a provider will show the logo. A BIMI setup needs a correctly authenticated sending domain, a suitable SVG logo and, for many providers, a VMC or CMC.
First inventory all services that send from the affected domain. A replacement that authorises one service but removes another can cause new failures. Preserve the previous record so you can review or roll back the change.
You receive a private, downloadable package for one confirmed issue: a diagnostic-message check, the DNS baseline we checked, the supported scope, proposed changes or required provider inputs, safe application guidance, rollback context and three configuration rechecks within seven days. The package then gives you a direct link to request the complete scoped fix from an infrastructure engineer if you prefer not to apply it yourself. The pack is tied to your domain and finding; it is not a generic DNS template.
The first Fix Pack gives you the proposed records and provider-specific instructions. You can apply the changes in your own DNS account, or request our assistance if you grant temporary, least-privilege access to the relevant DNS zone. Automatic unattended DNS changes are not part of this offer.
We recheck the selected issue before opening PayPal checkout, so you do not pay for a stale or unsupported scope. After the one-time $5 payment is verified, we prepare the private Fix Pack and open its recovery page. Keep that link private: anyone who has it can access the package. If preparation takes longer, the page shows progress and refreshes automatically.
Use your DNS provider's delegated user or API token, limited to the relevant zone and DNS-record changes. Do not share your registrar password, account-wide credentials or a token with unrelated permissions. Grant access only after the package scope is confirmed, and revoke or delete the delegated access as soon as the changes are complete.
For the underlying requirements, see the original specifications and Google's guidance. The checker reads public DNS; it does not verify a particular message or promise inbox delivery.