Email bouncing or authentication failing? Start with what your domain says about its senders. Understand the error before changing your DNS.
Enter a domain to inspect its public MX, SPF and DMARC records. DKIM needs the selector and signing domain from a real message or your sending provider. Pasting headers can fill these in and show reported authentication results. This checks configuration, not inbox placement or a particular message.
These records do different jobs. A passing result for one does not mean the others are working.
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.
Check alignment and all legitimate senders before tightening a DMARC policy.
Authentication is one part of delivery. Reputation, complaints, message content and recipient filtering also affect where an email lands.
| 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 configuration check is available above. The paid fix workflow is not open yet.
Find configuration errors before paying for a fix.
Results stay in your browser session; no account is required.
A specific set of changes for a supported setup.
We'll confirm that your issue is supported before offering payment. Inbox placement is not guaranteed.
The planned $5 offer will run for the first 30 days after the paid service launches. Exact dates will be shown when checkout opens. Payments are not being accepted yet.
A useful diagnosis tells you what failed, what is still unknown and what to do next.
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.
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.
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.
The planned 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 initial offer.
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.